# 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 Chrome browser from London or Frankfurt and returns Core Web Vitals (LCP, FCP, CLS, TTFB), an A to F performance grade, and a shareable video report URL.
- 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 (its own memory, CPU, cache, cookies, and network stack), so the contention measured under load is real rather than approximated by a shared-browser model.
- It captures Core Web Vitals (LCP, INP, CLS, FCP) and Navigation Timing 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 (live), Testing Suite (coming soon), Monitoring (coming soon). Build a scenario once; use it as a performance test, a CI smoke check, or a continuous monitor.
- 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 any scale, with Core Web Vitals capture and a five-view forensic report per run. Live now.
- [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. Coming soon.
- [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. Coming soon.
- [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.
- [Changelog](https://www.evaluat.com/changelog): Dated product, tooling, and platform updates, newest first. Entries begin June 2026.

## Comparisons

- [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, and reports Core Web Vitals, Apdex, and 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: a visual recorder captures the journey, 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 and an Executive Summary, and keeps data in the region the test ran in.
- [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 distils each run into an Executive Summary.

## Blog (concepts and methodology)

- [Performance testing: the complete guide](https://www.evaluat.com/blog/performance-testing-guide): The cornerstone guide to the whole discipline: what performance testing is and how it differs from functional testing, the types (load, stress, soak, spike, scalability), the metrics that matter on both the server side (response time percentiles, throughput, error rate, TTFB) and the experience side (Core Web Vitals), the testing process, manual vs automated, the protocol-level vs real-browser tool split, and where it fits in the release cycle.
- [What is performance testing?](https://www.evaluat.com/blog/what-is-performance-testing): A beginner's guide for QA engineers to performance testing under real traffic: what it is, its types, the metrics that matter, and why server response time is not the same as user experience.
- [Load vs stress vs performance testing](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing): How the three actually differ, when to run each, and which one your team needs first, with the real-browser and Core Web Vitals angle most comparisons miss.
- [Smoke testing vs performance testing](https://www.evaluat.com/blog/smoke-testing-vs-performance-testing): Why a quick smoke test that checks a build is not broken is not a performance test, the two meanings of the term, and when a quick pre-release check is enough before you need full load testing.
- [Functional testing vs performance testing](https://www.evaluat.com/blog/functional-testing-vs-performance-testing): The two questions every release must answer, does it do the right thing and does it hold up under load. How the disciplines differ (correctness vs behavior under load, pass/fail vs a degradation curve), when each runs in the pipeline, the common mistakes teams make, and the real-browser gap that neither a functional suite nor a protocol-level load test catches on its own.
- [Stress testing a website](https://www.evaluat.com/blog/stress-testing-a-website): A step-by-step guide to finding the breaking point: set a baseline, ramp past peak, read the failure signals, measure recovery, and fix the bottleneck.
- [What is spike testing?](https://www.evaluat.com/blog/what-is-spike-testing): A beginner's guide to spike testing: a sudden, extreme jump in traffic and an equally sudden drop, how it differs from load testing (gradual peak) and stress testing (gradual climb to the breaking point), the flash-sale and viral events that cause spikes, why reactive autoscaling has launch and warm-up latency that a surge outruns, what to measure during and after the spike (error rate, response time percentiles, throughput, recovery time), and why a real browser captures the white-screen experience a protocol test misses.
- [What is soak testing?](https://www.evaluat.com/blog/soak-testing): A beginner's guide to soak (endurance) testing: holding a steady, realistic load for hours or days to surface what short tests miss, the difference between a true memory leak and unbounded growth, the leak signature (a resource that climbs and never returns to baseline), how long to run one and at what load, common mistakes, and why the front-end experience over a long run is invisible to a protocol-level test.
- [Real-browser load testing](https://www.evaluat.com/blog/real-browser-load-testing): How real-browser load testing differs from HTTP-script and shared-browser models, and when each is the right call.
- [Playwright for performance testing](https://www.evaluat.com/blog/playwright-performance-testing): Whether a browser automation tool can drive virtual users, why each real browser costs hundreds of megabytes and a CPU core against a protocol virtual user's few megabytes, how Artillery turns Playwright into a load generator, and the hybrid that pairs the two.
- [API vs browser performance testing](https://www.evaluat.com/blog/api-vs-browser-performance-testing): The two layers of a performance strategy compared. API performance testing measures backend latency, throughput, and scalability (APIs are 57% of internet traffic, much of it with no UI); browser performance testing measures Core Web Vitals and the rendered experience. Why a 52-millisecond server can still ship an eight-second page, what each layer cannot see, and how to sequence both.
- [8 metrics every performance test report should include](https://www.evaluat.com/blog/performance-test-report-metrics): The eight metrics a complete report needs, grouped by three questions (did it keep up: active users, throughput, error rate; how slow, really: response time percentiles and TTFB; what did users feel: Core Web Vitals and Apdex) plus a per-URL and per-session breakdown for where it broke, each with its benchmark and the mistake to avoid.
- [What is an Apdex score?](https://www.evaluat.com/blog/what-is-an-apdex-score): A beginner's guide to the Application Performance Index: the formula (satisfied plus half the tolerating, divided by the total), the satisfied/tolerating/frustrated buckets defined by a target T and 4T, how to choose T (anchored in the one-second and ten-second limits of human attention), the common rating scale and why it is a vendor convention rather than the standard, the limitations of a single number, and why Apdex works best as a headline on top of response time percentiles and per-session detail.
- [Core Web Vitals at load](https://www.evaluat.com/blog/core-web-vitals-load-testing): Why Core Web Vitals shift under load (LCP rises as the server slows, INP degrades at peak, CLS least), why single-user lab tools miss it, and how to measure them at concurrency in real browsers.
- [Core Web Vitals: lab vs field data](https://www.evaluat.com/blog/core-web-vitals-lab-vs-field): Why a lab score (Lighthouse, one synthetic run on a fixed device and network) differs from real-user field data (CrUX at the 75th percentile): single sample vs distribution, deliberately slow throttling, no interactions for INP, third-party variance, and the traffic load a lab never models. Which view to trust, and when.
- [Performance regression testing in CI/CD](https://www.evaluat.com/blog/performance-regression-testing): How to gate releases on Core Web Vitals: baseline your main branch, set budgets, fail the build when a change regresses, and catch the slowdowns that only appear under load.
- [Where does performance testing fit in an agile release cycle?](https://www.evaluat.com/blog/performance-testing-agile-release-cycle): A stage-by-stage map of performance testing across an agile cycle: budgets in planning, cheap checks every commit, a real-browser load test at the pre-release gate, and monitoring in production, with per-stage ownership and a risk-tiered Definition of Done.
- [Largest Contentful Paint (LCP) explained](https://www.evaluat.com/blog/largest-contentful-paint): What counts as the LCP element, the four phases LCP breaks into (TTFB, load delay, load duration, render delay) and why load delay is usually the bloat, lab vs field measurement, and how to capture LCP under load.
- [Interaction to Next Paint (INP) explained](https://www.evaluat.com/blog/interaction-to-next-paint): What INP measures, why it replaced First Input Delay, and how to test it under load.
- [Why Magento checkout dies first under load](https://www.evaluat.com/blog/magento-checkout-slow-under-load): The cache asymmetry behind sale-day failures: catalog pages are served from full page cache while cart and checkout are non-cacheable by design, so a sale multiplies origin load far faster than traffic grows. The four bottlenecks inside checkout (full page builds with totals collection, database lock contention on quote, stock, and order rows, per-shopper session locking, and synchronous shipping and payment calls exhausting PHP-FPM workers), why a homepage load test proves nothing about checkout, and how to load test the full journey with unique data per virtual user.
- [WooCommerce performance testing guide](https://www.evaluat.com/blog/woocommerce-performance-testing): The self-hosted SMB corner of the ecommerce cluster, and the practical how-to-test guide. WooCommerce runs on WordPress and powers more stores than any other platform, and it scales with the right hosting and caching, but the cart, checkout, and my-account pages are non-cacheable by design and run PHP and MySQL on every request. The WooCommerce-specific load costs are the admin-ajax cart-fragment call (reduced since version 7.8 but still uncached where it fires), wp_options autoload bloat, plugin sprawl, and small PHP worker pools with no object cache on budget hosting, which cap concurrency and return 502s at peak. Because WooCommerce is self-hosted, you can and should load test the whole journey including checkout, unlike a hosted platform, on a staging copy and after checking your host's terms. Covers why an HTTP load test only measures the cache, the real-browser difference, and how to find the worker-pool ceiling.
- [Why your Shopify store slows down under load](https://www.evaluat.com/blog/shopify-store-slow-under-load): The client-side mirror of the Magento post, on a hosted platform. Shopify's storefront is served fast from a global CDN with full-page caching, and most Shopify shops pass Core Web Vitals in the field, so buyers assume the store scales. The slowdown is the theme, app, and third-party JavaScript a merchant adds: it runs on each shopper's own device and never amortizes, so peak means the most people paying that render cost at once, while the app and tag backends the JavaScript calls degrade under their own load at the same moment. An HTTP load test never executes any of it, so it reports a healthy 200 and a fast server while LCP and INP slip; only a real-browser test sees it. Includes how to load test the storefront and cart safely against a development store, since checkout is Shopify-hosted and sandboxed.

## Key facts

- Browsers: Chromium-based, the same engine customers run as Chrome and Edge.
- Test regions live today: London (UK) and Frankfurt (Germany). Further regions are added when customers ask.
- What every test report contains: five views (Overview, URL performance, Sessions with video, Console logs, Network logs), plus an Executive Summary that distils them into 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.
- 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 residency: test data resides in the region the test ran in: run a test from London and its data stays in the UK; run it from Frankfurt and it stays in Frankfurt, Germany. If you have a specific residency or compliance requirement, talk to us.
- Architecture note: Evaluat runs full browsers (not headless) so paint timings match what users see, and tests user-facing applications rather than APIs or non-HTTP protocols.
- Customers: engineering teams at Auping (bed manufacturer), terStal (fashion retailer), and roadmap.sh (developer learning platform) use Evaluat for performance testing.

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