Why a Fast Website Is Indispensable Today

“The site is too slow” is a feeling. Before anyone can work on it, that feeling has to become a number, otherwise you are optimising blind. Since Google introduced the Core Web Vitals there has been a shared yardstick for this: three measurements that describe how a page feels to real people. This article explains what they measure, where things usually go wrong and which measures genuinely pay off.

Fast means measurable today. The Core Web Vitals bring together three aspects: how long the most important visible content takes, how promptly the page responds to input and how steady the layout stays while loading. All three are assessed on real page views, not on a single test run in the lab.

The Core Web Vitals consist of three metrics, and each has a clear threshold above which Google classes the value as “good”:

INP is the youngest of the three: in March 2024 it replaced the earlier First Input Delay as a Core Web Vital. The reason was that the old metric only looked at the very first interaction – and of that only the delay before processing began, not the processing itself. Almost every page passed it, sluggish ones included. INP instead assesses how promptly the page responds to clicks, taps and key presses across the whole visit. Scrolling and zooming are expressly excluded.

Because an average swallows the outliers. The 75th percentile says: three out of four page views were at least as good as this value. What counts is therefore not the fastest device in the office but the experience of the large majority – older phones and poor mobile connections included.

In practice that means a page can feel lightning fast on the development machine and still fail. Anyone wanting a defensible statement about their own website needs data from real visits. Lab values are good for tracking down causes, but they are no evidence of how the page behaves out there with your customers.

Faster than most websites deliver. The best-known figure on this comes from Google: 53 per cent of visits are likely to be abandoned if a mobile page takes longer than three seconds to load. Google published it in September 2016, drawing on around 3,700 mobile websites that contributed their data voluntarily. It is therefore more than ten years old and rests on no random sample – read it as an order of magnitude, not as a measurement for your website.

We still cite the figure because it points in the right direction: patience is thinner on a phone than at a desk, and someone who has clicked away rarely comes back. What we deliberately do not repeat are the two staples of every performance presentation: the Amazon anecdote about milliseconds and revenue, and the rule of thumb that one second of delay costs a double-digit share of conversions. Neither has a published study with a traceable methodology behind it – for the Amazon figure, a roughly twenty-year-old conference talk at best. They sound good and prove nothing – and when we recommend an investment, we do not do it with invented numbers.

Yes, but not as the main factor. Google expressly recommends that site owners achieve good Core Web Vitals, and places them, together with other aspects of page experience, among the things its ranking systems are meant to reward. What decides the matter is still the content: Google describes page experience as what can tip the balance when several results are similarly helpful.

What happens after the click is more interesting than the ranking anyway. Someone arriving from search who first stares at a blank white area is gone before your best argument becomes visible. Speed is therefore less an SEO trick than the precondition for any work on visibility paying off at all.

Almost always for four reasons, and they are remarkably consistent across projects: images that are too large, too many third-party scripts, fonts embedded clumsily and a server that answers too late. The order changes from case to case; the list rarely does.

Images are almost always the element against which the Largest Contentful Paint is measured: according to the HTTP Archive, on 76 per cent of mobile pages and 85 per cent of desktop pages. It does not follow, though, that file size is also the cause of the problem. Google's analysis of real field data shows the opposite: on most websites with a poor Largest Contentful Paint, less than ten per cent of the time goes on actually downloading the image. By far the larger share goes on the server answering late and the browser finding out late which image it is supposed to load at all. A photo that goes into the media library straight from the camera still needs fixing – it is just rarely the only lever. So check first where the time actually goes: on the server response, on the delayed request for the image, or on the transfer. What separates WebP from AVIF is set out in our glossary under image compression.

Usually more than their benefit is worth. Every embedded tool – analytics, chat, maps, ad pixels, font services – brings its own connection, its own code and its own waiting time. It adds up quietly, because nobody removes a script that was added for a campaign two years ago. An honest inventory is often the cheapest optimisation available: whatever nobody looks at any more can go.

Noticeably, because both can block the first visible render. The browser holds text back until the font has loaded, or waits for a stylesheet it discovers only late. A small number of font weights, served from your own domain, a deliberately chosen loading behaviour and CSS that does not push half the website into every single page: that buys a lot here for comparatively little effort.

The server determines when anything reaches the browser at all. That waiting time is called Time to First Byte; web.dev names 0.8 seconds as a good value – not a Core Web Vital, but a reliable early indicator. If this value is high, no amount of image optimisation helps, because the problem sits before the first byte. Then it is about caching, about the database, or simply about a hosting package that is up to the website.

With two kinds of data. Field data comes from real visits and tells you how your page actually behaves. Lab data comes from a simulated test run and tells you what is causing the problem. You need the field data for the assessment and the lab data for the repair – together they give you a picture.

A lab test runs under fixed conditions: same device, same connection, every time. That makes it repeatable and therefore well suited to comparing two versions of the same page. Field data, by contrast, reflects reality, with all the old devices and poor connections – and that is exactly what the 75th percentile is built from. Anyone looking only at lab tests is optimising past a reality that does not exist. It is also worth looking at the First Contentful Paint; web.dev names 1.8 seconds as a good value.

In most projects, the same four: serve images at the size and in the format the page actually needs; weed out third-party scripts; slim down fonts and CSS; and make sure the server answers promptly. Big rebuilds come after that – if at all.

What is deliberately missing from this list are miracle tools. A plugin that promises “performance” usually just moves where the problem arises and makes the cause harder to find. When a website that has grown over the years fails on all four points at once, a clean rebuild is often cheaper than years of patching. We work that out beforehand, not afterwards.

More than it first appears. The same decisions that make a page fast – little ballast, clear structure, no surprise layout jumps – also make it easier to operate and easier for machines to read. Speed is therefore rarely a project in its own right.

A layout that jumps while loading affects everyone, but hits people with motor impairments hardest: they hit the button that has meanwhile moved. A page that manages without heavy scripts also works on a poor connection and on older devices. And search engines, like answer engines, cope far better with lean, cleanly structured HTML. That is why we treat performance not as an afterthought but as part of how a website is built in the first place.