What are Core Web Vitals? LCP, INP and CLS explained

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element (usually an image or heading) to appear. Interaction to Next Paint (INP) measures how quickly the page responds to clicks, taps and key presses. Cumulative Layout Shift (CLS) measures how much the layout shifts while loading, for instance when a banner pushes the text down.

The thresholds come from Google's official documentation on web.dev. They apply per page, not per site: your homepage can score well while a product page fails. A site that feels smooth in the office can still miss the threshold on an average phone over 4G.

Slow pages cost visitors. Every extra second of load time increases the share of people who leave before the page renders. Google also uses the Core Web Vitals as a ranking signal: with comparable content, the faster page wins. For web shops it counts double, because a stuttering checkout directly affects revenue.

The metrics are deliberately chosen around what a visitor actually notices: how quickly do I see something, how quickly does it respond, and does the layout stay put. A server that responds fast but a page that then spends seconds running scripts rightly scores poorly. This is not about an abstract grade; it is about how the page feels in the user's hand.

There are two kinds of measurements. Field data comes from real visitors (through the Chrome User Experience Report) and determines how Google judges your page. Lab data comes from a simulated test, such as a scan or Lighthouse run, and is instantly available and reproducible. Field data is the verdict; lab data is the tool for finding problems and verifying fixes.

The WebYes scan measures lab values on the scanned pages (up to six per scan) and includes them in the speed pillar. To learn how to run and interpret that measurement yourself, also read testing website speed. For a quick external check you can also use PageSpeed Insights; it often shows both lab and field data when there is enough traffic.

A high LCP is usually caused by oversized images, slow server response or render-blocking scripts and stylesheets. A high INP almost always points to too much JavaScript occupying the main thread, often from tag managers, chat widgets and tracking scripts. CLS problems come from images without fixed dimensions, late-loading ads or web fonts that make the text jump.

The order of attack is almost always: optimise images first (size, compression, lazy loading), then remove or defer unnecessary scripts, and finally speed up the server side with caching or a CDN. Measure again after every step; without a new measurement you do not know whether the fix really works.

Speed is one of the four pillars of the WebYes scan, alongside mobile, security and accessibility. Within that speed pillar we look at lab measurements aligned with the Core Web Vitals: how quickly the page loads, how stable the layout stays, and how heavy the page is for the browser. The free scan is labelled beta and limited to a maximum of six pages per run; a paid full audit may include up to fifteen sitemap-led pages.

The keurmerk requires an average score of at least 80 across the four pillars, and each pillar separately must score at least 60. A site with a strong mobile score but a speed pillar below 60 therefore fails the assessment, even if the average is high. That is intentional: a keurmerk that leans on only one strong pillar says little about the experience of your visitors. More on how to measure and prioritise yourself is in testing website speed and in the context of mobile-friendly websites, where slow LCP and CLS often hit hardest.

In re-audits we often see the same order of wins. Start with LCP on the homepage and key landing pages: hero images in a modern format (WebP or AVIF), fixed width/height, and no render-blocking CSS delaying the largest paint. Measure again; an LCP that drops from 4.2 s to 2.3 s feels calmer immediately and lifts the lab score visibly.

Then INP: inventory third-party scripts (chat, A/B tools, pixel stacks) and disable what is not essential on first paint. Chat widgets that block the main thread until the visitor clicks are a classic INP penalty. Only then fine-tune: code-splitting, idle callbacks, and less work in event handlers. CLS often comes last: reserve space for banners and cookie bars so content does not jump when consent UI appears.

Document every fix with a before/after lab measurement on the same URL. Without that discipline you optimise blindly and cannot tell which change saved the pillar score. The WebYes timeline on a paid profile helps: you see when a full audit ran again and whether the speed pillar rose or fell.

Core Web Vitals say nothing about content quality, accessibility or security. A fast page can still fail on contrast, missing alt text or missing security headers. That is why WebYes scores four pillars separately: speed alone is never enough for the keurmerk.

They also do not measure conversion paths end to end. A checkout that scores well in the lab but has three confusing steps can still lose visitors. Use vitals as a hard floor for technical UX, not as a substitute for usability tests or a human WCAG audit.