How Can I Fix My Website's Core Web Vitals?

Read the report right first

Go to PageSpeed Insights, enter your URL, and ignore the big score for a moment. The report has two halves, and most people read the wrong one.

The field data at the top is what Google actually uses. If it says your LCP is 3.1 seconds, that is what real visitors experienced over the last 28 days. The score below it comes from one simulated load, changes every run, and is for debugging only.

For a site-wide view, open the Core Web Vitals report in Google Search Console instead. It groups your pages by template, so you can see that the blog layout passes and the product layout fails, which is the level you fix at.

The five numbers and what they mean

Three metrics are the actual Core Web Vitals. Two more appear in the same report and help you diagnose the first three.

Each metric fails for different reasons, so each has its own fix list. Work through the one that is failing, not all three at once.

Fix LCP: the page shows too slowly

LCP measures how long the largest element takes to appear, and the largest element is almost always the hero image. The fixes, in order of how often they work:

• Compress the hero image. Serve it as WebP or AVIF, sized to the space it fills. A 2MB JPEG in a 800px slot is the single most common LCP failure.
• Preload it. Add a preload tag for the hero image so the browser fetches it first instead of discovering it late.
• Speed up the server. Get TTFB under 500 milliseconds with page caching or a CDN. The browser cannot paint what the server has not sent. The free HTTP header checker shows whether your caching and compression headers are set.
• Remove render-blocking CSS and JavaScript. Anything loaded in the head before the content delays the first paint. Inline the critical CSS and defer the rest.

Fix INP: the page reacts too slowly

INP measures how fast the page responds when someone clicks, taps, or types. It fails when JavaScript keeps the browser busy. The fixes are all about cutting script work:

• Remove unused scripts. Old trackers, abandoned A/B tools, and duplicate analytics are the usual finds. Every script you delete is free speed.
• Defer third-party scripts. Chat widgets, video embeds, and social buttons do not need to load before the page is usable. Load them after.
• Break up long tasks. A script that runs for 500 milliseconds straight blocks every click during it. Split heavy work so the browser can respond in between.

Fix CLS: the layout jumps around

CLS measures how much the page moves while loading: the paragraph you were reading jumps because an image loaded above it. The fix is to reserve space for everything before it arrives:

• Set width and height on every image and video. The browser then holds the space before the file loads. This one attribute fixes most CLS failures.
• Reserve fixed space for ads and embeds. Give the slot a set height even when the ad has not filled it yet.
• Preload web fonts. Text that renders in a fallback font and then reflows when the real font arrives counts as shift.
• Never inject banners above rendered content. A cookie notice that pushes the whole page down is a self-inflicted CLS failure.

What order to fix things in

Keep the order simple, and let the data pick the target:

1. Read field data, not the score. Fix what real visitors experience, and ignore lab-only wobbles.
2. Fix by template, not by page. The Search Console report already groups pages by layout. One template fix repairs hundreds of URLs at once.
3. Start with LCP. When more than one metric fails, LCP usually has the fastest standard fixes: an image and a server setting.
4. Ship, then wait 28 days. Confirm the fix in a lab test the same day, and in field data a month later.

Why one slow template hurts the whole site

Since Google's March 2026 core update, Core Web Vitals are scored site-wide rather than page by page. A few slow templates now drag on the whole domain, so a failing product-page layout is not just a product-page problem.

Keep the effect in proportion. Speed decides close contests between similar pages. It does not move a page from position 4 to position 40, and it will not rescue content that does not deserve to rank. If your whole site is struggling, run the 20-minute SEO problem check before spending a sprint on speed.

How to check a fix worked

Verify twice, because the two halves of the report update at different speeds:

• Same day: re-run PageSpeed Insights and check the lab numbers moved. This proves the fix works, not that visitors feel it.
• After 28 days: check the field data and the Search Console report. The template should move from Poor toward Good as the rolling average takes the fix in.

Fix the templates with traffic first

A failing template with no visitors can wait. A failing template that carries your search traffic cannot. CrawlRaven's 200-point crawl includes speed checks across every page and joins them with your Search Console data, so slow pages are ranked by the traffic actually at stake.

With the MCP server connected, you can ask for that priority list in one line:

List the pages on [your site] with the most impressions over the last 28 days, grouped by page type, so I know which templates are worth speed work first.

Compare clicks and average position for [your site] over the 28 days since [fix date] against the previous period, for the pages under [template path].

One honest limit: the MCP tools read search performance, not vitals, so the vitals themselves come from PageSpeed Insights and Search Console. The prompts tell you where the fix is worth making and whether traffic moved after it.