--- title: "How Real-Browser Performance Testing Works | Evaluat" description: "How Evaluat runs each virtual user in its own isolated browser, capturing Core Web Vitals and Navigation Timing at load, with session video and full logs." url: "https://www.evaluat.com/how-it-works" last_modified: "2026-08-12" --- How it works # One browser per user. The numbers come out *honest*. This is the technical layer, written for the engineer who has to decide whether our numbers can be trusted. If you came for the business case, start with [what a report shows](https://www.evaluat.com/reports/examples), then send this one to your engineering lead. Evaluat runs performance tests with [real browsers](https://www.evaluat.com/blog/real-browser-load-testing). One isolated browser per virtual user. That's the architectural decision everything else follows from. Here's what that means in practice and why it changes the numbers. The architectural principle ## 1,000 users means 1,000 browsers. When you start a 1,000-user test in Evaluat, the platform provisions 1,000 isolated browser instances, one per virtual user. Each instance has its own memory, cache, cookies, and network stack, so session state does not cross between users. Instances still share host compute; the contention you measure is real browser work under the selected test conditions. That isolation is the differentiator. Every virtual user keeps its own browser evidence: Core Web Vitals, session video, network logs, and console output for that session. You can open any one of them and see what that controlled browser did under load. Performance under load is mostly about contention. Measuring many concurrent browser experiences is a different instrument from approximating concurrency inside a shared process. The [LCP](https://www.evaluat.com/blog/largest-contentful-paint) and other timings you record in Evaluat are per-session, from independent browsers against your server, with the load you're testing. The numbers reflect what these controlled browsers saw under the selected test conditions. That is the right instrument for experience under load, and it is different from field CrUX data on your customers' own devices. *** What gets measured ## Every virtual user gives you the full picture. For every virtual user in every test, Evaluat captures the six things below. Aggregated across the run and addressable per session. CSV aggregates and per-session console download are available today; other raw exports vary by capture type. ### Core Web Vitals Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), plus First Contentful Paint (FCP). Captured natively by every real browser in the run. ### Navigation Timing DNS lookup, TCP connect, TLS negotiation, Time to First Byte, response, DOM Content Loaded, page load. Every phase, per URL, percentile-selectable. ### Network activity Every HTTP request the browser made: method, URL, status, timing breakdown, size, MIME type, originating page. Searchable across the whole run. ### Console output Every `console.log`, warning, error, exception, and resource load failure. Deduplicated with counts so the loud ones surface first. ### Session recording A full video of the browser viewport for every virtual user's session. Scrub through it. Find the broken moment. No reconstruction from logs. ### Step playback Every scripted action (navigate, click, type, wait) timestamped to the millisecond, with the CSS selector targeted and pass/fail outcome. Report views. Pick one to see that view of the run. Sessions Console Logs Network Logs ![Evaluat Sessions view: every virtual user's session listed with start time, duration, scenario, and pass or fail status, from a 200-user peak-trading rehearsal.](https://www.evaluat.com/_astro/sessions-list-panel.CJ5COGIn_2iIi1J.webp) A recorded session for every virtual user, so you can watch the exact run that failed instead of inferring it from an average. ![Evaluat Console Logs view: browser console warnings and messages deduplicated with a count for each across the whole run, from a 200-user peak-trading rehearsal.](https://www.evaluat.com/_astro/console-logs-panel.Gv4SK4x9_Z1vETcc.webp) The browser console output captured per session, errors and warnings included. ![Evaluat Network Logs view: every HTTP request with its page URL, hit count, status, and p95 duration, from a 200-user peak-trading rehearsal.](https://www.evaluat.com/_astro/network-logs-panel.Dw6i6Q32_q9Ikf.webp) The network activity captured per session, so you can see what was slow or failing on the wire. A real Evaluat report from a 200-user run. Company name, journey labels, and URLs anonymised at the customer's request. *** Building a test ## Four pieces. None of them require code. An Evaluat test is composed from four reusable parts. Build them once for Performance Testing today; the same pieces are designed to recombine for smoke tests and monitors when Testing Suite and Monitoring ship. Performance Testing is available through assisted private access; Testing Suite and Monitoring are planned. 01 ### Test scenarios A scenario is a user journey: a sequence of steps like "navigate to the homepage, click the product category, click a product, add to cart, proceed to checkout." Scenarios are reusable building blocks. A single test can run many scenarios in parallel with weighted distribution. 02 ### Datasets Datasets inject variable data into scenarios. 1,000 different UTM combinations. 1,000 different search terms. 1,000 different user records. Each virtual user picks a row, so no two users follow exactly the same path. Cache effects can't pretend to be performance. 03 ### Popup handlers Cookie banners. Newsletter modals. Geolocation prompts. Chat widgets. These break naive performance tests. Popup handlers in Evaluat are persistent project-level rules ("if this element appears, click that button") that apply across every scenario, so your test scripts stay focused on the journey. 04 ### Test plan The test plan ties everything together. Region. Timezone. Locale. Viewport. Browser speed. Load shape (Duration or Sessions). Ramp-up profile. Which scenarios run at what weight. The plan is what you click "run" on. *** Configurable conditions ## The dials you actually need. Every test plan controls these. None of the dials are gated behind a "contact sales" tier. Plan limits (regions, domains, concurrency) scale with the tier; the configuration surface doesn't. ### Region Pick the geographic origin for your virtual users. Latency from the UK is different to latency from the EU. The test should know which one you care about. ### Timezone & locale Match the segment you're modelling. A Dutch checkout should run with `nl_NL` locale and Europe/Amsterdam timezone, not `en_US`. ### Viewport Set the browser dimensions. Mobile (375×812) to desktop (1920×1080) and beyond. The viewport changes the layout, which changes LCP and CLS. ### Speed How fast actions happen between steps. Bot-speed clicking exposes different bugs than human-paced clicking. Pick the one that matches your test goal. ### Load shape Ramp-up duration, steady-state duration, ramp-down duration. Combined with target concurrency, this is how you describe load tests, stress tests, spike tests, and soak tests through one configuration. ### Popup handlers (active set) Toggle which project-level popup handlers apply to this run. Useful when you want to test what happens if the cookie banner doesn't dismiss. Get a demo Test in real browsers.\ Debug in real sessions. ## Want to see the report on *your* site? 30 minutes. We'll build a scenario on your real customer journey, run a small test live, and walk you through the five report views with your data in them. [Book a demo](https://www.evaluat.com/demo?intent=performance) [See pricing](https://www.evaluat.com/pricing)