Core Web Vitals: a fast website matters after loading too

LCP, INP and CLS in actual use. Distinguish a lab test from visitor experience and choose changes that improve reading and interaction.

A person using a website on a laptop at a wooden desk

One green score does not represent every visit

A developer tests on a fast computer and the page feels responsive. A visitor on an older phone waits for its cover image, then sees the interface stall after selecting a filter. Both experiences can describe the same website. A lab test helps reproduce and fix problems, but its particular device, network and scenario do not represent every user.

Core Web Vitals measure main-content loading through LCP, interaction responsiveness through INP and visual stability through CLS. Good thresholds are LCP within 2.5 seconds, INP within 200 milliseconds and CLS at or below 0.1. Assessment uses the 75th percentile, separating mobile and desktop visits. A technical team needs to understand the distribution, rather than only an average.

Find what actually delays the visitor

On an illustrative business website, compare the home page, service detail and article. Each type may have a different largest element and different interactions. Group results by page type and device; identifying individual users is unnecessary for this purpose. Where CrUX lacks sufficient public data, appropriately privacy-protected measurement of real visits can supplement diagnostics.

Record a baseline and one priority change. Replacing a form library may not help a delayed main image. Further shrinking a logo will not accelerate a slow filter calculation. Prepare a reproducible scenario and comparable post-fix measurement. Keep test conditions consistent so the comparison does not merely reflect different network speeds.

An LCP image must become available at the right time

For an image contributing to LCP, check when its address appears in the document and when fetching begins. A visible main image discovered only after another client request adds delay before transfer. Lazy loading suits images further down the page but can delay a main image in the initial viewport. Assign priority selectively to the element that needs it.

Prepare appropriate dimensions and responsive variants. A modern format such as WebP can reduce transfer, but an oversized source remains unnecessary for a small card. Check sizes and the variant actually downloaded. LCP can also be a text block, so inspect CSS, fonts and server response. Image compression cannot remove time spent waiting for a slow database read.

INP appears when people use the page

INP assesses interaction response, including delay before processing, handler work and presentation of the next frame. A long main-thread task can block a click even after the page appears loaded. During profiling, actually open the menu, filter the list and use the form. A scenario without interactions does not test their cost.

In an illustrative list, each keystroke might filter thousands of items and trigger a large render. Measure where the time goes first. Remove unnecessary work, limit rendered items or move suitable computation to a worker. Longer work may benefit from yielding the main thread between steps. An animated progress indicator cannot fix the blockage if it cannot repaint either.

CLS needs reserved space

Known image dimensions or aspect ratios let the browser reserve space before loading. Embedded video, externally inserted sections and font changes can cause similar problems. In an illustrative article, a late banner may shift the text precisely while someone reads the next paragraph or tries to select a link.

Reserve suitable space and avoid unnecessarily moving content already being read. Test dynamic components with slow networks and varying text lengths. CLS measures selected unexpected shifts; not every interface movement contributes in the same way. A good value still cannot replace checking whether a transition makes sense and the person can complete their task.

Verify the change during actual use

After deployment, compare the lab scenario and available field data. Public field results do not update immediately after one change. Record deployment time and scope to identify which version a result describes. Improved Core Web Vitals alone cannot guarantee a search ranking; it demonstrates improvement in a particular part of the visitor experience.

  • Main content loads without an unnecessary client-side discovery step.
  • Menus, filters and forms respond on slower devices too.
  • Images and late content do not displace text being read.
  • Post-fix measurement uses comparable scenarios and observes real visits too.

Sources and documentation

For implementation, consult the documentation for the version you use.

Put the topic into practice.

Have a process
that needs to change?

Let’s start with how you work today. We’ll choose the technology around it.

Discuss your project