--- title: "Evaluat: Real-Browser Performance Testing with Core Web Vitals" description: "Evaluat is a real-browser performance testing platform: Core Web Vitals under load, plus session video, network logs, and console logs for every virtual user." url: "https://www.evaluat.com/" last_modified: "2026-09-24" --- REAL-BROWSER PERFORMANCE TESTING # Slow pages lose sales. Find yours before your customers do. Your busiest day, rehearsed in real browsers before it happens. You read the verdict; your engineers get the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [Run a free speed test](https://www.evaluat.com/tools/website-speed-test) Teams we've worked with - ![Auping](https://www.evaluat.com/logos/auping.svg) - ![terStal](https://www.evaluat.com/logos/terstal.svg) - ![roadmap.sh](https://www.evaluat.com/logos/roadmap-sh.svg) - ![Tablething](https://www.evaluat.com/logos/tablething.svg) *Simulation of an Evaluat performance test: a cursor walks a storefront from product page to confirmed order while journey steps pass, 200 virtual users ramp up, and Core Web Vitals populate.* What slow costs ## Where slow pages cost you money. A minute of your busiest sale is worth more than a minute of any other day, and most teams have never put a figure on it. Set up the sale you are worried about. The downtime cost calculator is interactive. Open in a browser to use it. That is what half an hour costs you, and it assumes the site actually went down. Usually it does not. It stays up and slows to a crawl at checkout, shedding the same orders without ever registering as an outage. Hard down is a hosting problem. Slow under load is the one a performance test finds, and it is the more common of the two. Most load testing tools just ask your server if it answered. Evaluat opens your shop in many real browsers at your forecast peak, like real customers on real laptops, and watches what they actually see. Checkout at peak A checkout that slows under peak traffic sheds buyers at the exact moment you have the most of them. Evaluat rehearses your checkout at Black Friday numbers in real browsers and shows the point where it starts to drag. [More on checkout under load](https://www.evaluat.com/use-cases/checkout-performance-testing). The surge, not the average The email goes out, or the spot airs, and everyone arrives in the same five minutes. That shape breaks sites that handle a busy day fine. Rehearse the surge, not just the volume. [More on peak readiness](https://www.evaluat.com/use-cases/peak-readiness). The third-party tax Analytics, reviews, chat, A/B tests. Each tag is small; together they tax every page view. The report shows which one costs you the most, so you can decide whether it earns its keep. Speed and search Google uses field page-experience signals, including [Core Web Vitals](https://www.evaluat.com/blog/core-web-vitals-load-testing), among other ranking factors. Evaluat measures related diagnostics under controlled load, so you can find and fix the slow pages that fight uphill for the traffic you don't pay for. Teams run the same rehearsals for capacity planning, release validation, regional comparisons, and forensic debugging. Running a store? Start with [ecommerce performance testing](https://www.evaluat.com/solutions/ecommerce-performance-testing). [How the testing works](https://www.evaluat.com/how-it-works) The report · one real run ## A verdict you can read. Evidence your engineers can act on. > "The site stayed up and served every request under 200 users, but pages loaded far too slowly and about 1 in 10 shopper journeys did not finish." > > The opening line of this run's Executive Report. Written by the platform, in plain language. ### Written for the meeting, not the war room. A health score, findings ranked by severity, and recommended fixes in plain language. Forward it as it is. [What's in a report](https://www.evaluat.com/reports/examples) ![Evaluat verdict banner: the site stayed up under 200 users but pages loaded far too slowly, with an Apdex of 0.79, health score 0.62, 200 peak users, a 0% error rate, and 35,925 requests.](https://www.evaluat.com/_astro/exec-summary-verdict.BY85lhUn_1BkEhp.webp) ### A failure at peak isn't a percentile. It's a session. Open the session. Watch the moment it broke. The video, the network log, and the console output are there for every virtual user. [How session video works](https://www.evaluat.com/how-it-works#session-recording) ![Evaluat failed session 178.40: status Failed, a 2 minute 8 second duration, the scenario it ran, and the element-not-visible selector error that stopped the journey.](https://www.evaluat.com/_astro/session-detail-top.k6S18gqz_Z1zlkSR.webp) Session 178.40: the step that failed and the selector that timed out. Working with us ## Three steps to a straight answer. 1. step 1 of 3 Build the journey once. On the demo call we assemble your real journeys in the visual editor: home, product, cart, checkout. No scripts, no code. 2. step 2 of 3 Run it at your peak. Real browsers walk those journeys at your forecast traffic, from the UK and the EU, while everything is recorded. 3. step 3 of 3 Read the verdict. Hand off the evidence. You see what held, what slowed, and what broke. Your engineers open the exact sessions behind each finding. Who reads what ## One report. Three readers. For the CEO A plain-language verdict you can read on the way into the meeting, and what to fix first. [Tour a real report](https://www.evaluat.com/reports/examples) For the CMO Proof the landing page holds at campaign traffic before the spend goes out. [Ecommerce performance testing](https://www.evaluat.com/solutions/ecommerce-performance-testing) For the engineering lead The deep half of this page is yours: what gets captured on every run, and how to check our work. [Skip to the engineering section](https://www.evaluat.com/#engineering) For your engineers ## The part your engineering lead will check. Configured once at the project level. Captured for every virtual user. Open any session and see exactly what happened. This is the half your engineering lead will want. The full mechanics, including datasets, popup handlers, and regional execution, are on [How it works](https://www.evaluat.com/how-it-works); it's written for them. ### Test Scenarios - Build a journey once. Reuse it everywhere. - Step-by-step playback with pass/fail per step. [How scenarios work](https://www.evaluat.com/how-it-works#scenarios) ### Core Web Vitals capture - LCP, INP, and CLS for every virtual user, plus FCP. - Aggregated by run, addressable per session and URL. [How Vitals are captured](https://www.evaluat.com/how-it-works#vitals) ### Session Video - Watch any virtual user's browser end-to-end. - Step playback timestamped to the millisecond. [How session video works](https://www.evaluat.com/how-it-works#session-recording) ### Network & Console Logs - Every request and every console message, per user. - Searchable and deduplicated across the whole run. [How log capture works](https://www.evaluat.com/how-it-works#network) ### Five views on the same run. Report views. Pick one to see that view of the run. Overview URLs Performance Sessions Console Logs Network Logs ![Evaluat report Overview: test execution details, an Apdex of 0.79, 200 peak users, a 0% error rate, and the user ramp curve across the run, from a 200-user peak-trading rehearsal.](https://www.evaluat.com/_astro/overview-panel.CnpqSP8l_2cx7ce.webp) ![Evaluat URLs Performance view: per-URL hit counts, status codes, and Core Web Vitals including LCP, CLS, and INP, from a 200-user peak-trading rehearsal.](https://www.evaluat.com/_astro/urls-performance-panel.D8zIljEo_2bzPRA.webp) Every URL in the journey broken out, so you can see exactly which step slowed down under load. ![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. Evaluat is agent-ready: your team's AI agents can run a real-browser speed test over the Model Context Protocol and read the results back, no API key needed. [Developer and agent reference](https://www.evaluat.com/developers) The lineup ## One platform. Three products. Build a scenario once for Performance Testing today. The same scenarios are designed to become CI smoke checks and continuous monitors when Testing Suite and Monitoring ship. Same definition, same forensic detail. ### Performance Testing Real-browser performance tests at your forecast peak. Track Core Web Vitals per session and per URL. Find what breaks before peak does. [Tour the platform](https://www.evaluat.com/product/performance-testing) ### Testing Suite Soon Run the same scenarios as post-deploy smoke checks. Catch Web Vitals regressions before they reach customers, with the per-session detail of a full performance test. [Join the waitlist](https://www.evaluat.com/product/testing-suite) ### Monitoring Soon Run your scenarios continuously from chosen regions. Alert on Web Vitals regressions, with session video to debug them. [Join the waitlist](https://www.evaluat.com/product/monitoring) Keep reading ## Latest from the blog. Guides and engineering notes on performance testing, Core Web Vitals, and peak readiness, for the person who owns the site and the engineer who fixes it. - [![A page load drawn as a waterfall of seven waits in order: DNS lookup, TCP connection, TLS handshake, the server thinking until the first byte, the HTML download, fetching CSS, scripts and images, then layout and paint. The first byte arrives after the fourth wait and the largest paint after the seventh. The server wait is highlighted because it is the one that grows when the site is busy.](https://www.evaluat.com/blog/how-a-web-page-loads-cover.svg)](https://www.evaluat.com/blog/how-a-web-page-loads) ### [What happens when a web page loads: DNS, TLS, TTFB and render](https://www.evaluat.com/blog/how-a-web-page-loads) [Between the tap and the paint there are seven waits, and most speed problems live in exactly one of them. The browser looks up the address, opens a connection, secures it, waits for the server, downloads the page, fetches everything the page asks for, and paints. Learn the order and you can find the slow one.](https://www.evaluat.com/blog/how-a-web-page-loads) [Ahmad Farzan · 24 September 2026](https://www.evaluat.com/blog/how-a-web-page-loads) - [![The concurrent users formula worked through: 12,000 sessions in the peak hour, multiplied by an average session of 5 minutes, divided by 60, gives 1,000 concurrent users. A bar comparison shows how small that is next to the 12,000 sessions in the same hour. Load tests are sized from the people on the site at the same moment.](https://www.evaluat.com/blog/how-many-concurrent-users-cover.svg)](https://www.evaluat.com/blog/how-many-concurrent-users) ### [How many concurrent users can my website handle? (with calculator)](https://www.evaluat.com/blog/how-many-concurrent-users) [Visitors per hour multiplied by session length. That is the whole formula for concurrent users, and most teams have never run it. It tells you how many people are on your site at the same moment, which is the number that loads your servers. How many your site can handle is a second question, and no server specification can answer it.](https://www.evaluat.com/blog/how-many-concurrent-users) [Ahmad Farzan · 23 September 2026](https://www.evaluat.com/blog/how-many-concurrent-users) - [![A first load test as ten steps in four phases. Plan: pick one journey, set a target, size from real traffic, choose where to test and who to warn. Build: script the journey with think time, then smoke test. Run: ramp up and hold, and watch while it runs. Read: read the report, then fix one thing and run it again. The load profile underneath ramps up, holds steady and ramps down.](https://www.evaluat.com/blog/how-to-load-test-a-website-cover.svg)](https://www.evaluat.com/blog/how-to-load-test-a-website) ### [How to load test a website: your first test, step by step](https://www.evaluat.com/blog/how-to-load-test-a-website) [Your first load test should take an afternoon, not a quarter. Pick the one journey that earns money, write down what passing means, size the test from your own analytics, tell the people who need telling, then run a small test before the real one. This guide follows one online store through all ten steps, with the numbers at each.](https://www.evaluat.com/blog/how-to-load-test-a-website) [Ahmad Farzan · 18 September 2026](https://www.evaluat.com/blog/how-to-load-test-a-website) - [![A capacity test steps the load up in plateaus, from 500 to 1,750 virtual users, while the 95th percentile response time is read at each step. Response time stays under the two second target up to 1,250 users, which is the usable ceiling, crosses the target at 1,500, and the site only breaks at 1,750. Capacity is the last step that still meets the target, not the breaking point.](https://www.evaluat.com/blog/what-is-capacity-testing-cover.svg)](https://www.evaluat.com/blog/what-is-capacity-testing) ### [What is capacity testing?](https://www.evaluat.com/blog/what-is-capacity-testing) [Most teams can tell you when their site falls over. Far fewer can tell you when it stops being good enough, and that second number is the one customers feel. Capacity testing, in performance testing, finds it. It measures how many users your site can serve while still meeting the speed and error targets you set in advance.](https://www.evaluat.com/blog/what-is-capacity-testing) [Ahmad Farzan · 18 September 2026](https://www.evaluat.com/blog/what-is-capacity-testing) - [![The same 200 virtual users produce two different workloads: with five seconds of think time between steps they generate a human-shaped load of about 40 actions per second, and with think time removed they hammer the site many times harder. A virtual user is a unit of behaviour, not just a number.](https://www.evaluat.com/blog/what-is-a-virtual-user-cover.svg)](https://www.evaluat.com/blog/what-is-a-virtual-user) ### [What is a virtual user?](https://www.evaluat.com/blog/what-is-a-virtual-user) [A virtual user is a simulated visitor that a load testing tool runs through your site: browsing, pausing, adding to cart, checking out, independently of every other simulated visitor. Get this one definition right, including what a virtual user is not (a person, a request, or your daily traffic), and most first load tests stop going wrong.](https://www.evaluat.com/blog/what-is-a-virtual-user) [Ahmad Farzan · 10 September 2026](https://www.evaluat.com/blog/what-is-a-virtual-user) - [![The four main types of load testing as four traffic shapes: load testing ramps to expected traffic and holds; stress testing climbs until the system breaks; spike testing jumps to a sudden surge and drops back; soak testing holds a steady load for hours. Each shape answers a different question.](https://www.evaluat.com/blog/types-of-performance-testing-cover.svg)](https://www.evaluat.com/blog/types-of-performance-testing) ### [The types of performance testing, and when to use each](https://www.evaluat.com/blog/types-of-performance-testing) [Load, stress, spike, soak: the names get used interchangeably, but each test answers a different question about your site. This guide maps every major type of performance testing to the question it answers and the traffic shape it uses, in one table, with an honest order to run them in. Start with the question, and the right test picks itself.](https://www.evaluat.com/blog/types-of-performance-testing) [Ahmad Farzan · 9 September 2026](https://www.evaluat.com/blog/types-of-performance-testing) [All posts](https://www.evaluat.com/blog) Common questions ## Questions we get asked. ### What is Evaluat? Evaluat is a real-browser performance testing platform. Every virtual user runs in its own isolated browser instance, so you capture Core Web Vitals (LCP, INP, CLS) and Navigation Timing under load, plus full session video, network logs, and console logs for every user. ### Do I need to be technical to use Evaluat? Mostly no. Reports are written in plain language for non-technical readers, and you can generate an Executive Summary when you need the verdict fast. Building a scenario happens in a visual step editor with no scripts; the one technical bit is pointing steps at the right elements with CSS selectors, which is a job for your developer or your agency. The deeper views (session video, network logs, console logs) are there for them when something needs fixing. ### How do I know if we need load testing? Three common signals. A date is coming when traffic multiplies (Black Friday, a product drop, a press or TV moment). You are changing platform, theme, or checkout. Or the site already feels slower during promotions than on a quiet Tuesday. If any of those apply, one rehearsal will tell you where you stand. ### What's in a test report? Five detail views: Overview (aggregate Web Vitals, time-series), URL performance (every URL with its own metrics), Sessions (every virtual user, individually addressable, with video), Console logs (deduplicated and counted), Network logs (every HTTP request, searchable across the run). You can generate an Executive Summary on top: a plain-language verdict with a health score, the key findings ranked by severity, and recommended fixes. [See what a report contains](https://www.evaluat.com/reports/examples). ### How does Evaluat differ from k6? k6 sends HTTP requests and measures how fast your server responds. Evaluat runs real browsers and measures what users actually see: Core Web Vitals (LCP, INP, CLS), plus FCP and the full network and console for every session. Use k6 for API load tests. Use Evaluat for the customer-facing parts of your app. [See all comparisons](https://www.evaluat.com/vs). ### Can Evaluat tell me if my site is ready for Black Friday? Yes. That is the most common first test: a rehearsal of your real journeys (home, product, cart, checkout) at the number of simultaneous visitors you expect at peak. Generate an Executive Summary for the verdict; the session-level detail shows your team exactly what to fix. Black Friday 2026 is November 27, and fixes need shipping time, so the useful testing window closes earlier than it feels. ### Is there a free trial? We don't run a self-serve trial. Every onboarding includes a 30-minute demo on your real site, with a small test run live. The report from that demo is yours to keep, whether you go ahead or not. More answers on the [FAQ page](https://www.evaluat.com/faq). Get a demo Test in real browsers.\ Debug in real sessions. ## Know before November. See it run on your site. 30 minutes, no slides. We run a small test on your real site, a handful of users, and the report is yours to keep either way. [Book a demo](https://www.evaluat.com/demo?intent=performance) [See how it works](https://www.evaluat.com/how-it-works)