Blog
Product updates, engineering notes, and guides on testing performance in real browsers.
API performance testing vs browser performance testing: which your QA strategy needs
Your API responds in fifty milliseconds. Your page still takes eight seconds to feel ready. API performance testing and browser performance testing measure different layers of that gap, and your QA strategy needs both. Here is what each one catches, what it misses, and how to decide which to run first.
Evaluat Staff ·
Performance regression testing: making Core Web Vitals a CI/CD release gate
A green test suite proves your code is correct. It says nothing about whether the page got slower. Performance regression testing closes that gap: set Core Web Vitals budgets, measure every build against a baseline, and fail the pipeline when a change busts one. This guide wires that gate into CI/CD, from baselining main to the regressions only load reveals.
Evaluat Staff ·
What is an Apdex score? Measuring user satisfaction in performance testing
A load test can come back full of green percentiles and still not tell you whether the people behind them were satisfied or quietly giving up. An Apdex score answers that in one number from 0 to 1: you set a target response time, and it reports how many requests left users satisfied rather than merely tolerating, or frustrated.
Evaluat Staff ·
Load testing vs stress testing vs performance testing: how the three actually differ
Three terms, endless confusion. Performance testing is the umbrella; load testing checks whether you survive the traffic you expect; stress testing pushes past that to find where you break. This guide shows how the three actually differ, when to run each, and which one your team needs first.
Evaluat Staff ·
Core Web Vitals at load, explained
A page can score green in a single-user Lighthouse run and still ship a red Largest Contentful Paint the moment real traffic arrives. Core Web Vitals change under load: the server slows, time to first byte grows, and interactions wait on a busy backend. This guide explains why each Vital moves under load, and how to measure them at concurrency.
Evaluat Staff ·
Interaction to Next Paint (INP), explained for engineers
A page can pass every functional test and still feel slow on the second tap. Interaction to Next Paint is the Core Web Vital that catches it: the latency of your slowest interaction across a visit, timed from the click to the next frame painted. Here is what INP captures, what drags it past 200ms, and how to test it under load.
Evaluat Staff ·
What is spike testing? Preparing for traffic surges and flash sales
A flash sale does not ramp up. Ten thousand people hit checkout in the same minute, and the autoscaler is still booting servers when the page falls over. Spike testing rehearses that surge on purpose, a sudden jump in traffic then a sudden drop, so you learn whether the site survives the moment before your customers find out for you.
Evaluat Staff ·
Soak testing explained: catching slow degradation and memory leaks over time
Some failures never show up in a ten-minute test. A memory leak, a connection that never closes, a cache that only grows: these surface after hours of steady traffic, not minutes. Soak testing holds a realistic load for hours or days to expose the slow degradation short tests miss, before your users meet it as a 3 a.m. outage.
Evaluat Staff ·
Stress testing a website: how to find the breaking point before your users do
Every website has a breaking point. The only question is whether you find it in a test or your users find it during a sale. Stress testing pushes the site past its limit on purpose, so you learn where it fails, how it fails, and how fast it recovers, before real traffic does. Here is how to run one.
Evaluat Staff ·
Smoke testing vs performance testing: when a quick pre-release check is enough
Smoke testing and performance testing get treated as rivals, but they answer opposite questions. A smoke test asks whether a new build is broken. A performance test asks whether it stays fast and stable under load. This guide shows how the two differ, and when a quick pre-release check is genuinely enough.
Evaluat Staff ·
What is performance testing? A QA engineer's guide to testing under real traffic
Your app works fine for one user. Then a launch sends three thousand at once and pages crawl. Performance testing is how QA teams measure speed, stability, and scale under real traffic, on purpose, in a test instead of in production. This guide covers what performance testing is, its types, and when to run it.
Evaluat Staff ·
Playwright for performance testing: can a browser automation tool drive virtual users?
You already know Playwright for end-to-end tests. Can you reuse it for performance testing and call each browser a virtual user? You can, but a real browser is expensive to run, so it drives a handful, not a flood. Here is how far Playwright scales, and where you reach for a different tool.
Evaluat Staff ·
Where does performance testing fit in an agile release cycle?
Agile teams ship every week, sometimes every day. Performance testing built for a quarterly release does not fit that rhythm, so it slides to the end, then to never, until production buckles. It does not have to. This guide maps each performance test to a stage: cheap checks every commit, a real-browser load test at the pre-release gate, monitoring after.
Evaluat Staff ·
Core Web Vitals: why lab scores differ from real users
Your Lighthouse score says 98. Your Core Web Vitals report says the page is failing. Both can be right. A lab test measures one synthetic load on a fixed device and network; field data is the spread of every real device, connection, and click your users bring, including the traffic a lab never simulates. Here is why lab and field diverge, and which to trust.
Evaluat Staff ·
Why average response time misleads you: reading p95 and p99
Your dashboard says average response time is 420 milliseconds. Half your users see 100, one in a hundred waits over five seconds, and the average describes none of them. p95 and p99 read response time from the slow end, where the failures you run a performance test to find actually live.
Evaluat Staff ·
8 metrics every performance test report should include
A performance test report full of green averages can still hide a checkout that buckled at peak. The numbers that catch it come in three passes: did the system keep up, how slow was it really, and what did users feel. Here are the eight metrics that answer those questions, and the benchmark that shows each is healthy.
Evaluat Staff ·
Largest Contentful Paint (LCP), explained for engineers
Your Largest Contentful Paint is the moment the biggest thing on the page, usually the hero image, finishes rendering, and Google treats it as a Core Web Vital. This guide explains what counts as the LCP element, the four phases LCP breaks into, why your lab and field numbers disagree, and how to fix and measure it under real load.
Evaluat Staff ·
Real-browser load testing, explained
Most load testing tools fire HTTP requests at your server. A few share one browser across many simulated users. Real-browser load testing gives every virtual user its own isolated browser, so it measures what your customers' browsers actually do under load. Here is how the three models differ, what each one can and cannot see, and when each is the right call.
Evaluat Staff ·
Functional testing vs performance testing: two questions every release should answer
A build can pass every functional test and still fall over the moment real traffic arrives. Functional testing answers one question: does your software do the right thing? Performance testing answers another: does it stay fast and stable under load? Every release has to answer both. This guide shows how the two differ, and where each one fits.
Evaluat Staff ·
Performance testing FAQs
What is performance testing?
Performance testing measures how a website or app behaves under load: how fast it responds, how stable it stays, and where it breaks. It spans load, stress, spike, and soak testing, each answering a different question about behaviour under traffic.
What is the difference between load, stress, and spike testing?
Load testing checks behaviour at expected traffic. Stress testing pushes past capacity to find the breaking point. Spike testing applies a sudden surge to see how the system copes and recovers. Most teams run all three against the same journey.
What are Core Web Vitals and why do they matter under load?
Core Web Vitals are Google's user-experience metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They measure what users feel. Under load they often degrade long before the server returns errors, so measuring them in a real browser is what surfaces the problem.
Why test in a real browser instead of at the HTTP level?
HTTP-level tools stop at the server response. The seconds a user waits for the page to render, run JavaScript, and become interactive all happen afterward, in the browser. Real-browser testing captures that part, so the numbers match what users actually experience.
How often should you run performance tests?
Run them before major launches and traffic events, after significant changes to critical journeys, and on a regular cadence so regressions surface early. Continuous monitoring fills the gaps between scheduled tests.