---
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-10-11"
---

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)

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 <https://www.evaluat.com/tools/downtime-cost-calculator> 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](https://www.evaluat.com/reports/examples)

[A plain-language verdict you can read on the way into the meeting, and what to fix first.](https://www.evaluat.com/reports/examples)

[Tour a real report](https://www.evaluat.com/reports/examples)

### [For the CMO](https://www.evaluat.com/solutions/ecommerce-performance-testing)

[Proof the landing page holds at campaign traffic before the spend goes out.](https://www.evaluat.com/solutions/ecommerce-performance-testing)

[Ecommerce performance testing](https://www.evaluat.com/solutions/ecommerce-performance-testing)

### [For the engineering lead](https://www.evaluat.com/#engineering)

[The deep half of this page is yours: what gets captured on every run, and how to check our work.](https://www.evaluat.com/#engineering)

[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. Testing Suite, now in early access, re-runs the same scenarios as post-deploy smoke checks. Monitoring is planned and will run them around the clock. One definition, one place to maintain it.

### [Performance Testing](https://www.evaluat.com/product/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.](https://www.evaluat.com/product/performance-testing)

[See Performance Testing](https://www.evaluat.com/product/performance-testing)

### [Testing Suite Early access](https://www.evaluat.com/product/testing-suite)

[Re-run the same scenarios as post-deploy smoke checks. See which journeys failed and where, with session video and logs to fix what broke.](https://www.evaluat.com/product/testing-suite)

[See Testing Suite](https://www.evaluat.com/product/testing-suite)

### [Monitoring Planned](https://www.evaluat.com/product/monitoring)

[Will run your scenarios around the clock from the UK and the EU and alert on Web Vitals regressions, with session video to debug them.](https://www.evaluat.com/product/monitoring)

[See Monitoring](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.

- [![Time to first byte for the same page on a quiet afternoon and on sale day, drawn as stacked bars against Google's thresholds of 0.8 seconds for good and 1.8 seconds for poor. Network travel takes 435 milliseconds both times. Server time is 200 milliseconds when quiet, giving a good TTFB of 635 milliseconds, and 1,400 milliseconds when requests queue, giving a poor TTFB of 1,835 milliseconds.](https://www.evaluat.com/blog/time-to-first-byte-cover.svg)](https://www.evaluat.com/blog/time-to-first-byte)
  ### [Time to First Byte (TTFB), explained](https://www.evaluat.com/blog/time-to-first-byte)
  [Time to First Byte (TTFB) is how long a browser waits between starting to load a page and receiving the first byte of the reply. Good is 0.8 seconds or less. It is not a Core Web Vital, but it is the first slice of every page load and the number that moves first when your server starts to queue.](https://www.evaluat.com/blog/time-to-first-byte)

  [Ahmad Farzan · 8 October 2026](https://www.evaluat.com/blog/time-to-first-byte)
- [![A code freeze calendar for Black Friday 2026 drawn as a timeline from 26 October to 4 December. A feature freeze starts on Friday 30 October, a full freeze starts on Friday 13 November followed by a final load test on the frozen build, Black Friday falls on Friday 27 November within the peak week, and a gradual thaw begins on Tuesday 1 December.](https://www.evaluat.com/blog/black-friday-code-freeze-cover.svg)](https://www.evaluat.com/blog/black-friday-code-freeze)
  ### [What is a code freeze, and should you have one before peak?](https://www.evaluat.com/blog/black-friday-code-freeze)
  [A code freeze does not protect you from the release you shipped in September. It protects the site you last load tested, by stopping changes nobody has proved since. Freeze about two weeks before Black Friday, include tags, configuration and content as well as code, and keep a tested route open for genuine fixes.](https://www.evaluat.com/blog/black-friday-code-freeze)

  [Ahmad Farzan · 7 October 2026](https://www.evaluat.com/blog/black-friday-code-freeze)
- [![Two comparisons of where a page load's wait goes. Upgrading broadband from 100 Mbps to 1 Gbps cuts the transfer of a 2.6 MB page from 0.21 seconds to 0.02 seconds, saving about 0.19 seconds. Shortening each round trip from 140 milliseconds to 30 milliseconds cuts a page that needs ten round trips in a row from 1.4 seconds of waiting to 0.3 seconds, saving 1.1 seconds.](https://www.evaluat.com/blog/latency-vs-bandwidth-cover.svg)](https://www.evaluat.com/blog/latency-vs-bandwidth)
  ### [Latency, bandwidth and round trips, explained](https://www.evaluat.com/blog/latency-vs-bandwidth)
  [Faster broadband does not make a slow website fast. Bandwidth is how much data a connection carries each second; latency is how long one trip takes. A web page needs dozens of small trips, so once a connection passes about 20 Mbps, the number and length of those trips decide the wait, not the size of the pipe.](https://www.evaluat.com/blog/latency-vs-bandwidth)

  [Ahmad Farzan · 3 October 2026](https://www.evaluat.com/blog/latency-vs-bandwidth)
- [![A worked example of sizing a Black Friday load test from last year's analytics. The busiest hour averaged 600 people on the site at once. Multiplying by 2.4 for the peak minutes after the email send gives 1,440, adding 8% growth gives 1,555, and adding 20% headroom gives a load test target of 1,900 virtual users.](https://www.evaluat.com/blog/sizing-black-friday-load-test-cover.svg)](https://www.evaluat.com/blog/sizing-black-friday-load-test)
  ### [How to estimate peak traffic from your analytics](https://www.evaluat.com/blog/sizing-black-friday-load-test)
  [Across the 138 retailers Queue-it tracked, Black Friday 2025 drew 78% more visits than an average October Friday. Your load test needs your own number, and last November's analytics already hold it. Find the busiest hour, find the minutes inside it, scale for growth, and turn the result into virtual users and journeys.](https://www.evaluat.com/blog/sizing-black-friday-load-test)

  [Ahmad Farzan · 3 October 2026](https://www.evaluat.com/blog/sizing-black-friday-load-test)
- [![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)

[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)
