Core Web Vitals: how to fix LCP, INP and CLS
Pass Core Web Vitals by fixing field data, not lab scores: find the slow template, fix LCP, INP and CLS in that order, then wait 28 days to confirm.
To fix Core Web Vitals, start from field data in Search Console, not a lab score. Find the page template that fails, then fix Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift in that order. Ship one change at a time, and allow 28 days for the real-user data to confirm it.
Speed is one part of a wider technical SEO checklist. This guide covers only the three metrics Google uses to judge page experience, and how to move each one.
في هذه الصفحة
What are Core Web Vitals, and what counts as a pass?
Core Web Vitals are three measures of how a page feels to a real visitor: how fast the main content shows, how fast the page reacts, and how still it stays. A page passes when all three are good for at least 75% of visits [2].
Here are the three metrics and the numbers you need to hit.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | When the biggest image or text block shows | 2.5 s or less | Over 4 s |
| Interaction to Next Paint (INP) | How fast the page responds to taps, clicks and keys | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much content jumps around while it loads | 0.1 or less | Over 0.25 |
The 75th percentile matters. It means a quarter of your visits can be slow and you still pass, but no more. Mobile and desktop are judged apart, so a page can pass on a laptop and fail on a phone. The phone result is usually the one to worry about.
INP replaced First Input Delay in March 2024 [4]. If an old report or tool still talks about FID, it is out of date. INP is harder to pass, because it looks at every interaction during a visit, not just the first one.
Google uses these signals as part of how it rates page experience [1]. That does not make speed a shortcut to the top. A fast page that does not answer the search still loses. Think of the vitals as a floor: below it, you give away ground to rivals with equal content.
Where do I find my real Core Web Vitals data?
Open the Core Web Vitals report in Google Search Console. It groups your URLs by status and by likely template, and it uses data from real Chrome users. That report, not a lab test, is what counts.
The data comes from the Chrome UX Report, which collects timings from real users who opt in [5]. It is a rolling 28-day window. That has two effects. A fix you ship today shows up slowly. And a page with little traffic may have no data at all, in which case Google falls back to groups of similar pages.
PageSpeed Insights shows two things on one screen. The top panel, when present, is field data for that URL or its origin. The score below is a lab run on one simulated phone. The lab score is useful to debug with, because you can rerun it in seconds. It is not the verdict.
A simple rule: use Search Console to decide what to fix, and use lab tools to find out why.
How do I find which pages to fix first?
Fix by template, not by URL. Search Console groups similar URLs, and on most sites one template covers most of the failing pages. Product pages, blog posts and category pages each share one layout, so one fix passes all of them at once.
Work through it like this.
Export the failing groups
In the Core Web Vitals report, open the mobile view first and list each issue with its example URLs.
Map URLs to templates
Tag each example URL with the layout it uses. Count how many pages each template serves.
Rank by traffic, not by count
Pull clicks per template from the Performance report. Start with the template that earns the most visits and fails.
Reproduce in the lab
Run an example URL through PageSpeed Insights or Chrome DevTools on a throttled phone profile to see what is slow.
Fix one metric, ship, validate
Change one thing, deploy it, and press Validate Fix so the 28-day check starts.
Keep a short log of what you changed and when. Four weeks later you will not remember, and the log is how you know which change moved the number.
How do I fix a slow Largest Contentful Paint?
Make the main image or heading arrive sooner. LCP is almost always slow for one of four reasons: the server answers late, the browser finds the image late, the image is large, or something blocks it from painting [3].
Start with the element itself. In DevTools, the Performance panel names the LCP element. On most pages it is the hero image. If so, check that it sits in the HTML the server sends, not injected later by a script. An image that only exists after JavaScript runs cannot start loading until that script has finished.
Next, tell the browser the image matters. Add fetchpriority="high" to it, and never lazy-load the image at the top of the page. Lazy loading is right for images below the fold and wrong for the one the visitor sees first.
Then shrink it. Serve a modern format such as WebP or AVIF, size it to the space it fills, and use srcset so phones get a smaller file. A 2,000-pixel image squeezed into a 400-pixel slot is the most common waste we see.
Last, look at the server. If time to first byte is slow, no front-end fix will save you. Caching the HTML at the edge, or through a CDN, is often the biggest single win. Sites built with frameworks have extra traps here; our guide to JavaScript SEO on Next.js covers rendering choices that change when the first byte lands.
How do I fix a poor Interaction to Next Paint?
Keep the main thread free, so the page can respond the moment someone taps. INP is slow when JavaScript holds the browser busy and the next frame cannot paint until that work ends [4].
The usual cause is third-party script. Chat widgets, tag managers, A/B testing tools and ad code all compete for the same thread. List every script on the failing template and ask of each one: does it earn its cost? Remove what you can, and load the rest after the page is interactive.
For your own code, break long tasks into small ones. A single function that runs for 300 ms blocks every tap in that window. Splitting it, and yielding back to the browser between parts, lets input through. Also check the handlers themselves: a click that re-renders a large list, or reads and writes layout in a loop, will be slow however little else is running.
How do I stop layout shift?
Reserve space for everything before it loads. CLS happens when content appears late and pushes the rest of the page down, usually just as the visitor goes to tap something.
Set a width and height, or an aspect ratio, on every image and video, so the browser holds the space open. Do the same for ad slots and embeds, which load late by design. Banners for cookies or promotions should sit over the page, not push it down. Web fonts can shift text when they swap in; a matching fallback font keeps that small.
Animations are a quieter source. Moving an element by changing its top or left position counts as a shift. Moving it with a CSS transform does not.
How do I keep Core Web Vitals from slipping again?
Treat the vitals as a release check, not a one-off project. Most sites that pass once fail again within a few months, because a new script, a new hero image or a redesign undoes the work.
Set a budget per template, such as a maximum image weight and a maximum script size, and check it before each release. Watch the Search Console report monthly. Big changes carry the most risk: a redesign or a move to a new platform can reset every metric at once, which is why a site migration checklist should include a speed baseline before and after.
Sites with several languages or regions have one more thing to watch. Each version is often a separate template with its own scripts, and one can fail while another passes. If you are already fixing hreflang errors on those versions, test their speed in the same pass.
How much does it cost to fix Core Web Vitals?
It depends on where the problem sits. Swapping a hero image format or adding size attributes is an afternoon of work. Removing a tag manager full of old scripts can take a week of checking what each one did. A slow server or a rendering model that needs rework is a project measured in weeks.
The cheap fixes cover most sites. If yours needs deeper work, you can see what a scoped engagement costs on our pricing page, or have us run the diagnosis as part of our technical SEO service. That is our own service, so weigh the advice with that in mind; every step above works just as well done in-house.
أسئلة يطرحها الناس
What are the three Core Web Vitals?
Largest Contentful Paint measures loading, Interaction to Next Paint measures responsiveness, and Cumulative Layout Shift measures visual stability. Google calls a page good when all three pass at the 75th percentile of real visits.
Why does PageSpeed Insights show a good score but Search Console says my pages fail?
The score at the top of PageSpeed Insights is a lab test on one simulated device. Search Console uses field data from real Chrome users over 28 days. Only the field data decides whether you pass.
How long after a fix will Search Console show the change?
Field data is a rolling 28-day window, so a fix shows in full about four weeks after it ships. Use the Validate Fix button to start the check, and keep the change stable while it runs.
Will passing Core Web Vitals raise my rankings?
Not on its own. Google says good page experience is rewarded, but relevance comes first. Passing removes a drag on pages that already compete; it does not lift a page that does not answer the query.
Which metric should I fix first?
The one that fails on the template with the most traffic. On most sites that is LCP on mobile, because the hero image is large and late. INP comes next on sites heavy with scripts.
المصادر
- Understanding Core Web Vitals and Google search results — Google Search Central (checked 22 September 2026)
- Web Vitals — web.dev (checked 22 September 2026)
- Largest Contentful Paint (LCP) — web.dev (checked 22 September 2026)
- Interaction to Next Paint (INP) — web.dev (checked 22 September 2026)
- Chrome UX Report overview — Chrome for Developers (checked 22 September 2026)
Want a second pair of eyes on your slowest template?
احجز استشارة مجانية مدتها 30 دقيقة مع إبراهيم وجيريمي. ننظر في موقعك أثناء الحديث، وتخرج بخطة مرتّبة حسب الأولوية.
من كتب هذا
Ibrahem HelalCo-founder
Leads strategy and delivery.
يعمل على: SEO, GEO
راجعه قبل النشر Jeremy Zava، Co-founder.
المزيد عن هذا
- Technical SEO: the complete checklist for 2026Technical SEO makes sure search engines and AI crawlers can reach, render and index your pages. This checklist covers every layer, in the order to fix it.
- JavaScript SEO: Get Google to See Your PagesJavaScript SEO means rendering content so crawlers see it without running your scripts: pick server rendering, check the raw HTML, and avoid client-only routes.
- Hreflang Errors: How to Find and Fix ThemHreflang errors mostly come from missing return tags or wrong language codes. Here is how to find every broken pair and fix them without breaking more.
- Site Migration SEO: The Full ChecklistA site migration loses traffic when redirects, canonicals or content go missing. This checklist covers the mapping, the launch and the four weeks after.