A Core Web Vitals checklist comes down to three numbers: how fast the main content loads (LCP), how quickly the page reacts to a tap or click (INP) and how much the layout jumps while loading (CLS). Google's targets are 2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS. Fix them in that order of business impact: load first, then responsiveness, then stability.
This guide is for CTOs, founders and product leads who own a website that has to convert visitors. It explains what each metric means, what usually breaks it and how to run the work without guessing.
What the three metrics measure
The Core Web Vitals thresholds article lists the final "good" values and the rule for judging a page. A page or site is assessed at the 75th percentile of all page views. That means three out of four visits must meet the target, not just your fastest ones.
The same article says one set of thresholds applies to mobile and desktop, although the values are largely set around what mobile sites can reach. Treat the mobile numbers as your priority.
INP is the newest of the three. In March 2024 it became a stable metric and replaced First Input Delay. If an old report or vendor deck still shows FID, it is out of date.
Why it matters for search and sales
Google's page on Core Web Vitals and Search says the metrics align with what its core ranking systems seek to reward. It also says it highly recommends that site owners achieve good scores. It does not say that a good score guarantees a high ranking, so do not sell it internally as a ranking shortcut.
The stronger business case is simpler. A slow page, a button that lags and a layout that jumps under the thumb all cost you visitors who were already interested. Fixing them helps users first and search second.
LCP: make the main content arrive sooner
The LCP guide says sites should aim for an LCP of 2.5 seconds or less for at least 75% of visits. Above 4.0 seconds counts as poor. It splits the wait into four parts and gives an ideal share for each:
| LCP part | Ideal share of the total |
|---|---|
| Time to first byte | About 40% |
| Resource load delay | Under 10% |
| Resource load duration | About 40% |
| Element render delay | Under 10% |
The guide calls these guidelines, not strict rules, and warns against turning them into fixed millisecond goals. The useful point is that the two delay parts should be close to zero. If the browser waits before it even starts fetching your hero image, that is wasted time.
Three fixes come straight from the guide:
- Never lazy-load the LCP image. The guide says this always adds unnecessary resource load delay.
- Set
fetchpriority="high"on the image most likely to be the LCP element. Using it on more than one or two images weakens the effect. - Make the LCP resource easy to discover. If the image is only referenced from external CSS or JavaScript, preload it in the HTML.
INP: keep the page responsive
The INP guide says a good INP is 200 milliseconds or less and a poor one is above 500. It breaks an interaction into three phases: input delay, processing duration and presentation delay. That split tells your engineers where to look.
- 1Input delayThe tap waits because the main thread is busy, often with startup scripts. Reduce script work during load.
- 2Processing durationYour event handlers run too long. Split the work into smaller tasks and yield to the main thread between them.
- 3Presentation delayThe browser takes too long to draw the next frame. Run only the logic the next frame needs and defer the rest.
The guide also names a few other causes. Layout thrashing happens when code updates styles and then reads them in the same task. A very large DOM makes every update more expensive, and the CSS content-visibility property can limit rendering of off-screen elements. Rendering large amounts of HTML with JavaScript on the client can also delay the next frame.
For a marketing site, the usual suspects are heavy scripts that run at startup, menus and forms that do too much on click and large pages with thousands of elements. A product team should expect INP to need real engineering time, not a plugin.
CLS: stop the page from jumping
The CLS guide sets the target at 0.1 or less for at least 75% of visits, with scores above 0.25 counted as poor. It names four common causes:
Set width and height on images and video, or reserve space with CSS aspect-ratio, so the browser holds the space before the file loads.
Ads, embeds, iframes and injected banners push content down. Reserve space for them with a minimum height or aspect ratio.
Swapping a fallback font for a web font, or hiding text until the font loads, can shift lines. Choose sensible fallbacks and preload critical fonts.
Animating properties such as top and left causes shifts. Transform animations avoid re-layout and do not count toward CLS.
Cookie banners and chat widgets are common offenders on business sites. Give them a reserved slot, or overlay them so they do not move the page.
A fix order that works
- 1Read real-user dataOpen the Core Web Vitals report in Search Console and list the page groups that fail.
- 2Pick the worst templateFix a template used by many pages, such as product, service or blog, before a single one-off page.
- 3Find the biggest causeUse the three LCP parts, the three INP phases or the four CLS causes above to name the cause.
- 4Fix and releaseShip one change at a time so you can see what moved the number.
- 5Measure againWait for fresh real-user data, then repeat on the next template.
Search Console is the place Google points site owners to for this data. Lab tools help you debug, but they are a different view from what real visitors experience.
Mistakes to avoid
Teams lose weeks on the same few errors:
- Optimizing one page for a lab score while the template that serves a thousand pages stays slow.
- Lazy-loading every image, including the hero, which hurts LCP.
- Adding a performance plugin on top of heavy scripts instead of removing the scripts.
- Fixing the numbers once and never checking again. New banners, fonts and embeds bring the problems back.
Where XOSOFT fits
Our frontend and UI/UX practice covers frontend engineering, design systems and WCAG AA accessibility, which are the layers where most of these problems start. Our QA and testing practice treats QA as a gate, not a phase, so performance checks can sit in the release process. You can read how we run projects on the how we work page.
If your scores are failing and you are not sure where to start, book a technical call. It is a technical conversation, not a sales pitch.
Frequently asked questions
What are the three Core Web Vitals?
Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) measures responsiveness and Cumulative Layout Shift (CLS) measures visual stability.
What scores count as good?
Google's guidance gives LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, measured at the 75th percentile of page visits.
Did INP replace First Input Delay?
Yes. In March 2024 Interaction to Next Paint became a stable Core Web Vital and replaced First Input Delay.
Will good scores guarantee better search rankings?
No source we read promises that. Google says the metrics align with what its core ranking systems seek to reward and highly recommends good scores, but relevance and content still matter.
Where do we see our own scores?
Google points site owners to the Core Web Vitals report in Search Console, which groups real-user data by page.
Need help with frontend and UI/UX?
Talk to the engineers who would do the work. We reply within one working day.