Frontend browser performance testing

Use case

Modern web applications are increasingly dominated by client-side rendering, single-page app hydration, and third-party script loading. The server can be fast — sub-50 ms response times — while the user experiences 4 seconds before they can interact with the page. HTTP-only load testing measures the server half of that equation and misses the client half entirely.

Frontend browser performance testing runs real browser sessions at load. The test executes a Playwright script that navigates, clicks, fills forms, and waits for rendered content — the same actions a real user would take. Under concurrent load from multiple browser sessions, bottlenecks appear that never show up in HTTP tests: JavaScript bundles that block hydration, render-blocking stylesheets, CDN cache misses on shared assets, and third-party analytics scripts that serialise on the main thread.

The goal is not just to find these issues in isolation; it is to find them at the concurrency level your users actually produce. A hydration bottleneck that takes 200 ms at 1 user and 2,000 ms at 50 concurrent users is a performance cliff that HTTP testing will not tell you about.

How MaxoPerf supports it

MaxoPerf supports Playwright as a first-class test executor. A Playwright script authored for browser testing runs on MaxoPerf’s browser-enabled runner infrastructure without changes to the script itself.

Browser runs collect per-step metrics including total step duration, network timing, and any custom performance marks you add to the script (via page.evaluate(() => performance.mark(...))). Step labels map to Playwright test steps or named checkpoints, so the result breakdown shows which interaction — login, product load, checkout — is the bottleneck.

Browser runner health metrics (CPU, memory) surface the resource cost of running real browsers at concurrency, which is higher than HTTP runners. This makes it easy to distinguish “the browser itself is CPU-bound” from “the application is the bottleneck.”

A concrete browser test profile

A fintech company tests their web dashboard — a React SPA with complex data visualisation — before every release:

• Journey: authenticate via SSO redirect → load portfolio overview dashboard (heavy D3 charts) → navigate to transaction history (infinite scroll) → open a single transaction detail (modal with async data)
• Playwright steps: 4 named steps, each with a page.waitForLoadState('networkidle') assertion and a visual assertion on key elements appearing in the DOM
• Load profile: 20 concurrent browser sessions, 5-minute hold; 2 managed regions (US-East, EU-West)
• Thresholds: p95 per step < 3 s; JavaScript error count = 0 (asserted per session); no unhandled promise rejections
• Finding from last release: a new analytics integration introduced a 1.8 s blocking script on the portfolio overview step. p95 jumped from 1.2 s to 3.1 s at 20 concurrent users; the script loading had been invisible in the individual developer’s browser (cached after first load) but showed up clearly in fresh browser sessions under load.

Practical rollout

1. Start with your most complex, highest-value flow — pick the journey where client-side rendering work is most significant. A purely server-rendered page benefits less from browser-based load testing than an SPA with heavy hydration.
2. Add named steps — use Playwright’s test.step() or custom performance.mark() calls to label each meaningful interaction. Without labels, all you know is that the session took X seconds total.
3. Assert on rendered state, not just HTTP responses — use waitForSelector, waitForLoadState('networkidle'), and assertions on DOM content to confirm that the UI is actually ready, not just that a network request completed.
4. Run at moderate concurrency and combine with HTTP tests — 20–50 concurrent browsers is enough to surface rendering bottlenecks. Run this alongside a higher-concurrency HTTP test to cover both user-experience quality and raw server throughput.
5. Baseline before every major frontend change — bundle size increases, new third-party scripts, and hydration changes can each independently regress browser performance. Baseline after each change so you can attribute the regression to a specific change rather than debugging across multiple changes at once.