Development July 14, 2026
Core Web Vitals: what moves rankings and what merely annoys people
Core Web Vitals are three metrics: LCP, INP and CLS. The 2025 Web Almanac shows fewer than half of mobile sites pass all three. Here is what is worth fixing.
Core Web Vitals measures how a page feels to the user: how fast the main content appears, how fast the page responds to a click, and whether elements jump around. There are three metrics, each with a clear threshold.
Three metrics and their thresholds
- LCP (largest content appears): good up to 2.5 seconds
- INP (response to interaction): good up to 200 milliseconds, poor above 500 ms
- CLS (layout shift): good up to 0.1
Assessment uses the 75th percentile of real-user data, separately for mobile and desktop. A lab score (Lighthouse, for instance) is a tool, not the judge.
Where the market stands
Example: according to the HTTP Archive Web Almanac 2025, 48% of mobile sites passed all three metrics (44% a year earlier) and 56% of desktop sites. On mobile, 77% of sites had good INP, 62% good LCP and 81% good CLS. LCP is the weakest link.
So most sites lose on LCP, not on INP. If your page is at the average, improving LCP is the biggest quick win.
INP: where the delay comes from
INP replaced FID and measures the longest interaction across the whole visit, outliers excluded. It splits into three parts: input delay, processing time and presentation delay.
- long JavaScript tasks on the main thread block click handling
- a large DOM and expensive style calculations lengthen painting
- third-party scripts (chat, analytics, ads) steal time from everyone
What actually moves rankings
Google names page experience as one quality signal, but content relevance matters more. Speed alone rarely decides who ranks first, yet a poor LCP and a jumpy layout make users leave. Speed is therefore first a conversion question and only then a ranking question.
What to do: fix order
- Measure real data first (the Core Web Vitals report in Search Console, the CrUX part of PageSpeed Insights)
- LCP: prefer server-rendered HTML, give the hero image proper dimensions and high priority, do not lazy-load it
- CLS: set width and height on images and ad slots, load fonts without a jump
- INP: split long tasks, defer third-party scripts, reduce the DOM
- Check the result after 28 days, because field data updates on a rolling window
A practical example
Pages on this site are pre-generated as static HTML, so the first byte arrives fast and the main content exists without JavaScript. Images carry dimensions so the layout does not shift. That is the cheapest route for LCP and CLS, and it helps INP too, because less JavaScript means fewer long tasks.
A quick checklist before release
- The hero image has dimensions and is not lazy-loaded
- Fonts do not cause a visible jump
- Third-party scripts load after the main content
- Interactive elements respond to a click without a noticeable delay
Three questions
Why do the Lighthouse score and Search Console differ?
Lighthouse is a lab measurement from one device and one browsing session. Search Console shows real-user data at the 75th percentile. The latter decides.
How fast does a fix show up?
Field data updates on a rolling 28-day window, so the full effect appears after about a month. Do not draw conclusions from three days.
Which matters more: mobile or desktop?
Both are assessed separately, but mobile is weaker: per Web Almanac 2025, 48% of mobile sites and 56% of desktop sites pass all three metrics. On LCP the share of “poor” sites is nearly double on mobile (13% versus 7%).
Summary
Start with real data, fix LCP first, then CLS and INP, and check the result after a month. A fast site does not guarantee a position, but a slow site certainly loses visitors.
