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.
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, then send this one to your engineering lead.
Evaluat runs performance tests with real browsers. 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 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.
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.
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.