Web performance, explained
Understand what the browser is actually doing.
Interactive experiments, visualisations and practical techniques for building faster websites. Lighthouse tells you that something is wrong. This site teaches you why.
12 experiments · 4 tracks
How bytes get to the browser, and how to need fewer of them.
Why isn’t loading 30 images just 30 requests?
Connection limits, DNS, TCP, TLS and what HTTP/2 and HTTP/3 change. The “six at once” rule, taken apart.
Why does a repeat visit sometimes still wait on the network?
Cache-Control, validation, 304s, immutable files and CDNs, plus what compression does and doesn’t change.
What happens when you put a programmable proxy between the page and the network?
Install, activate and update; cache-first, network-first and stale-while-revalidate; offline, and the stale-cache trap.
Preload, prefetch, preconnect: which one, and when?
The hints and priorities compared, including fetchpriority and Early Hints. When each helps and when it competes.
How can the next page load before you click?
Back/forward cache, prefetch and prerender with Speculation Rules, and what can go wrong.
What you send: images, fonts, JavaScript and everyone else’s scripts.
What does the browser do with a 2.4 MB hero?
Formats, srcset, lazy loading, priority and sprite sheets, including when a sprite sheet is the wrong call.
Why does your page feel broken for half a second?
FOIT, FOUT, font-display, preload, subsetting and variable fonts, compared side by side.
Why is a kilobyte of script dearer than a kilobyte of image?
Download, parse, compile, execute. Watch long tasks block the main thread and swallow a tap.
Who else is using your main thread?
Add analytics, ads and chat widgets one at a time and watch blocking time, layout shift and bytes grow.
What the browser does with it once it has arrived.
Why can’t the browser just show the page?
HTML to DOM, CSS to CSSOM, render tree, layout, paint, composite. Add a blocking resource and watch it stall.
Why can 200 KB of CSS cost more than 200 KB of images?
Selector matching, style recalculation, content-visibility and containment.
Knowing whether any of it worked.
Why does my 95 score not match what users feel?
A distribution of real visits, percentiles, Core Web Vitals thresholds, and how a single lab run misleads.
Training mode
A deliberately bad page starts at 24. Fix the hero image, lazy-load what’s below the fold, sort out fonts and cut the JavaScript, and see exactly which change moved the score.
Common misconceptions
Not universally true
Six connections per origin is an HTTP/1.1-era habit. HTTP/2 and HTTP/3 multiplex many requests over one connection, and the real limits depend on protocol, origin, connection reuse and priorities.
Outdated
On HTTP/2 and HTTP/3 a request is far cheaper than it was, and a cached request is free. Many small, separately cacheable files can beat one bundle that changes on every release.
It moves one request, and crowds the rest
Preload starts a request sooner and ranks it higher. Everything else now has more to compete with for the same bandwidth. It helps where discovery is late, and overused it delays the resources that matter most.
Not for what’s on screen
Lazy loading saves bytes by waiting, and waiting is the wrong thing for the hero. Above-the-fold images should load as early as possible.
Usually, not always
A more aggressive format can cost more to decode. A smaller file discovered late, or behind a queue, still arrives late. Bytes are one of several costs.
One simulated visit was fast
A lab run is one visitor on a fixed profile. Real visits differ, and what happens after load shapes the experience. Lab scores, field data and perceived responsiveness can all disagree.
How this site is built
prefers-reduced-motion and fits a 320px screen without sideways scrolling.