Browser-Based Load Testing with Real Residential IPs

Test how your website performs under real-world load. This Actor launches full Chromium browser sessions — not raw HTTP requests — routed through rotating residential proxies worldwide. Every session loads JavaScript, executes analytics scripts, fires network requests, and behaves exactly like a real visitor navigating your site.

Use it to expose bottlenecks before they hit production, validate your CDN and caching setup, or verify that your infrastructure holds up under traffic spikes from different regions.

---

What this Actor does

Each simulated session:

• Opens a real headless Chromium browser (full JS execution, resource loading, analytics events)
• Routes through a unique residential IP — a fresh proxy session per browser visit, so every hit looks like a different user from a different location
• Applies a randomised browser fingerprint (screen resolution, timezone, platform, language) via Crawlee's built-in fingerprint injection
• Scrolls through the page and moves the mouse to simulate realistic dwell behaviour (configurable)
• Waits a configurable dwell time on the page before closing the session
• Records status code, full page load duration, and any errors
• Streams all results live to a dataset and saves a summary with aggregate stats when complete

---

Intended use cases

This tool is designed for engineers testing infrastructure they own or are authorised to test:

• Pre-launch stress testing — find breaking points before real users do
• CDN and edge cache validation — confirm that cache-hit rates hold under concurrent load
• Rate limiting and WAF verification — check that your firewall rules behave correctly under bursts from diverse IPs
• Regional performance benchmarking — measure load times routed through proxies in specific countries
• Rendering pipeline testing — verify that server-side rendering, hydration, and JS bundle loading work correctly under concurrency
• Autoscaling trigger testing — confirm your hosting provider scales up when it should

Important: Only run this against websites and infrastructure you own or have explicit permission to test. Unauthorised load testing may violate Terms of Service and applicable law.

---

How to use

1. Open the Actor on Apify Store and click Try for free
2. Enter the Target URL of the page you want to test
3. Set Page View Count, Concurrency, and Delay to define the load profile
4. Optionally pin a Country Code to test from a specific region
5. Click Start — results stream in real time to the Output tab
6. When the run finishes, export the dataset as JSON, CSV, or Excel

---

Input

Field	Type	Default	Description
url	string	(required)	Target URL to load in each browser session
requestCount	integer	50	Total number of browser sessions to run
concurrency	integer	5	Maximum parallel browser sessions
minDelayMs	integer	0	Minimum pre-request delay per session (ms)
maxDelayMs	integer	0	Maximum pre-request delay per session (ms) — randomised between min and max
minTimeOnPageMs	integer	2000	Minimum time the browser spends on the page after load (ms)
maxTimeOnPageMs	integer	8000	Maximum time the browser spends on the page after load (ms)
simulateBehavior	boolean	true	Scroll through the page and move the mouse during the session
waitUntil	select	load	Page load event to await: domcontentloaded, load, or networkidle
proxyGroups	array	["RESIDENTIAL"]	Apify proxy groups — use RESIDENTIAL for diverse IPs
countryCode	string	(any)	ISO 3166-1 alpha-2 country code to restrict proxy location (e.g. US, DE)
headers	object	{}	Extra HTTP headers injected into every browser session

Example — pre-launch stress test from US residential IPs:

{
    "url": "https://yourdomain.com",
    "requestCount": 200,
    "concurrency": 10,
    "minDelayMs": 300,
    "maxDelayMs": 1200,
    "minTimeOnPageMs": 3000,
    "maxTimeOnPageMs": 10000,
    "simulateBehavior": true,
    "waitUntil": "networkidle",
    "proxyGroups": ["RESIDENTIAL"],
    "countryCode": "US"
}

---

Output

Each browser session produces one record in the default dataset.

Per-session record:

{
    "requestIndex": 1,
    "url": "https://yourdomain.com",
    "statusCode": 200,
    "durationMs": 2847,
    "success": true,
    "error": null,
    "timestamp": "2024-05-10T12:34:56.789Z"
}

Run summary (saved to key-value store under key SUMMARY):

{
    "url": "https://yourdomain.com",
    "totalRequests": 200,
    "successCount": 198,
    "errorCount": 2,
    "successRate": "99.0%",
    "avgDurationMs": 2341,
    "minDurationMs": 987,
    "maxDurationMs": 8203,
    "totalElapsedMs": 94500,
    "throughputReqPerSec": 2.12,
    "statusCodeCounts": { "200": 198, "503": 2 },
    "finishedAt": "2024-05-10T12:36:31.289Z"
}

durationMs measures the full browser session — from navigation start to page fully loaded plus dwell time — making it a realistic measure of user-perceived load time.

---

Tips

Ramp up gradually: Start with concurrency: 3 and requestCount: 20 to establish a baseline, then increase concurrency incrementally to identify the threshold where errors begin appearing.

Stick with domcontentloaded for reliability: The default domcontentloaded event fires once the HTML is parsed and JS starts executing — which is when real users start perceiving the page. load and networkidle additionally wait for all images and background requests to finish, which through residential proxies can easily exceed 60 seconds on image-heavy sites and cause unnecessary retries. Only switch to networkidle if you specifically need to measure full resource load times.

Test specific regions: Set countryCode: "DE" to route all sessions through German residential IPs. Useful for validating region-specific CDN edge nodes or GDPR-related routing rules.

Simulate sustained low-level load: Set concurrency: 2, requestCount: 500, minDelayMs: 1000, maxDelayMs: 3000 for a prolonged gentle test that runs for several minutes without spiking your error rates.

Inject custom headers: Use headers to pass values like { "X-Test-Run": "load-test-2024" } so your server logs can distinguish test traffic from real traffic during the test window.

---

FAQ

Can I use this on any website? Only on websites and services you own or have explicit written authorisation to test. Load testing without permission can cause service disruption and may be illegal under computer misuse legislation in your jurisdiction.

Why use browser sessions instead of plain HTTP requests? Real browser sessions load the full page — JavaScript bundles, fonts, images, third-party scripts, analytics events. This exercises your entire stack: origin server, CDN, edge workers, and any client-side rendering pipeline. Plain HTTP misses all of that.

Will server-side analytics record these sessions? Yes — access logs, Cloudflare, and server-side analytics will record the requests. Client-side analytics tools (e.g. Google Analytics) will also fire since JavaScript executes in the browser. If you want to exclude test traffic from your analytics, use the headers input to inject a recognisable header and filter it out in your analytics platform.

Is there a free tier? Free Apify accounts can run 1 browser session per run to try the Actor. For any meaningful load test you'll need a paid Apify plan, which removes this cap.

Do I need a paid Apify plan for residential proxies? Yes. Residential proxies require a paid Apify subscription. If you want to run without proxies (all sessions from the Actor's container IP), set proxyGroups: [] — useful for quick local network tests.

How much does a run cost? Cost depends on the number of sessions, page size, and proxy traffic. Browser sessions consume more proxy bandwidth than raw HTTP — a typical modern webpage transfers 1–3 MB. At 100 sessions × 2 MB average: ~200 MB of residential proxy traffic. Check current proxy pricing at apify.com/pricing.