How to Load Test Websites with a Browser

To load test a website with a browser, first decide whether you need to diagnose one page, compare browser loads under chosen conditions, or measure how a service behaves under concurrent traffic. Use Lighthouse in Chrome DevTools for a page audit, WebPageTest for controlled remote browser runs, and k6 browser for scripted browser journeys. A browser audit alone does not establish how many concurrent users a service can handle.

For capacity testing, define a workload and generate traffic with a protocol-level test such as k6. Add browser tests when rendering, interaction, and browser metrics matter. A useful report records the page or journey, browser, location, connection profile, first or repeat view, run count, workload, and observed metrics.

1. Choose the test that answers your question

Question	Start with	What it tells you
Where is this page slow, and what should I investigate?	Lighthouse in Chrome DevTools	A page audit with metrics, screenshots, opportunities, diagnostics, and passed audits. It is not a concurrent-user capacity test. Chrome Lighthouse guide
How does a browser load vary by location or connection?	WebPageTest	Remote runs with selectable browser, location, connection profile, run count, and first or repeat view. WebPageTest
Does a real browser journey render and behave correctly?	k6 browser	Scripted interactions in a Chromium-based browser, alongside browser metrics. k6 browser documentation
Can the service handle concurrent traffic?	Protocol-level load test, for example k6	Server behavior under a defined workload. Pair with browser tests when you also need user-visible rendering and interaction data. k6 website load testing guide

These methods answer related but different questions. Lighthouse helps diagnose a page; remote browser testing lets you compare specified conditions; scripted browser testing exercises journeys; protocol traffic can generate concurrent requests efficiently. Combine them when the goal includes both backend capacity and the experience people see in a browser.

2. Establish a page baseline with Lighthouse

Open the target page in Chrome and open DevTools.
Select Lighthouse, choose the audit settings relevant to your question, and generate a report.
Save the report and note the page, browser, device or audit configuration, and when the run took place.
Make one relevant change at a time, then repeat the audit under the same conditions to assess its isolated effect.
Use the report’s diagnostics and opportunities to investigate. Treat the score as a starting point, not a full explanation of what happened.

Lighthouse is also available through a command-line tool and as a Node module. Use the project’s current documentation for installation and runtime requirements, which can change: GoogleChrome Lighthouse project. DevTools is a convenient place to establish a manual baseline; CLI or Node usage fits automated workflows.

Keep comparisons like-for-like: same URL and page state, same browser and audit settings, and comparable runs. A result from one audit does not demonstrate how the site handles many visitors at once.

3. Compare remote browser loads with WebPageTest

Enter the page URL.
Choose a test location near the users whose experience you want to approximate.
Select an available browser and a connection profile that matches the question.
Choose the number of runs and whether to collect first view, repeat view, or both.
Review the waterfall and visual filmstrip, then compare repeated runs before drawing conclusions.

Report the selected browser, location, connection profile, run count, and view type with any result. A remote test describes those selected conditions; it does not automatically represent every browser, network, or production region. WebPageTest documentation explains location selection and repeat views: WebPageTest documentation.

First view and repeat view are different scenarios

A first view represents a fresh-visit scenario. A repeat view is intended to represent another visit with state or cache retained according to the test setup. Keep the two results distinct: they answer different questions. Repeated runs help reveal variation; repeat view concerns browser state across visits.

When runs differ, do not select only the fastest result. Compare the detailed request waterfall and filmstrip to understand the timeline and report the variation along with the setup.

4. Script browser journeys and test concurrency with k6

Use a browser script when the test depends on browser behavior: navigating, clicking, waiting for content, or observing browser metrics. Use protocol-level scripts for higher-volume concurrent traffic and backend behavior. Grafana documents both browser-based and protocol-based testing; select the approach according to the measurement objective. k6 browser · Load testing websites with k6.

A real test plan should specify virtual users, arrival pattern, duration, test geography, browser mix, and the user journey. Choose these values from expected traffic and the test environment; there is no universal workload in the cited guidance. Do not point a high-concurrency test at a third-party site without authorization.

Define a workload before running it

