# Evaluat (full)

> Evaluat is a real-browser performance testing platform that runs each virtual user in an isolated browser instance, capturing Core Web Vitals and Navigation Timing metrics under load — with full session video, network logs, and console logs for every user.

This is the extended machine-readable index for evaluat.com. For the concise version, see https://www.evaluat.com/llms.txt.

## AI and agent resources

Evaluat is agent-ready. AI agents can run a real-browser website speed test through the Model Context Protocol (MCP) server and read the results back as structured data.

- MCP endpoint: https://www.evaluat.com/api/mcp (Streamable HTTP, JSON-RPC 2.0, no API key, rate limited). Tool: run_website_speed_test(url, region) loads a public URL once in a real browser from the UK or the EU and returns LCP and CLS, plus FCP and TTFB, Evaluat's A to F composite grade, and a shareable video report URL. A single cold load does not produce a representative INP.
- MCP server card: https://www.evaluat.com/.well-known/mcp.json
- OpenAPI 3.1 specification: https://www.evaluat.com/openapi.json (POST /api/pulse to start a run; GET /api/pulse/{token} to read status and metrics).
- API catalog (RFC 9727): https://www.evaluat.com/.well-known/api-catalog
- AI plugin manifest: https://www.evaluat.com/.well-known/ai-plugin.json
- Developer and agent reference: https://www.evaluat.com/developers

## What Evaluat is

- Evaluat is a real-browser performance testing platform. Every virtual user runs in its own isolated browser instance with its own cache, cookies, and network stack. Instances share host compute, so the contention measured under load is real browser work under the selected test conditions rather than a shared-browser approximation of many users inside one process.
- It captures Core Web Vitals (LCP, INP, CLS), plus FCP, TTFB, Navigation Timing, and Apdex for every virtual user under load, plus full session video, network logs, and console logs, each session individually addressable.
- Three products built on one scenario format: Performance Testing (available through assisted private access), Testing Suite (planned), Monitoring (planned). Build a scenario once for Performance Testing today; the same scenarios are designed for CI smoke checks and continuous monitors when those products ship.
- Operated by Evaluat Digital Limited, a company incorporated in the United Kingdom (company number 14150225).

## Products

