Black Friday is November 27. Peak rehearsals are booking now. Book a slot

Guides

Start here for definitions, process, and how performance testing fits a release cycle.

The guides are the long-form spine of the blog. If you are new to the subject, Performance testing: the complete guide covers the vocabulary, the test types and the process end to end, and What is load testing? and What is a virtual user? fill in the two terms every conversation with a vendor turns on. What is website performance, and why does speed matter? is the one to send to a stakeholder who asks why any of this deserves budget.

Two guides are about how the work fits a team. Where does performance testing fit in an agile release cycle? looks at when in a sprint the testing should happen and what it should gate, and Playwright for performance testing answers the question engineers ask once Playwright is already in the repo: can it drive virtual users, and where does it stop.

If you would rather follow a sequence, the beginner's guide publishes two parts a week, from first principles through to running and reading your own tests.

The browser's main thread drawn as one bar shared by several owners. The site's own code takes the first part. Tag manager tags, a chat widget, a video embed and ads, all code from other companies, take the rest. A shopper's tap has to wait until the thread is free. You wrote some of the page; your shoppers wait for all of it.

Third-party scripts and tag managers: the slowdown you did not write

Nine in ten web pages run code from another company's servers, such as analytics, ads, chat and consent banners. Each one downloads, runs on the main thread beside your own code, and can hold the page up when its server is slow. A tag manager makes them easy to add. Measuring what each one costs tells you which to keep.

Ahmad Farzan ·

Five cache layers between a shopper and the database, drawn left to right: browser cache, CDN, full-page cache, object cache and database memory. A request for a product page is answered by the full-page cache and stops there. A basket request uses the browser cache for files only, skips the CDN page cache and the full-page cache, and goes on to the object cache and the database.

Caching explained: browser, CDN, full-page and object caches

Caching means keeping a copy of something expensive to produce so the next request can be answered faster. A busy online shop has five layers of it between a shopper and the database. Basket, checkout and account requests skip the two layers that store whole pages, which is why they slow first under load.

Ahmad Farzan ·

The five stages a busy website fails in, drawn as a descending staircase. First, requests queue and pages slow. Second, timeouts turn slow requests into 502 and 504 errors. Third, retries and refreshes multiply the load. Fourth, overloaded servers miss health checks and are pulled from service. Fifth, the failure cascades to the next part of the system, often the database. The order barely changes; what runs out first does.

Why websites crash under high traffic

Most websites do not simply switch off when traffic spikes. Requests queue for a limited resource, pages slow, timeouts turn slow into failed, and retries and failed health checks pile on more load until the site falls over. The symptoms arrive in roughly that order every time. What differs is which part runs out first.

Ahmad Farzan ·

A CDN receives 2,000 requests a second. Bars show how many reach the origin server at each cache hit ratio: 400 a second at 80 percent, 200 at 90 percent, 100 at 95 percent and 20 at 99 percent. Dropping from a 95 to a 90 percent hit ratio doubles the origin's traffic, and baskets, checkouts and orders are always among the requests that get through.

What a CDN does (and does not) do for your site under load

A content delivery network (CDN) is a network of servers that keeps copies of your files close to your visitors and answers for your own server whenever it can. Under load it can absorb most requests for pages and files that are the same for everyone. Baskets, checkouts and every order still reach your server.

Ahmad Farzan ·

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.

Latency, bandwidth and round trips, explained

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.

Ahmad Farzan ·

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.

What happens when a web page loads: DNS, TLS, TTFB and render

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.

Ahmad Farzan ·

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.

How many concurrent users can my website handle? (with calculator)

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.

Ahmad Farzan ·

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.

How to load test a website: your first test, step by step

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.

Ahmad Farzan ·

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.

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.

Ahmad Farzan ·

Ecommerce conversion rate against page load time, from Portent's 2022 study of over 100 million page views: 3.05 percent of visitors convert on a one-second page, falling to 0.67 percent by four seconds. Every extra second of load time costs sales.

What is website performance, and why does speed matter?

Website performance is what your site feels like to the person using it: how fast pages appear, how quickly they respond, and whether that holds when traffic arrives. It matters because the costs are measurable. Slow pages convert visitors at a fraction of the rate of fast ones, and search rankings lean toward sites that feel good to use.

Ahmad Farzan ·

Response time chart for the same checkout: at one user the page answers in under a second; as concurrent users approach 3,000 the curve bends and the same page takes eight seconds. Load testing measures that curve before real traffic does.

What is load testing?

Load testing tells you what happens to your site when real traffic shows up at once. This guide explains what it is, why slow pages cost conversions, how a test actually runs, and how to size your first run, with no prior testing background assumed.

Ahmad Farzan ·

The cost of one virtual user. A protocol virtual user in a load tool like k6 costs about 1 to 5 megabytes, so one machine runs tens of thousands of them, shown as a dense field of dots. A real-browser virtual user driven by Playwright costs hundreds of megabytes and about one CPU core, so one machine runs only dozens to low hundreds, shown as a few browser windows. Roughly 50 to 100 times more compute per user.

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.

Ahmad Farzan ·

A release cycle drawn as five stages from planning to production. The weight of each performance test grows from light checks on every commit to a heavy real-browser load test at the pre-release gate, then tapers to monitoring in production.

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.

Ahmad Farzan ·

A performance test timeline. The server answers in 0.28 seconds, but the page is not usable until 4.3 seconds under load, well past Google's 2.5-second LCP budget. The gap is everything the browser does after the server responds: rendering, JavaScript, and third-party tags.

Performance testing: the complete guide

Your server can answer in 50 milliseconds and still ship an eight-second page. Performance testing measures both backend behavior and the browser-rendered experience under controlled load. This guide maps the whole discipline: the types, the metrics that matter, the process, and how to choose between protocol-level and real-browser tools.

Ahmad Farzan ·