Journey: list the pages and interactions being exercised, and the state needed to start each journey.
Load shape: define virtual users or an arrival pattern, duration, and any ramp-up or ramp-down behavior appropriate to the question.
Environment: record the browser environment and geography for browser runs, and the test environment for protocol traffic.
Observations: decide which browser metrics and server-side measures will answer the question.
Comparison: retain the script and configuration so a later run can be compared under the same conditions.

Do not infer capacity from a browser audit score. Browser execution is useful for seeing user-visible behavior; protocol testing is generally the more suitable way to generate broader concurrent traffic. A combined approach connects what the service handled with what a user experienced.

5. Make results repeatable and useful

Change one relevant factor at a time while diagnosing page performance.
Repeat runs to see whether a result is stable; show the run count and variation instead of presenting one favorable run as a fact.
Separate fresh and repeat visits, since retained state changes the scenario.
Keep the browser, location, connection profile, page state, and workload consistent when comparing changes.
Use traces, waterfalls, filmstrips, browser metrics, and server-side measures to explain results; a score alone is not a diagnosis.
Label findings as applying to the configured test. Do not generalize one location or browser to all users.

6. Common problems and fixes

Symptom	Likely cause	What to do
A good Lighthouse score but slow behavior under traffic	A page audit is being treated as a capacity test.	Define a concurrent workload and run a protocol-level load test; add browser journeys to measure user-visible behavior.
Results differ between runs	Browser tests can vary, or the conditions are not comparable.	Use multiple runs, keep settings consistent, and inspect the waterfall and filmstrip for differences.
First-view and repeat-view results disagree	The repeat scenario retains state or cache according to the setup.	Report them separately and make sure the selected view matches the question.
A remote result does not match a user report	The chosen browser, location, or connection profile differs from that user’s conditions.	Select representative conditions, record them, and avoid treating one remote configuration as universal.
A browser journey fails during a load test	The journey, starting state, or browser conditions may not be repeatable, or the service may behave differently under load.	Reproduce the journey at low load, verify its initial state and steps, then compare browser observations with server-side measures as traffic increases.
Protocol test shows healthy responses but the page looks broken	Protocol checks do not observe rendering and browser interaction.	Add a browser-based scripted journey and inspect its browser metrics and visual timeline.

7. Performance, reliability, and cost considerations

Choose the lightest test that answers the question. Lighthouse is a practical diagnostic baseline; remote browser tests add controlled location and connection comparisons; browser scripts exercise interactions; protocol load generation is appropriate for broader concurrency. Browser runs and protocol tests have different resource demands, so scope the workload to the environment and objective.

For reliability of conclusions, use comparable repeated measurements and preserve the configuration. A result is only representative of the conditions selected. Keep page-performance diagnosis separate from service-capacity conclusions, and correlate browser observations with server-side measurements for a combined view.

The research sources do not establish universal run counts, workload sizes, prices, or performance thresholds. Determine these from your expected traffic, test environment, and budget; do not treat an arbitrary number as a standard.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. It captures a page as PNG, JPEG, WebP, or PDF with one GET request. See the ScreenshotNeo API documentation. A screenshot is useful for capturing a page’s visual state; it does not replace a concurrent traffic test.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners and consent overlays are accepted and removed before the shot; newsletter popups and chat widgets are removed too. Each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers identify the page verdict and billing status.
An MCP server lets AI agents, including Claude and Cursor, use screenshot, page-info, and PDF-capture tools.
The Free plan includes 1,000 shots a month with no card. Paid plans start at $5 for 3,000 shots.

Frequently asked questions

Can Lighthouse simulate many concurrent users?

No. It audits a page. Use a designed load test to assess concurrency.

Should I use a browser or protocol test?

Use browser tests for rendering and interactions, protocol tests for efficient concurrent traffic generation, and both when you need to connect backend behavior to user experience.

Does repeat view mean repeated test runs?

No. Repeat runs help show variability. Repeat view represents a subsequent visit with retained state according to the test setup.

What should I include when publishing a result?

Include the page or journey, browser, location, connection profile, view type, run count, workload shape where applicable, and the measures observed.