- [Performance Testing](https://www.evaluat.com/product/performance-testing): Real-browser performance, load, stress, and spike tests at forecast peak traffic, sized with you, with Core Web Vitals capture and a five-view forensic report per run. Available through assisted private access.
- [Ecommerce performance testing](https://www.evaluat.com/solutions/ecommerce-performance-testing): Commercial solution page for ecommerce and digital leaders rehearsing peak journeys. Covers ecommerce load testing for Shopify, Magento, WooCommerce, and headless storefronts.
- [Magento performance and load testing](https://www.evaluat.com/solutions/magento-performance-testing): Real-browser load testing for Magento and Adobe Commerce stores, catalog to checkout, including Hyvä and headless frontends. Explains the two-ceilings model: full-page-cache-served pages versus the uncacheable cart, checkout, and login paths that saturate first.
- [Checkout performance testing](https://www.evaluat.com/use-cases/checkout-performance-testing): Cart and checkout rehearsal under concurrency.
- [Peak readiness](https://www.evaluat.com/use-cases/peak-readiness): Black Friday, flash sale, and launch readiness rehearsals.
- [Testing Suite](https://www.evaluat.com/product/testing-suite): Runs the same real-browser scenarios as post-deploy smoke checks in CI, failing the pipeline on broken journeys or busted Web Vitals budgets. Planned.
- [Monitoring](https://www.evaluat.com/product/monitoring): Runs the same scenarios continuously from chosen regions and attaches the session video, network log, and console log to every alert. Planned.
- [How It Works](https://www.evaluat.com/how-it-works): The architecture (one isolated browser per virtual user), what is measured, and how a test is built from scenarios, datasets, popup handlers, and a test plan.
- [What's in a report](https://www.evaluat.com/reports/examples): What a report contains: five detail views on every plan (Overview, URL performance, Sessions with video, Console logs, Network logs), plus an Executive Summary (plain-language verdict, health score, findings ranked by severity, recommended fixes) generated on demand.
- [Changelog](https://www.evaluat.com/changelog): Dated product, tooling, and platform updates, newest first. Entries begin June 2026.

## Free tools

- [Website Speed Test (Evaluat Pulse)](https://www.evaluat.com/tools/website-speed-test): Free website speed test that loads a public URL once in a real browser from the UK or the EU and returns LCP and CLS, plus FCP and TTFB, Evaluat's A to F composite grade, and a video replay on a shareable report link. A single cold load does not produce a representative INP. No signup; reports are kept for 30 days.

## Comparisons

- [All comparisons](https://www.evaluat.com/vs): The comparison hub: how Evaluat lines up against other load testing tools that test in real browsers, each page with a capability table, a reviewed date, and an honest when-the-other-tool-is-right section.
- [Evaluat vs k6](https://www.evaluat.com/vs/k6): k6 is an open-source load tester from Grafana Labs, scripted in JavaScript for protocol and API load in CI. Its browser module drives real Chromium but is resource-heavy, so teams run it for a share of users alongside protocol load. Evaluat runs a real browser for every virtual user with no scripting, reports Core Web Vitals and Apdex, and can generate an Executive Summary.
- [Evaluat vs AppLoader](https://www.evaluat.com/vs/apploader): AppLoader drives GUI and protocol load across desktop and web applications. Evaluat focuses on web applications in real browsers and reports Core Web Vitals, Navigation Timing, and Apdex for every user.
- [Evaluat vs Cavisson NetStorm](https://www.evaluat.com/vs/cavisson): Cavisson NetStorm is an enterprise multi-protocol load testing suite. Evaluat is a hosted real-browser tool that reports the user-visible experience and keeps per-session video, network, and console logs.
- [Evaluat vs JMeter](https://www.evaluat.com/vs/jmeter): JMeter sends protocol-level requests from a JVM (HTTP, JDBC, JMS, SOAP, and more). Evaluat runs real browsers from the cloud with visual scenario authoring and measures the user-visible experience.
- [Evaluat vs Loadero](https://www.evaluat.com/vs/loadero): Loadero runs real browsers and is strong on WebRTC and multi-participant testing. Evaluat is a real-browser performance tool focused on Core Web Vitals under load, an Executive Summary, and per-session forensics with no scripting.
- [Evaluat vs LoadForge](https://www.evaluat.com/vs/loadforge): LoadForge is a cloud load tester built on Locust and scripted in Python for HTTP load. Evaluat runs a real browser for every user and reports the Core Web Vitals the protocol layer cannot see.
- [Evaluat vs Loadium](https://www.evaluat.com/vs/loadium): Loadium is a cloud runner for JMeter, Gatling, and Selenium scripts. Evaluat needs no scripts: the journey is built in a visual step editor, and every virtual user runs in a real browser with Core Web Vitals and session video.
- [Evaluat vs LoadView](https://www.evaluat.com/vs/loadview): LoadView, from Dotcom-Monitor, runs real-browser load with per-test pricing. Evaluat runs a real browser for every user, reports Core Web Vitals, can generate an Executive Summary, and holds customer test content in UK and EU infrastructure.
- [Evaluat vs Locust](https://www.evaluat.com/vs/locust): Locust is an open-source, Python-scripted protocol load tester. Evaluat runs a real browser for every user with no code, capturing the rendered experience Locust never executes.
- [Evaluat vs OctoPerf](https://www.evaluat.com/vs/octoperf): OctoPerf runs JMeter-based protocol load at scale with a hosted UI. Evaluat runs a real browser for every user and reports Core Web Vitals, Apdex, and per-session video, network, and console logs.
- [Evaluat vs Web Performance Load Tester](https://www.evaluat.com/vs/web-performance): Web Performance Load Tester is a self-hosted protocol load tool. Evaluat is hosted, runs a real browser for every user, and can distil a run into an Executive Summary (generated on demand).

## Blog (concepts and methodology)

- [Blog](https://www.evaluat.com/blog): The blog hub: performance testing guides, Core Web Vitals explainers, testing-type comparisons, and ecommerce load-testing writeups, organised into per-category archives.

- [What is load testing?](https://www.evaluat.com/blog/what-is-load-testing): Load testing is a way to measure how a website or app behaves when many people use it at the same time. You simulate a realistic crowd of virtual users, send that traffic at the system, and watch whether pages stay fast and requests keep succeeding. It matters because slow pages cost real money. Research by Google and Deloitte found that improving mobile speed by just a tenth of a second lifted retail conversions by more than eight percent, and pages that take longer than three seconds to load lose over half of their mobile visitors. Every load test follows the same shape: you build a scenario that mirrors a real user journey, apply traffic through a ramp, a plateau, and a ramp down, then read the results as percentiles like p95 and p99 rather than averages, because the slow tail is where failures hide. Size the test from real concurrency, not total users: start from your peak concurrent sessions and add twenty to fifty percent of headroom. And remember the difference between the server and the page: protocol-level tools measure how fast the server answers, while real-browser testing captures what visitors actually see, including Core Web Vitals. Test before a launch or a sale, then keep testing every release.
- [Playwright for performance testing: can a browser automation tool drive virtual users?](https://www.evaluat.com/blog/playwright-performance-testing): Playwright can measure performance, but it can't generate load on its own. Because it drives a real browser, every run records what a user actually experiences, including Core Web Vitals like Largest Contentful Paint and Interaction to Next Paint. What it lacks is any concept of a virtual user, so simulating a crowd takes an orchestrator like Artillery, which launches many browsers, ramps the traffic, and aggregates the results. The catch is cost. A protocol virtual user is a lightweight HTTP client needing just a few megabytes of memory, which is why a tool like k6 can drive tens of thousands of users from one machine. A real browser needs hundreds of megabytes and roughly one processor core each, so the same machine runs dozens to low hundreds of browsers, and fifty to a hundred concurrent sessions is usually enough to characterize the experience. Push past what the machine can feed and the browsers starve, which distorts the very metrics you came to measure. The practical pattern is a hybrid: k6's own guidance suggests keeping browser users to about ten percent of the load while protocol traffic carries the rest. And avoid the classic mistakes: reusing the same login for every user, under-provisioning the generator, and judging the test by server numbers alone. Use a protocol tool for raw volume, size the rig for the browsers you run, and put a real browser on the journey that carries your revenue.
- [Where does performance testing fit in an agile release cycle?](https://www.evaluat.com/blog/performance-testing-agile-release-cycle): Performance testing fits an agile release cycle when you stop looking for one place to put it and place a right-sized check at every stage instead. Think of a vehicle: you glance at the dashboard every drive, check the tyres before a long trip, and book a full inspection once a year. Same idea here: cheap benchmarks and single-page audits run on every commit, an integration load test runs nightly or per feature, a realistic real-browser load test runs at the pre-release gate, and monitoring watches production. The squeeze is structural: a heavy performance phase has nowhere to live in a two-week sprint, so it slides to the end, then to never. And that's the expensive choice. A widely cited study by the US National Institute of Standards and Technology put the annual cost of inadequate testing at nearly sixty billion dollars, with more than a third of it avoidable through earlier testing, and when Vodafone improved Largest Contentful Paint by about thirty percent, its sales rose eight percent. Ownership matters as much as tooling: developers own the inline checks, a QA or performance engineer owns the gate, operations owns production, and the product owner sets the acceptance criteria, because when everyone owns performance, no one does. Add performance to your Definition of Done, tie the rigor to risk, so checkout gets the full treatment and a copy change doesn't, and give every stage a named owner.
- [Performance testing: the complete guide](https://www.evaluat.com/blog/performance-testing-guide): Performance testing is the practice of measuring how a software system behaves under demand: how fast it responds, how stable it stays, and how well it scales as traffic grows. It is an umbrella term. Load testing checks expected peak traffic, stress testing pushes past the breaking point, spike testing throws a sudden surge, and soak testing holds a moderate load for hours to catch problems like memory leaks. Every test measures two layers. Server-side metrics cover response time, read as percentiles like p95 and p99, plus throughput and error rate. Experience metrics are the Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. They can only be measured in a real browser, and they matter because a server can answer in fifty milliseconds and still ship a slow page. The process is a loop: set budgets, build a realistic scenario, run the test, find the bottleneck, fix it, and run it again. Tools split into two families: protocol-level tools like k6 and JMeter that measure the server efficiently at high concurrency, and real-browser tools that capture what users actually experience. Match the weight of the test to the stage: cheap checks on every change, a real-browser load test before a release, and monitoring in production.
- [How to improve CLS: a step-by-step optimization guide](https://www.evaluat.com/blog/how-to-improve-cls): To improve Cumulative Layout Shift, or CLS, find what moves on the page and reserve its space before it loads. Almost every layout shift is the same bug: an element arrives without a box held for it, so everything below it jumps. It's the easiest Core Web Vital to fix, and the numbers show both sides: in the 2025 Web Almanac, eighty-one percent of mobile pages already pass CLS, the best rate of the three Vitals, yet sixty-two percent still ship at least one image without dimensions. The fixes come in priority order. First, give every image and video an explicit width and height, or reserve the box with the CSS aspect-ratio property; that's usually the biggest win. Then hold space for ads, embeds, and iframes with a minimum height, since third-party content loads late and on someone else's schedule. Stop injected things like cookie banners from pushing the page: reserve a placeholder or overlay them instead, and remember that shifts within half a second of a user interaction don't count against you. Tame font swaps by sizing the fallback font to match the web font, and animate with transform rather than layout properties. The payoff is documented: Yahoo Japan News cut CLS from roughly point two to zero and saw page views per session rise fifteen percent. Finally, verify the fix with real-user data at the 75th percentile, on mobile, not from one fast lab load on your desk.
- [How to improve INP: a step-by-step optimization guide](https://www.evaluat.com/blog/how-to-improve-inp): To improve Interaction to Next Paint, or INP, find your slowest interaction, split its latency into three phases, input delay, processing duration, and presentation delay, and fix the phase that owns the most time. Most teams tune the click handler, and most of the time the handler isn't the problem: a long task was already running on the main thread when the user clicked, so the interaction had to wait before the handler could even start. That's why the highest-leverage fix is breaking long tasks into smaller pieces and yielding to the main thread between them, ideally with the browser's newer scheduler yield API and a setTimeout fallback for browsers that don't support it yet. It works: the retailer Trendyol used exactly that pattern to cut its mobile INP in half, from nearly a second to around half a second. Responsiveness is largely a mobile problem, with seventy-seven percent of mobile sites passing INP against ninety-seven percent on desktop in the 2025 Web Almanac. The rest of the playbook: trim event handlers so only the visual-critical work runs synchronously, audit and defer third-party scripts, batch DOM reads and writes, and suspect hydration when the first tap is the slowest. Then verify the fix in the field, at the 75th percentile rather than the average, because INP reports your slowest interactions, and a lab tool can't measure it on a cold load at all.
- [How to improve LCP: a step-by-step optimization guide](https://www.evaluat.com/blog/how-to-improve-lcp): To improve Largest Contentful Paint, or LCP, find the element that paints last, split its time into four phases, and fix the biggest phase first. On most pages that biggest phase isn't a heavy image, it's a late start: the browser simply doesn't begin loading the hero image early enough. According to the 2025 Web Almanac, only about sixty-two percent of mobile pages have a good LCP. And the data backs the late-start diagnosis: most origins with poor LCP spend less than ten percent of their LCP time actually downloading the image, while the request sits delayed on the client for roughly one point three seconds at the seventy-fifth percentile. So the cheapest, highest-leverage fix is making the LCP image start immediately: reference it in the initial HTML, never lazy-load it, and mark it high priority. After that, cut Time to First Byte with caching and edge delivery, shrink the download with modern formats like AVIF, clear render-blocking scripts and styles, and consider prerendering the likely next page with the Speculation Rules API; one site cut LCP by nearly eighteen percent that way. Finally, verify the fix where it counts: in field data, at the seventy-fifth percentile, and under realistic load, because Time to First Byte rises as traffic climbs, and a green score in a quiet lab isn't a green score on sale day.
- [What is an Apdex score? Measuring user satisfaction in performance testing](https://www.evaluat.com/blog/what-is-an-apdex-score): An Apdex score, short for Application Performance Index, is a single number between zero and one that summarizes how satisfied users were with response times. You set a target time called T, and the formula sorts every measured request into three buckets: satisfied requests, at or under T, count fully; tolerating requests, up to four times T, count half; and frustrated requests count zero. Add them up, divide by the total, and you have the score. For example, out of a thousand requests, eight hundred satisfied and one hundred fifty tolerating gives a score of about 0.88. A common rating scale treats anything from 0.94 up as excellent and anything below 0.5 as unacceptable, but those bands are a vendor convention, and a score only means something next to its target: a 0.95 against a generous ten-second T can hide a worse experience than a 0.85 against a strict one-second T. Two habits keep the number honest. Choose T per action, based on when users stop feeling that action is fast, and then keep it fixed across runs, so a falling score always means the app got slower rather than that you moved the goalposts. And never read Apdex alone: two very different distributions can produce the same score, so keep percentiles like p95 and p99, the error rate, and per-page detail behind it. Used that way, Apdex is a headline the whole team can track, with the diagnosis sitting underneath.
- [Core Web Vitals at load, explained](https://www.evaluat.com/blog/core-web-vitals-load-testing): Core Web Vitals at load means measuring Google's three page-experience metrics, Largest Contentful Paint, or LCP, Interaction to Next Paint, or INP, and Cumulative Layout Shift, or CLS, while many people use the site at once, not during a single-user audit. The numbers move because concurrency shifts the bottleneck from the browser to shared infrastructure. Time to first byte grows as the server queues requests, and since it sits at the front of LCP, a page comfortably under the two and a half second threshold for one user can cross it at peak. INP degrades when interactions wait on a busy backend, or when slower loading delays hydration. CLS is the steadiest of the three, because layout shifts are mostly structural, though late-arriving resources can still expose them. This matters commercially: when redBus improved INP on its search page by about seventy percent, it recorded a seven percent increase in sales. Yet single-user lab tools miss all of this by construction, and in 2024 under half of mobile sites passed all three Vitals. Measuring at load takes a real browser for every virtual user, isolated instances, tests run from the region closest to your customers, and per-session capture. And if INP matters, the scenario has to perform real clicks, because a page that only loads has nothing for INP to measure. Measure at the concurrency you actually serve, per URL, at the 75th percentile rather than the mean.
- [Interaction to Next Paint (INP), explained for engineers](https://www.evaluat.com/blog/interaction-to-next-paint): Interaction to Next Paint, or INP, is the Core Web Vital that measures how quickly a page responds to input. For every click, tap, and key press during a visit, the browser times the full delay from the action to the next frame painted on screen, then reports your slowest interaction as the page's score. Each interaction breaks into three phases: input delay, processing, and presentation. INP replaced First Input Delay in March 2024, and it's much stricter, because First Input Delay only timed the wait before the first interaction's handler started running. A good INP is two hundred milliseconds or less at the seventy-fifth percentile of visits, and anything over five hundred is poor. It's largely a mobile problem: in 2024, ninety-seven percent of desktop sites had good INP against seventy-four percent of mobile sites, because slower phone CPUs stretch every phase. The usual culprits are long tasks hogging the main thread, heavy event handlers, third-party scripts, and hydration in server-rendered apps. Fixing it pays off: after improving INP by seventy-two percent, redBus reported a seven percent increase in sales. One catch to remember: a standard lab page load can't measure INP at all, since a cold load has no interactions to time. So measure it the way users feel it: in a real browser, performing real interactions, at the concurrency you expect.
- [Core Web Vitals: why lab scores differ from real users](https://www.evaluat.com/blog/core-web-vitals-lab-vs-field): Lab data and field data measure the same page in two different ways, which is why they rarely match and aren't meant to. A lab score, from a tool like Lighthouse, is one synthetic page load on a fixed device and network. Field data is the spread of real visits, scored at the 75th percentile over a rolling twenty-eight day window, and it's the number your users live with and the one Google Search ranks on. Four differences do most of the damage. A lab run is a single sample while the field is a whole distribution. Lighthouse deliberately throttles to a slow connection and a mid-tier phone's CPU, so the lab number can land on either side of the field result. A lab run loads cold and never clicks, so Interaction to Next Paint, or INP, gets estimated by a proxy rather than measured. And the lab server is idle, while real traffic arrives in volume. The gap is expensive: in the 2024 Web Almanac's field data, INP passed on ninety-seven percent of desktop sites but only about three quarters of mobile ones, and research by Google and Deloitte found a tenth of a second of mobile speed lifted retail conversions by more than eight percent. The advice: trust both, for different jobs. Watch lab data during development, treat field data as ground truth, and run a real-browser load test before releases to cover the load-driven gap neither one sees.
- [Why average response time misleads you: reading p95 and p99](https://www.evaluat.com/blog/p95-p99-response-time): The p95 response time is the value ninety-five percent of your requests come in under, and the p99 draws the same line at ninety-nine percent. They matter because the average is a blend that matches no actual user. Take a hundred requests where ninety return in a hundred milliseconds and ten are slow: the average works out to around four hundred and twenty milliseconds, which describes nobody, while the p95 shows one visitor in twenty waited almost three seconds and the p99 shows one in a hundred waited over five. That tail is where the money leaves: research from Akamai and SOASTA found a hundred-millisecond delay cut conversions by seven percent, and more than half of mobile visitors abandon a page that takes over three seconds. The tail also compounds with scale. In Google's famous example, a server that's slow just one time in a hundred, feeding a page that calls a hundred servers in parallel, leaves nearly two out of three page loads waiting on a straggler. So target p95 for most user-facing budgets, reach for p99 where one slow request loses a sale, like checkout, and never average percentiles together. And check how your load test measures: coordinated omission can make a tool report a healthy p99 under fifty milliseconds while production shows nearly two seconds. Read the median, p95, and p99 together, set your targets at the percentile, and when one turns red, dig into the session behind it.
- [8 metrics every performance test report should include](https://www.evaluat.com/blog/performance-test-report-metrics): A performance test report should answer three questions in order: did the system keep up, how slow was it really, and what did the people using it actually experience. Eight metrics cover them: active virtual users over time, throughput, error rate, response time percentiles, Time to First Byte, Core Web Vitals, an Apdex score, and a per-URL breakdown. The stakes are real: a Deloitte study for Google found that improving mobile speed by a tenth of a second lifted retail conversions by more than eight percent, and Portent's analysis of over one hundred million page views found a one-second site converting business-to-business visitors at roughly three times the rate of a five-second one. The biggest trap is the average: a mean hides the slow tail, so read p50, p95, and p99 together, because the slowest few percent are often your highest-value sessions. Time to First Byte, healthy at eight hundred milliseconds or less, rises first when a backend starts queuing under load, while Core Web Vitals like Largest Contentful Paint capture what the browser actually renders, which server metrics can't see. And never trust a site-wide figure: a healthy overall number can hide one failing checkout page. Set your benchmarks before the run, keep them steady across runs, break everything down per URL, and open the slowest sessions rather than the average, because that's where the regression that costs a conversion is hiding.
- [Largest Contentful Paint (LCP), explained for engineers](https://www.evaluat.com/blog/largest-contentful-paint): Largest Contentful Paint, or LCP, is the time from when navigation starts until the largest content element in the viewport finishes rendering, usually the hero image or product photo. It's one of Google's three Core Web Vitals, and a good score is two and a half seconds or less at the seventy-fifth percentile of real page loads; above four seconds is poor. That percentile does real work, because a flattering average can hide a slow quarter of visits, and in 2024 only fifty-nine percent of mobile pages had a good LCP. LCP isn't one number but the sum of four phases: Time to First Byte, resource load delay, load duration, and render delay. The counterintuitive finding is that on most slow pages the download isn't the problem; the browser starts fetching the image too late. Origins with poor LCP typically spend less than ten percent of their LCP time downloading the image, while the request sits delayed on the client for around one point three seconds. So find the LCP element in DevTools, split its time into the four phases, and fix the biggest one first, which is usually the late start rather than the file size. The payoff is real: Vodafone improved LCP by thirty-one percent and saw an eight percent increase in sales. And measure where it actually degrades: in field data at the seventy-fifth percentile, and under real load, because Time to First Byte swells as the server queues requests.
- [API performance testing vs browser performance testing: which your QA strategy needs](https://www.evaluat.com/blog/api-vs-browser-performance-testing): API performance testing and browser performance testing measure different layers of the same stack, and most QA strategies need both. An API test drives traffic straight at your servers and reports latency, throughput, and error rates as concurrency climbs; it's the cheapest way to find the backend's breaking point. A browser test runs a real browser, so it captures the rendering, JavaScript, and third-party tags that decide how fast a page actually feels, including Core Web Vitals like Largest Contentful Paint, or LCP. Here's why one can't stand in for the other: a fast API doesn't mean a fast page. In Catchpoint's 2025 benchmark, the app with the fastest server measured, replying in about fifty milliseconds, still left users waiting roughly eight seconds for a usable page, because over a hundred JavaScript files had to download and run first. And in the 2025 Web Almanac, fewer than half of mobile sites passed all three Core Web Vitals, almost all of it decided in the browser after the server had already replied. The practical advice: sequence the two by where your risk lives. Gate every pull request with fast, cheap API checks, then run a browser test at realistic concurrency before release, so both the engine and the experience are proven before the traffic arrives.
- [Performance regression testing: making Core Web Vitals a CI/CD release gate](https://www.evaluat.com/blog/performance-regression-testing): Performance regression testing compares every new build against a known-good baseline and fails the build when a change makes pages measurably slower. It matters because speed doesn't stay fixed: Google's research found most performance improvements regress within six months, and a Deloitte study for Google linked a tenth of a second of mobile speed to a conversion lift of more than eight percent. The gate is built on Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Start by measuring your main branch three to five times and keeping the median, because Google notes the median of five runs is about twice as stable as one. Then set each budget at that baseline plus a small tolerance, roughly ten percent, so a page that slides from good to slightly worse still fails, even while it's inside Google's absolute thresholds. Wire the check into your pipeline so a pull request that busts a budget shows a red check naming the page and the metric. Two blind spots remain. A cold page load has no interactions, so it can't measure Interaction to Next Paint; you have to script the clicks. And a lab run is one user on a quiet server: in the worked example, a product page held just over two seconds for a single user but climbed to nearly three and a half at five hundred concurrent users. So baseline your main branch, set budgets, gate every pull request, and add a real-browser load stage before release.
- [Load testing vs stress testing vs performance testing: how the three actually differ](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing): Performance testing is the umbrella term, and load and stress testing are two types inside it that ask opposite questions. Load testing checks whether your system survives the traffic you actually expect: you ramp virtual users to your expected peak, hold it, and confirm response times, throughput, and error rates stay within target. Stress testing deliberately pushes past that point to find where the system breaks, how it fails, and how long it takes to recover; there's no pass line, because the goal is to find the ceiling before a real surge does. They're a sequence, not a choice: run load first for the baseline, then stress to find the edge. Two more types round out the family: spike testing throws a sudden surge at the system, and soak testing holds a moderate load for hours to surface slow leaks. Whichever you run, read the results as percentiles like p95 and p99, because averages hide the slow tail. The stakes are well documented: research by Google and Deloitte found a tenth of a second of mobile speed lifted retail conversions by more than eight percent, and pages that load in one second convert at just over three percent, falling to about one percent by three seconds. One blind spot applies to all of it: most tools measure how fast the server answers, not what the user sees, so for customer-facing journeys put a real browser in the loop and capture Core Web Vitals under load.
- [What is spike testing? Preparing for traffic surges and flash sales](https://www.evaluat.com/blog/what-is-spike-testing): Spike testing hits a system with a sudden, extreme jump in traffic, holds it briefly, then drops it just as sharply. It measures two things at once: whether the system survives the surge, and how fast it recovers afterward. What defines a spike test isn't how much load arrives, but how abruptly; a gentle climb to a big number is just a load test wearing a spike's name. That abruptness is what real events look like. On a recent Black Friday, online shoppers spent around twelve and a half million dollars every minute at the midday peak, and one documented flash sale saw traffic climb more than tenfold in two minutes. Don't assume the cloud saves you either: reactive autoscaling takes time to launch and warm new servers, and a surge that arrives in seconds can outrun a scaler that reacts in minutes, while caches sit cold and connection pools hit their limits. A good spike test sizes the surge to a real event rather than a round number, drives a realistic journey through product pages and checkout instead of hammering the homepage, and watches four signals: error rate, p95 and p99 response times, throughput, and recovery time. The recovery half matters as much as the surge, because a system can survive the spike and then stay degraded with a queue backlog long after the crowd has gone. Run a spike test before any flash sale, product drop, or campaign, again after infrastructure changes, and on a schedule if you run recurring sales.
- [Soak testing explained: catching slow degradation and memory leaks over time](https://www.evaluat.com/blog/soak-testing): Soak testing, also called endurance testing, holds a steady, realistic load against a system for hours or even days to catch the problems that build up slowly: memory leaks, resource exhaustion, and gradual performance decline that a short test ends too soon to see. Where a load test asks whether you can handle peak traffic, a soak test asks whether you can keep handling everyday traffic. It's about duration, not intensity, so you run it at average production load rather than peak. The signature you're hunting is a resource that climbs and never comes back down. Healthy memory rises and falls in a sawtooth as the garbage collector reclaims it; a leak shows up as a baseline that drifts upward hour after hour until the process slows or dies. How long should it run? Match the test to how long your system runs untouched in production: four hours is a reasonable first test, eight to twenty-four hours is common, and systems that must survive an unattended weekend are often soaked for seventy-two. The stakes are real: in one large survey, more than ninety percent of mid-size and large enterprises said a single hour of downtime costs over three hundred thousand dollars. And don't forget the front end, because a browser tab left open all day degrades too. So pick a realistic load, hold it, watch every resource trend across the whole run, and treat any line that never returns to baseline as the bug to chase.
- [Stress testing a website: how to find the breaking point before your users do](https://www.evaluat.com/blog/stress-testing-a-website): Stress testing a website means deliberately pushing it past the traffic it was built for, to find the point where it breaks and to watch how it fails. Unlike a load test, which confirms you handle your expected peak, a stress test keeps raising the load until something gives, so the breaking point becomes a number you own instead of a surprise your users find during a sale. And finding it first matters, because research from Google found the chance of a bounce rises by about a third as a page slows from one second to three. The method is a loop. Start with a baseline load test at expected peak so you know what healthy looks like. Then ramp well past that, often two to ten times peak, watching four signals together: error rate climbing, p95 and p99 response times spiking, throughput flattening, and timeouts appearing. The breaking point is where several move at once, not the first slow request. How it breaks matters too: graceful degradation sheds load and stays up for most users, while a hard failure returns errors to everyone. Then drop the load and time the recovery; a healthy system returns to baseline within a minute or two, and lingering errors point to a queue backlog or a leak. Finally, fix the first bottleneck and run the identical test again to prove the ceiling moved. And remember that request-level tools only measure the server, so when the experience matters, run the test in a real browser.
- [Smoke testing vs performance testing: when a quick pre-release check is enough](https://www.evaluat.com/blog/smoke-testing-vs-performance-testing): Smoke testing and performance testing answer opposite questions. A smoke test is a fast, shallow check that a new build isn't broken: it runs the critical paths, like login and checkout, and confirms they work at all. A performance test measures how the system behaves under realistic load: its speed, its stability, and its ability to scale. Confusingly, smoke test also has a second meaning in the load testing world, where it's a tiny warm-up run at a handful of virtual users that proves your test script works before the full run. Mixing up those two meanings is where most teams go wrong. The right order comes down to cost. A smoke test is cheap enough to run on every build, so it goes first and keeps broken builds out of the pipeline. A performance test is heavier, so you spend it only on builds that survive. A quick smoke check is enough to gate a build or protect a low-traffic internal tool; it's never enough to tell you whether the system holds up under real traffic, and getting that wrong is expensive: one industry survey found a single hour of downtime now costs more than three hundred thousand dollars for over ninety percent of mid-size and large enterprises. So run a smoke test on every build, run a full performance test before releases and known traffic events, and when the user experience matters, measure it in a real browser instead of just timing server responses.
- [Real-browser load testing, explained](https://www.evaluat.com/blog/real-browser-load-testing): Real-browser load testing runs every virtual user in its own real, isolated browser, then drives many of them through a journey at the same time to see how a site holds up under load. Because each browser loads the page, runs the JavaScript, and renders the result, the test records what visitors actually see, not just how fast the server replied. That distinction matters because the server's reply is only the first slice of the wait: after the first byte arrives, the browser still has to parse the HTML, execute scripts, load every third-party tag, and paint the page. Those tags are nearly universal, more than nine in ten pages use at least one third party, and they only run inside a browser, so a request-only test never sees the scripts that most often wreck real experience. There are three tool models to know: HTTP-script tools that fire requests and measure the server, shared-browser tools that run many simulated users inside one browser and distort the results, and real browsers, which capture Core Web Vitals natively along with per-session video, network logs, and console logs. The trade-off is cost: a real browser needs far more compute per user than an HTTP client. The honest answer for most teams is both. Keep a protocol tool for the API surface, where it's genuinely the better instrument, and put a real browser on the customer-facing journey that carries your revenue.
- [Functional testing vs performance testing: two questions every release should answer](https://www.evaluat.com/blog/functional-testing-vs-performance-testing): Functional testing and performance testing answer the two questions every release has to clear: does the software do the right thing, and does it hold up under load? Functional testing checks correctness, with a clear pass or fail, and it runs first, on every build, because there's no point load-testing a checkout that can't complete a purchase. Performance testing checks speed and stability as concurrency climbs, read as a curve against your targets rather than a simple pass or fail, and it belongs before releases and known traffic events. Both matter in money terms. Poor software quality cost the United States an estimated two point four trillion dollars in 2022, and Google's research found that more than half of mobile visits are abandoned when a page takes longer than three seconds to load. With roughly nine in ten organizations now shipping through automated pipelines, both questions have to be answered by automated gates, or they quietly stop being answered at all. There's also a shared blind spot: functional suites run one user with no load, and request-level load tests never render the page, so neither sees what a real customer experiences when the site is busy. Putting a real browser in the loop closes that gap. The advice: gate correctness on every commit, run a load test at expected peak before launch, and for revenue-critical journeys, measure Core Web Vitals in a real browser rather than guessing from server timings.
- [Best real-browser load testing tools in 2026](https://www.evaluat.com/blog/best-real-browser-load-testing-tools): A real-browser load testing tool drives an actual browser for every virtual user, so the test measures rendering, JavaScript execution, and Core Web Vitals under load, not just how fast the server answers. Genuinely real-browser platforms are rare because browsers are expensive to run at concurrency: a comparison by Dotcom-Monitor puts a typical load injector at up to eight hundred HTTP sessions but only ten to twelve headless browser sessions, and one measured workload found a single Playwright browser user consuming roughly as much as two hundred protocol users. Of the thirty-nine tools screened for this list, twenty-five can genuinely drive real browsers under load, and only six use them as the native engine; Evaluat, whose team wrote the list and discloses that upfront, makes the seventh. The field splits into two tiers: native real-browser platforms like LoadView, LoadNinja, BrowserStack, BrowserUp, Loadero, and AppLoader, and protocol tools like k6, Artillery, and NeoLoad that added a browser mode for a slice of users. One famous name is deliberately absent: Gatling loads at the protocol level only, by its own account. The advice is to pick by question, not by brand. Use protocol tools for raw server capacity, reach for real browsers when you need Core Web Vitals and journey evidence under load, and pair the two when your traffic is mostly APIs with a front-end slice.
- [Load testing a headless or Hyvä storefront](https://www.evaluat.com/blog/load-testing-headless-hyva-storefront): A headless storefront decouples the frontend from Magento and talks to commerce services through APIs, while Hyvä is something different: a lighter Magento theme that keeps server-rendered templates but replaces most of Luma's JavaScript stack. Both still need two kinds of testing, browser measurement for the render and capacity testing for the backend, just for different reasons. On a headless build, the server's response is often a small fraction of what the customer waits for: the browser still has to download the JavaScript bundle, run it, hydrate the page, and work through chains of dependent GraphQL requests. The median page now ships over half a megabyte of JavaScript on mobile, and main-thread blocking time at the seventy-fifth percentile is nearly three seconds on mobile against roughly a quarter of a second on desktop. Protocol load tools stop exactly where that work begins; JMeter's own FAQ says it doesn't process JavaScript. Hyvä attacks the problem from the other end by removing most of the JavaScript, and it has grown past six thousand four hundred live stores, but it's a frontend theme: it doesn't remove Magento's PHP and database from checkout. So load test the rendered journey in real browsers, watch Interaction to Next Paint for hydration cost, follow the GraphQL waterfall in the network logs, test the checkout ceiling as its own separate question, and keep a protocol tool for the bare API.
- [Why your Shopify store slows down under load](https://www.evaluat.com/blog/shopify-store-slow-under-load): Shopify's platform genuinely scales, and that's the trap. Its cached storefront is served from a global content delivery network, and Shopify's own data shows nearly ninety percent of shops on its latest themes hitting good Core Web Vitals, against under half of mobile sites across the web. So why does a store still crawl during a sale? Because the theme, the apps, and the third-party tags a merchant adds all run in each shopper's own browser, and no cache can do that work for them. Two costs compound at peak. First, the render tax is paid per device and never amortizes: the median mobile page spends nearly two seconds with its main thread blocked, more than twenty times the desktop figure, and the slowest devices show up in their largest numbers exactly when you're busiest. Second, the app and tag servers your scripts call serve thousands of sites at once, so your sale peak is their peak too. An HTTP load test misses all of this because it never opens a browser: in one benchmark, a server answered in about fifty milliseconds while the page took more than eight seconds to finish loading. To test safely, drive real browsers through the storefront and cart you control, not Shopify's sandboxed checkout, point them at a development store rather than your live shop, give every virtual user its own cart, and read Core Web Vitals per page and per session. Test the store you assembled, not the platform underneath.
- [WooCommerce performance testing: find your store's limit under load](https://www.evaluat.com/blog/woocommerce-performance-testing): WooCommerce scales, but not evenly. The cached catalog can serve thousands of visitors cheaply, while the pages shoppers spend money on, the cart, the checkout, and the account pages, are non-cacheable by design: they run PHP and MySQL on every request. Think of a printed menu that works for the whole room while every order still goes to a kitchen with a fixed number of cooks. On budget hosting that kitchen is a small pool of PHP workers, often with no persistent object cache, and every request carries the weight of autoloaded options, plugin hooks, and the mini-cart's admin-ajax calls. A normal day hides this because most visitors browse cached pages. A sale changes both numbers at once: more people arrive, and more of them head for checkout, so requests queue, response times climb, and the slowest time out as errors. That's also why your last load test may have said everything was fine: pointing traffic at the homepage just tests the cache, and an HTTP-only test never runs the theme and plugin JavaScript or records Core Web Vitals like Largest Contentful Paint. Because WooCommerce is self-hosted, you can test the whole journey, including checkout, unlike a hosted platform. So test a staging copy that mirrors production, check your host's terms first, script the full journey from product page to sandboxed checkout with unique data per virtual user, run it in a real browser, and ramp past expected peak until you find the concurrency where checkout stops holding. Then re-test after every plugin change.
- [Why Magento checkout dies first under load](https://www.evaluat.com/blog/magento-checkout-slow-under-load): Magento checkout fails first under load because it's the one part of the store the cache can't protect. Catalog pages are served from a stored copy, so the homepage costs the origin almost nothing, but every cart and checkout request is rebuilt from scratch by PHP and written to MySQL. Think of a supermarket: a thousand shoppers can browse the aisles without extra staff, but every buyer has to pass through a staffed till. Sales make it worse in a compounding way: if traffic goes up five times while the share of visitors checking out triples, the origin is doing fifteen times its normal work even though analytics only shows five. This isn't theoretical; one agency watched leading Magento retailers lose over a million dollars in Black Friday sales, with add-to-cart delays of twenty to forty seconds. Inside checkout, four things break, usually in order: PHP workers fill up, database rows contend and deadlock, session locks queue each shopper's own clicks, and slow shipping and payment calls park workers while they wait. Which is why a load test aimed at the homepage says the site is fine: it measured the cache, not the store. So script the full journey from browsing to payment, give every virtual user its own account and cart, ramp past your expected peak, read the results per checkout step, and re-test before every sale, because roughly fifteen percent of shoppers who abandon an order cite the site crashing or showing errors.

## Key facts

- Browsers: real browsers in the cloud.
- Test regions live today: the UK and the EU. Further regions are added when customers ask.
- What every test report contains: five views (Overview, URL performance, Sessions with video, Console logs, Network logs). On Growth plans and above, an Executive Summary can be generated on demand: a plain-language verdict with a health score, findings ranked by severity, and recommended fixes. Reports have stable read-only shareable URLs. Aggregated metrics export as CSV.
- Executive Summaries: generated on demand per run; Growth includes 2 per month and Scale 10; not available on Starter.
- Pricing: sales-led and sized by virtual user-minutes (one virtual user running for one minute equals one VU-minute). Tiers are Starter, Growth, and Scale, billed monthly or annually. There is no public dollar pricing and no self-serve trial; onboarding is a 30-minute demo on the customer's real site.
- Data location: test data resides in the region the test ran in: run a test in the UK and its data stays in the UK; run it in the EU and it stays in the EU. Exact storage layout for each artifact type is described in the Privacy Policy, DPA, and Sub-processors list. If you have a specific residency or compliance requirement, talk to us before you start.
- Architecture note: Evaluat's difference is isolation, concurrency, and per-session forensics: every virtual user runs in its own browser instance under load, with session video, network logs, and console logs retained. Evaluat tests user-facing applications rather than APIs or non-HTTP protocols.
- Magento: Evaluat load tests Magento and Adobe Commerce stores in real browsers, including Hyvä and headless storefronts. Cart, checkout, and login are the uncacheable paths that saturate first under load, so tests walk the full browse-to-checkout journey with a unique cart per virtual user rather than requesting cached catalog URLs.
- Customers: Teams we've worked with include Auping (bed manufacturer), terStal (fashion retailer), roadmap.sh (developer learning platform), and Tablething.

## Reference

- [Pricing](https://www.evaluat.com/pricing)
- [FAQ](https://www.evaluat.com/faq)
- [About](https://www.evaluat.com/about)
- [Ahmad Farzan, founder and author](https://www.evaluat.com/authors/ahmad-farzan): Founder of Evaluat and author of the blog. Background in building and load-testing Adobe Commerce and Magento storefronts.
- [Agency Partner Program](https://www.evaluat.com/partners)
- [Book a Demo](https://www.evaluat.com/demo)
- [Contact](https://www.evaluat.com/contact)

## Legal

- [Privacy](https://www.evaluat.com/privacy)
- [Terms](https://www.evaluat.com/terms)
- [Data Processing Agreement](https://www.evaluat.com/dpa)
- [Sub-processors](https://www.evaluat.com/sub-processors)