# How to improve Core Web Vitals and pass the assessment
> How to improve Core Web Vitals: find the metric and template that fail in the field, fix the usual cause of each (LCP, INP, CLS) in the right order, and confirm the pass over 28 days.
Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/how-to-improve-core-web-vitals
To improve Core Web Vitals, first find which metric fails for real visitors and on which page template, then fix that metric's usual cause: a slow server or a late hero image for LCP, heavy JavaScript for INP, and images, ads or fonts without reserved space for CLS. Fix LCP first if several fail, change one thing at a time, and confirm the result in the field data, which takes about 28 days to catch up. Passing the assessment means all three metrics are good at the 75th percentile.
This guide is the working plan for site owners, marketers and developers who have seen "Core Web Vitals Assessment: Failed" in PageSpeed Insights or a Poor group in Search Console. It covers triage, the fixes with the biggest effect per metric, and how to verify. What each metric means is explained in [Core Web Vitals explained for site owners](https://getreport.app/guides/core-web-vitals-for-site-owners).
## Quick answer
- **Start from field data,** not the Lighthouse score. The assessment uses real Chrome visitors at the 75th percentile over 28 days.
- **Fix templates, not URLs.** Search Console groups similar pages; one product template fix covers thousands of URLs.
- **Mobile first.** It fails more often and is assessed separately from desktop.
- **LCP:** fast server response with page caching, a compressed hero image that is not lazy-loaded, fewer render-blocking files.
- **INP:** less JavaScript on the main thread, fewer third-party tags, lighter event handlers.
- **CLS:** width and height on images, reserved space for ads and embeds, fonts that do not reflow.
- **Verify twice:** the lab the same day, the field over the next four weeks.
## Step 1: read the assessment the way Google does
The Core Web Vitals assessment passes when LCP, INP and CLS are all "good" at the 75th percentile of real visits. The thresholds are Google's, published on web.dev:
| Metric | Good | Needs improvement | Poor |
| --- | --- | --- | --- |
| LCP | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
One metric outside "good" is enough to fail. A "Core Web Vitals Assessment: Failed" banner in PageSpeed Insights sits above the lab score, and it can appear on a page with a green lab score, because it comes from different data: 28 days of real visitors instead of one simulated load. The banner also tells you whether it is judging "this URL" or the whole origin; low-traffic pages are often judged on the origin's numbers.
Start with a test that shows both sources for the page:
> **Free tool:** [Core Web Vitals test: check LCP, INP and CLS](https://getreport.app/tools/core-web-vitals): Free Core Web Vitals test: LCP, INP and CLS from real Chrome users next to the lab values, rated against Google's thresholds, with what to fix. No sign-up.
The Core Web Vitals test reads LCP, INP and CLS from the Chrome UX Report for the URL and the origin, rates each against the thresholds, and runs a Lighthouse lab test beside it that names the element and the files responsible. INP only appears in the field data, because a lab run does not tap anything.
> **Check: Real-user Largest Contentful Paint.** LCP is when the biggest element on screen finishes loading. Google's threshold for "good" is 2.5 s at the 75th percentile of real Chrome users.
>
> 1. Find the LCP element in the Speed module and make it smaller, earlier or both.
> **Check: Real-user Interaction to Next Paint.** INP is how long the page takes to visibly react to taps and clicks, measured on real Chrome users over the last 28 days. Google's threshold for "good" is 200 ms.
>
> 1. Cut long JavaScript tasks and heavy third-party scripts; see the INP finding above.
> **Check: Real-user Cumulative Layout Shift.** CLS on real visitors' devices over the last 28 days. Google's threshold for "good" is 0.1; layout jumps hit hardest on slow phones with late-loading ads and fonts.
>
> 1. Reserve space for images, embeds and ads; see the CLS finding above.
For the whole site, open Search Console → Core Web Vitals, mobile report first. Each issue ("LCP issue: longer than 2.5 s (mobile)") lists groups of similar URLs with an example URL. Those groups are your work list.
## Step 2: triage a failed assessment
Match what you see to the likely cause before touching anything:
| What fails | What the lab shows | Likely cause | First fix |
| --- | --- | --- | --- |
| LCP | High TTFB (over 0.8 s) | Server: no page cache, slow host, redirects | Page caching, remove redirect hops, CDN |
| LCP | Fast TTFB, LCP element is an image | Hero image too large, lazy-loaded or found late | Resize, WebP/AVIF, `fetchpriority="high"`, no lazy-load |
| LCP | Fast TTFB, LCP element is text | Render-blocking CSS or a web font | Defer non-critical CSS and JS, `font-display: swap` |
| INP | High Total Blocking Time | Heavy JavaScript during load | Remove or delay third-party tags, split bundles |
| INP | Low Total Blocking Time | A slow interaction later in the visit | Find the slow tap in Chrome's Performance panel |
| CLS | Lab CLS high | Images or embeds without dimensions, fonts | `width`/`height`, `aspect-ratio`, font fallbacks |
| CLS | Lab CLS low | Shift after load: late ads, banners, infinite scroll | Reserve space for anything injected later |
| Nothing in the field | Lab only | Not enough Chrome traffic | Fix clear lab problems; wait for data |
If more than one metric fails, fix **LCP first**: it fails most often, it has the clearest fixes, and some of them (a faster server) help everything else. Then INP, then CLS, which is often the quickest.
## Step 3: fix LCP
Web.dev splits LCP into four parts, and each has its own fix. The lab result in the Core Web Vitals test shows the LCP element; the [LCP guide](https://getreport.app/guides/fix-largest-contentful-paint) explains how to read each part.
1. **Time to first byte.** The server's answer. Turn on full-page caching on a CMS, remove redirect chains, and put a CDN in front for distant visitors. See [TTFB: what a slow server looks like](https://getreport.app/guides/ttfb-what-a-slow-server-looks-like).
2. **Resource load delay.** The time before the browser starts downloading the LCP image. The image must be in the HTML, not added by JavaScript or a CSS background, and must not be lazy-loaded. Add `fetchpriority="high"` to it.
3. **Resource load duration.** The download itself. Serve the image at the size it is shown, in WebP or AVIF, with `srcset` for phones. See [image optimization](https://getreport.app/guides/image-optimization).
4. **Element render delay.** The time between the image arriving and being painted: render-blocking CSS and JavaScript in the ``, or a web font the headline waits for. See [render-blocking resources](https://getreport.app/guides/render-blocking-resources).
```html
```
> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with or add fetchpriority="high" on the .
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.
> **Check: Offscreen images are lazy-loaded.** Images far below the fold compete for bandwidth with the ones visitors see first. Lazy loading defers them until they scroll into view.
>
> 1. Add loading="lazy" to images below the fold — but never to the hero/LCP image.
> 2. WordPress adds it by default since 5.5; check your theme or slider has not removed it.
## Step 4: fix INP
INP measures the delay between a tap, click or key press and the next frame the browser paints, and reports roughly the slowest interaction of the visit. It fails when JavaScript keeps the main thread busy at the moment the visitor interacts. The three parts, and what shortens each:
- **Input delay:** the browser is busy with other work when the tap arrives. Remove third-party tags nobody uses, delay the rest until after load or until interaction, and break long tasks into smaller ones.
- **Processing time:** the event handler itself does too much. Do the visible update first and defer the rest; in modern browsers `scheduler.yield()` (with a `setTimeout` fallback) gives the browser a chance to paint between steps.
- **Presentation delay:** rendering the result takes long, often because the page has a very large DOM or a change forces the whole layout to recalculate.
If the lab's Total Blocking Time is high, start with the scripts that run during load: the third-party finding lists them by domain with their blocking time. If TBT is low but field INP is poor, the slow interaction happens later: opening the menu, using filters, typing in search. Record it in Chrome's developer tools → Performance panel. [Fix Interaction to Next Paint](https://getreport.app/guides/fix-interaction-to-next-paint) and [long tasks and main-thread work](https://getreport.app/guides/long-tasks-and-main-thread-work) go through both cases.
> **Check: Total Blocking Time.** TBT adds up every moment the page was too busy running JavaScript to respond to a tap. It is the lab stand-in for INP and the heaviest-weighted Lighthouse metric.
>
> 1. Remove or defer JavaScript that is not needed for the first screen (defer, async, or load on interaction).
> 2. Split long tasks (> 50 ms) into smaller chunks; move heavy work to a web worker.
> 3. Audit third-party tags — chat widgets, tag managers and A/B tools are the usual culprits.
> **Check: Third-party code weight.** Tags, widgets and embeds from other companies run on your visitors' phones at your page's expense. Over 250 KB or 250 ms of blocking is a sign they dominate the load.
>
> 1. List what each third party gives you; remove the ones nobody looks at.
> 2. Load the rest after interaction or with a facade (a static thumbnail for YouTube, a click-to-load chat button).
> 3. Move tags into a tag manager that fires them late, not in .
## Step 5: fix CLS
Layout shifts come from a short list of causes, and the fixes are mostly CSS:
1. **Images and video without dimensions.** Add `width` and `height` attributes, or `aspect-ratio` in CSS, so the browser reserves the space.
2. **Ads, embeds and iframes.** Give their containers a minimum height matching the most common size.
3. **Content injected above what the visitor is reading:** cookie banners, notices, "related products" rows. Overlay banners instead of pushing content, or insert below the viewport.
4. **Web fonts.** A fallback font with different metrics reflows the text when the web font arrives. Match the fallback's size with `size-adjust`, or preload the main font. See [web fonts without layout shift](https://getreport.app/guides/web-fonts-without-layout-shift).
5. **Animations** that change `top`, `height` or `margin`. Use `transform` instead.
Pages that can be restored from the browser's back/forward cache also avoid shifts and load instantly on back-navigation, so avoid what blocks it, such as `unload` event handlers. [Fix Cumulative Layout Shift](https://getreport.app/guides/fix-cumulative-layout-shift) has the CSS for each case.
> **Check: Cumulative Layout Shift.** CLS measures how much the page jumps around while loading — the button that moves just as someone taps it. It is one of Google's three Core Web Vitals.
>
> 1. Give every ,
```
> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with or add fetchpriority="high" on the