To improve Core Web Vitals, first use real-user data to find which metric is failing, then fix the cause behind that specific metric. Google’s targets are that, for 75% of page loads, the main content appears within 2.5 seconds (LCP), the page responds to taps and clicks within 200 milliseconds (INP) and the layout shifts by no more than 0.1 (CLS). In practice, most of the gains come from loading the first-screen image early and small for LCP, freeing the main thread from long tasks for INP, and reserving space for images and late-loading elements for CLS.
This guide is based on Google’s web.dev and Search Central documentation. We have added what we did when we rebuilt antargetech.com in October 2026 as a worked example.
What are Core Web Vitals and why do they matter?
Core Web Vitals are three metrics that capture how a page feels to a visitor: loading speed, responsiveness and visual stability. Each is assessed at the 75th percentile of page loads, separately for mobile and desktop. In other words, a metric counts as “good” when three out of four visits stay under the threshold.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Time until the main content appears | 2.5 s or less | 2.5–4 s | over 4 s |
| INP | Response time to clicks, taps and key presses | 200 ms or less | 200–500 ms | over 500 ms |
| CLS | Unexpected layout shifts | 0.1 or less | 0.1–0.25 | over 0.25 |
INP replaced First Input Delay (FID) in March 2024. FID only measured the first interaction; INP observes every click, tap and key press on the page.
Google recommends achieving good Core Web Vitals for success in Search and says they align with the page experience its core ranking systems seek to reward. It does not, however, describe them as a score that decides rankings on its own. Good content can rank on a slow page, but when two pages answer the same question, the faster one loses fewer visitors.
Measure first: field data and lab data
There are two kinds of data and they tell you different things. PageSpeed Insights shows both on the same screen:
- Field data: real measurements collected from Chrome users (the Chrome User Experience Report, CrUX), covering the previous 28 days. Google’s assessment is based on this data.
- Lab data: a single page load run by Lighthouse, simulating a mid-tier phone on a mobile network. It is good for finding causes but does not reflect the variety of real devices and connections.
The Core Web Vitals report in Search Console also uses CrUX data. It groups similar pages and gives each group the status of its worst metric: if LCP and INP are good but CLS is poor, the whole group shows as poor.
On low-traffic sites these reports can stay empty, because CrUX needs a minimum number of visits to protect user privacy. In October 2026, Search Console told us there was not enough usage data from the last 90 days for our own site, on both mobile and desktop. In that situation you rely on Lighthouse and on your own measurements. Google’s web-vitals library collects the same three metrics from your visitors so you can send them to your analytics tool.
Speeding up LCP
The LCP element is usually the large image on the first screen or the main heading. Google suggests breaking LCP into four parts; improving one part without knowing which is slow can simply move the time into another.
- Time to First Byte (TTFB): the server’s first response. Cut redirect chains, cache pages and use a CDN close to your visitors.
- Resource load delay: how long before the browser discovers the LCP image and starts downloading it. Put the image directly in the HTML, add
fetchpriority="high", and usepreloadonly if the image is referenced from CSS or JavaScript. Google is blunt here: never lazy-load the LCP image (loading="lazy"). - Resource load duration: the download itself. Serve an image sized for the screen, in WebP or AVIF, and compressed.
- Element render delay: the time between the download finishing and the element being painted. Remove unused CSS, inline small stylesheets and defer synchronous scripts in
<head>. Generating the page as ready-made HTML on the server or at build time shows content without waiting for JavaScript.
Improving INP
INP is the time from the moment a user presses a button until the result appears on screen. It is made up of three phases: input delay (the browser is busy with something else), processing time (your event code runs) and presentation delay (the next frame is painted).
The most common culprit is JavaScript that keeps the main thread busy for too long. These steps help in most cases:
- Break up long tasks: split the work behind a click into pieces, run the part that updates the screen first and defer the rest to a later task, for example with
setTimeout. - Do not choke the main thread during load: keep large scripts and unnecessary libraries out of the initial load.
- Keep the DOM small: pages with thousands of elements paint more slowly on every interaction. Use
content-visibilityfor off-screen sections. - Avoid forced layouts: changing styles and then immediately reading element sizes in the same task forces the browser to recalculate the layout.
In web dashboards that behave like apps, code that runs on every key press, such as filters and search boxes, is where INP most often breaks down.
Reducing CLS
CLS measures content jumping down or sideways while you read. Shifts within 500 milliseconds of a user’s click or tap are not counted; the problem is shifts the user did not expect. The main causes Google lists, and their fixes:
| Cause | Fix |
|---|---|
| Images and videos without dimensions | Set width and height, or a CSS aspect-ratio |
| Ads, maps and embeds | Reserve space for the smallest expected size and keep it even if nothing loads |
| Banners and notices injected later | Overlay them instead of pushing content, or reserve their space up front |
| Web fonts | Preload key fonts and use a fallback font with similar metrics |
| Animations | Move elements with transform instead of top or left |
Keeping pages eligible for the browser’s back/forward cache (bfcache) also prevents them from reloading and shifting again when users navigate back.
What we did on this site
When we rebuilt antargetech.com in October 2026, the home page’s mobile Lighthouse result came out at Performance 97, with Accessibility, Best Practices and SEO at 100. The biggest gains came from three places:
- Loading the first-screen image early: the browser requests the LCP image as soon as it reads the HTML.
- Shrinking images: images are generated as WebP at build time in the sizes the layout needs, and each one has its width and height in the HTML. This also keeps CLS close to zero.
- Removing unused CSS: CSS per page went from 727 kB to 134 kB and is inlined into the page, so there is no separate stylesheet to wait for.
Pages are generated as static HTML at build time and served through Cloudflare, which keeps time to first byte short. One counter-example: on blog posts, the largest element on the first screen is the heading, not the image. When we tried loading the cover image early, LCP got worse rather than better, because the image competed for bandwidth with what the heading needed. So the covers are lazy-loaded. The rule is simple: preload the element that actually is the LCP.
We describe how we handled redirects and indexing during the same rebuild in our website migration guide, and what we did to get the site cited in ChatGPT and Google’s AI Overviews in our guide to GEO.
Frequently asked questions
My Lighthouse score is high but Search Console says “poor”. Why?
Lighthouse simulates a single load; Search Console looks at real visits over the past 28 days. If your visitors use slower phones or weaker connections, field data will be worse than the lab result. Google’s assessment is based on field data.
How long until a fix shows up?
Because field data covers a 28-day window, improvements appear gradually. Once the issue is fixed on all pages, you can start validation from the issue’s details page in Search Console (the “Start Tracking” button). Google then monitors field data for 28 days; if the issue does not appear on any URL in that time, it counts as fixed. Validation does not trigger a recrawl, it only starts the monitoring period.
How much do Core Web Vitals affect rankings?
Google treats them as part of page experience and recommends good values, but does not describe them as a deciding ranking score on their own. Content that answers the question well still comes first; speed makes the difference between two pages of similar quality and keeps visitors on the page.
Conclusion
The order is always the same: find the failing metric with field data, diagnose the cause with lab tools, then fix that cause. On most sites, the bulk of the gain comes from loading the first-screen image correctly, removing unnecessary JavaScript and CSS, and reserving space for elements on the page.
If you would like to review your site’s speed and technical SEO together, take a look at our SEO and digital visibility service, or reach us through the web and mobile app development page for a new project.
