Page Speed

Why It Matters

Speed changes behaviour long before it changes rankings. Google's own field studies show abandonment rising sharply as load time passes three seconds, and the effect compounds on a mobile connection. As a ranking factor it is real but modest: it separates pages that are otherwise close, and no amount of speed rescues a page that does not answer the query. The honest framing is that speed is a tax on everything else you do — a page that ranks well and loads slowly still loses most of the visitors it earned.

How It Works

Most delay comes from bytes and blocking. The browser requests the HTML, parses it, and discovers the stylesheets and scripts it needs on the way through; a render-blocking stylesheet in the head stops painting until it arrives, and a synchronous script stops parsing altogether. Images are usually the single largest cost, so serving a correctly sized WebP instead of a camera original often saves more than every other change put together. Compression and caching handle the rest: Brotli on text assets typically saves 15 to 20 per cent over gzip, and a long Cache-Control max-age means repeat visitors download nothing at all. Serving from an edge network shortens the round trip, which shows up as a lower Time to First Byte. What counts as good — the actual thresholds and how the field data is collected — belongs on the Core Web Vitals page rather than here.

Real-World Example

Common Mistakes

• ✕Optimising for the Lighthouse score rather than the field data — the score is a lab summary, and ranking uses what real visitors actually experienced
• ✕Testing on a laptop on office wifi — the median visitor is on a mid-range phone on a patchy connection, which is what the field data reflects
• ✕Adding third-party scripts for analytics, chat and fonts and then wondering where the seconds went — each one is a connection, a download and work on the main thread

Related Terms