Fast website: What Core Web Vitals measure and what we actually optimise

If you enter your own website into PageSpeed Insights, you often see a red or orange number. The question that follows is almost always the same: is that bad? The honest answer is that the number alone says little. Three metrics that Google calls Core Web Vitals matter more. Where the values come from matters even more.

The three metrics and their thresholds

Largest Contentful Paint (LCP) measures when the largest visible element is displayed. Usually this is the large image at the top of the page or the main heading. Google rates 2.5 seconds or less as good and more than 4 seconds as poor.

Interaction to Next Paint (INP) measures how quickly the page responds to input, meaning clicks, taps and the keyboard. It assesses the whole visit, not just the first interaction. 200 milliseconds or less is good, more than 500 is poor. On 12 March 2024, INP replaced its predecessor First Input Delay (FID). If a guide or an audit report still mentions FID, it is out of date.

Cumulative Layout Shift (CLS) measures how much content jumps unexpectedly while loading. The value is a score without a unit. 0.1 or less is good, more than 0.25 is poor.

Google does not look at the average but at the 75th percentile, separately for mobile and desktop. Put simply, three out of four visits must be in the green range.

Field data and lab data

PageSpeed Insights shows two different things that are often confused. At the top is field data from the Chrome User Experience Report (CrUX). These are measurements from real Chrome users over the last 28 days. Below that is a lab test with Lighthouse. It loads the page once in a simulated environment, on mobile with a throttled mid-range device. This is also where the score between 0 and 100 comes from. This score is not a Core Web Vital.

For many smaller websites there is no field data at all, because Google only includes sites with enough visitors in the report. Then the lab test remains as an indication. We also look at the “Core Web Vitals” report in Google Search Console and test on real phones that are not brand new.

Our rule: we judge by field data where it exists. The lab test is for finding the causes.

What makes websites slow in practice

The reasons are rarely exotic. We almost always come across the same five.

Images. A photo straight from the camera used as a large header image is the most common reason for a poor LCP. We deliver images in modern formats such as WebP or AVIF, in several sizes, so that a phone does not load the image meant for a large screen. The header image is loaded with priority. Images further down only load when someone scrolls there.

Fonts. Fonts from a third-party server mean an extra connection before any text appears. From a data protection point of view, they are tricky anyway. We host fonts ourselves, in the compact woff2 format, with as few weights as possible. Only the font used everywhere is preloaded.

Third-party scripts. Chat windows, tracking, embedded maps, videos and social media feeds each bring their own code. This mainly affects INP. For every script, we ask who actually uses the data. What remains, we load late. We embed maps and videos so that they only load after a click.

Server and caching. A WordPress site with many plugins builds every page from scratch on every request. With a page cache or statically generated pages, the server responds much faster. Our servers are at Hetzner in Germany, close to visitors from Austria. That is why many regional businesses do not need an additional content delivery network that distributes content across servers worldwide.

Late banners and images without dimensions. A cookie banner or notice bar that appears at the top and pushes the content down worsens CLS. The same happens with images without set dimensions and when the fallback font switches to the actual font. We reserve the space in advance and place banners over the page instead of inside it.

What speed means for rankings

Here it pays to stay sober. Google recommends good Core Web Vitals and says they align with what its ranking systems reward. At the same time, Google states that good values do not guarantee a top position. The most relevant page is shown even if it is slower. Speed is one signal among many. Good content remains more important.

The real reason for a fast site is therefore your visitors. Someone looking up your phone number on their mobile on the way to work does not like to wait. We do not optimise for 100 points in Lighthouse. We optimise until the field data is green and the site feels quick on an older phone. Anything beyond that takes a lot of effort for little noticeable difference.

How we go about it

First we measure the current state, in the field and in the lab. Then we fix the causes in order of their impact, usually starting with images and third-party scripts. Because field data is collected over 28 days, we check the result again after a few weeks. For websites we support, the topic stays on our radar after that, because every new plugin and every new header image can shift the values again.

How we plan for this from the start in new projects is described under Web Design & Development.