Core Web Vitals explained

Core Web Vitals are the three measurements Google uses to judge the experience on a page: how quickly the largest content appears on screen, how quickly the page responds to an interaction and how stable the page stays while it loads.

These three measurements are called Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google measures them with real visitor data collected through Chrome, rather than in a lab. That data then feeds into the ranking. It sets Core Web Vitals apart from a simulated speed test, because such a test covers one scenario while Core Web Vitals reflect the average of all your real visitors, on every device and every connection they use.

Why Google chose this over a simple loading time

• One number hides too much. An average loading time says nothing about whether the page also responds pleasantly once someone clicks on something, or about how stable the image stays.
• Real visitors differ enormously. Someone on a new phone with fibre experiences a very different page from someone on an older handset with mobile internet. Core Web Vitals try to make that difference visible instead of papering over it.
• Three separate measurements force precision. By measuring loading speed, responsiveness and stability apart from one another, it becomes clear straight away which part of the experience is the problem, instead of a vague complaint that “the site feels slow”.

The three measurements in detail

• Largest Contentful Paint (LCP). Measures how long it takes for the largest visible element, usually a hero image or a heading, to finish loading. A visitor staring at an empty page while the rest still loads experiences that as slow, even when the text is already there.
• Interaction to Next Paint (INP). Measures the delay between a click or a tap by a visitor and the moment the page responds to it. The higher that delay, the more a site feels as though it is stuck.
• Cumulative Layout Shift (CLS). Measures how much the page shifts unexpectedly while elements are still loading, for instance when an advert suddenly takes up room and a visitor clicks the wrong element by accident.

Why INP became the replacement for FID

• FID measured too little. First Input Delay looked only at the very first interaction of a visitor, while a page could keep responding slowly afterwards without that showing up in the measurement.
• INP looks at the whole session. Google replaced FID with INP on 12 March 2024, and INP measures the slowest interaction across the entire page visit instead of only the first.
• The consequence for sites with a lot of interaction. Pages with forms, filters or dropdown menus got a stricter picture of their real performance through this switch, because exactly that kind of interaction often shows problems only after the first click.
• What this means when your site is older. A page that counted as fast years ago under FID can still come out as slow under INP, simply because a different part of the interaction now gets weighed.

How to improve each measurement concretely

• Improving LCP. Compress images, load the most important element first and keep unnecessary scripts out from in front of the content, so the browser does not have to wait for something the visitor cannot see anyway.
• Improving INP. Break up heavy JavaScript tasks, so the browser can respond to a click in between instead of leaving it waiting until a long task has finished.
• Improving CLS. Reserve fixed space for images and adverts before they load, so the page stops shifting the moment they arrive.
• Measure again after every change. An adjustment that improves one measurement can worsen another, for example when loading a font affects CLS while you were only working on LCP.

The thresholds at a glance

These thresholds come from Google itself and apply to the measurement on mobile, where most sites are judged most harshly. A page that sits comfortably in the good zone on desktop can still land in the “needs improvement” category on an average mobile device with a middling connection, because slow networks and less powerful processors weigh extra heavily there.

Core Web Vitals stand apart from text and content and still count towards how Google decides the order. That same speed also plays a role in how well AI crawlers can work through your site, see technical SEO for AI. Taking these three measurements seriously improves the experience for visitors and the odds that a crawler can read your site without trouble.

A common misconception is that Core Web Vitals are mainly something for developers and not for whoever manages the content or the marketing budget. In practice a poor score often comes from content choices: a heavy carousel widget, an uncompressed product photo or a pop-up that loads at exactly the wrong moment. Anyone responsible for the pages themselves can prevent much of the damage with a few simple choices, long before a developer needs to get involved.

Want to see how your site scores on these three measurements? Take the free AI-zichtbaarheidscheck.