Core Web Vitals Optimization: What to Fix First When Time Is Short

Core Web Vitals optimization with limited time means fixing only the metric your real users fail, on the templates that carry your search traffic, and starting with the fixes web.dev puts first. Its guide to the most effective ways to improve Core Web Vitals leads with three: make the LCP image discoverable and prioritized, break up long JavaScript tasks for INP, and give images, ads and embeds reserved space for CLS.

This post turns that into an order of work you can finish in a few focused sessions.

Key takeaways

• A page passes Core Web Vitals when its LCP, INP and CLS all meet the targets at the 75th percentile, measured separately for mobile and desktop, per web.dev.
• Google uses Core Web Vitals in its ranking systems, but a good page experience does not guarantee a top ranking, per its page experience documentation.
• Search Console's Core Web Vitals report uses 28 days of real-user data and rates each URL group by its weakest metric, per Google's report help.
• The first fixes web.dev recommends are a discoverable, prioritized LCP image, broken-up long JavaScript tasks for INP, and reserved space for images, ads and embeds for CLS.

The targets you are aiming for

A page passes when it meets all three targets at the 75th percentile of page loads, measured separately for mobile and desktop, according to web.dev's Core Web Vitals overview. INP replaced First Input Delay as a Core Web Vital in March 2024, per web.dev's announcement, so any report or checklist that still talks about FID is out of date.

How much do Core Web Vitals matter for SEO?

Enough to fix, not enough to obsess over. Google says "Core Web Vitals are used by our ranking systems," but also that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par," and that a good page experience does not guarantee a top ranking, in its page experience documentation. Treat a failing metric on a template that earns traffic as a real bug. Treat the last few points of a lab score as optional.

Find the failing metric in field data

Start with the Core Web Vitals report in Search Console. It uses real-user data from the Chrome UX Report over the last 28 days, groups similar URLs, and gives each group the status of its most poorly performing metric, per Google's report help. That detail tells you where to spend time: a group marked Poor because of CLS will not improve if you only work on LCP.

Then open PageSpeed Insights for one representative URL from each failing group. The field data section shows which metric fails and by how much, and the lab section helps you find the cause. Lighthouse cannot measure INP in the lab and uses Total Blocking Time as a proxy, per web.dev, so for INP problems rely on field data and on recording real interactions in the Chrome DevTools Performance panel. Our free Core Web Vitals checker runs the same PageSpeed Insights test and shows the field and lab numbers side by side.

Rank the failing groups by the search clicks their pages get in the Search Console Performance report, and fix the template behind the group with the most clicks first. One fix to a product or article template moves every page built on it.

Match the metric to its first fix

How to fix LCP

The web.dev team splits LCP into four parts and suggests a rough share of the total for each, in its LCP optimization guide:

The two delay parts should be as close to zero as possible, so start there. The concrete moves, all from the same guide:

• Put the LCP image in the HTML as an img element rather than a CSS background or a script-inserted element, and add fetchpriority="high". If it has to stay in CSS, preload it with high priority.
• Never lazy-load the LCP image. The guide says doing so "will always lead to unnecessary resource load delay."
• Keep fetchpriority="high" to one or two images; the guide notes it becomes less useful when set on more.
• Remove render-blocking stylesheets and synchronous scripts from the head, inline only very small critical CSS, and break up long tasks that hold rendering back.
• Reduce Time to First Byte with caching and a CDN, and avoid redirects before the HTML.

<!-- Before: lazy-loaded and discovered late -->
<img src="/hero.webp" loading="lazy" alt="Trail runner on a ridge" />

<!-- After: eager, high priority, sized -->
<img
  src="/hero.webp"
  fetchpriority="high"
  width="1200"
  height="630"
  alt="Trail runner on a ridge"
/>

Compressing images and switching to modern formats helps too, but the LCP guide warns that resource load duration is often not the main bottleneck, so do it after the delay fixes.

How to fix INP

An interaction has three phases, input delay, processing duration and presentation delay, as web.dev's INP optimization guide describes. JavaScript that keeps the main thread busy can stretch any of them. Work through the fixes in the order web.dev's top recommendations list them:

• Yield often. A task over 50 milliseconds is a long task, per web.dev's recommendations, and splitting long tasks lets the browser respond to input between chunks.
• Ship less JavaScript. Audit third-party tags, remove the ones nobody uses, and split bundles so each page loads only its own code. The Coverage panel in Chrome DevTools shows code that did not run.
• Keep rendering work small. A smaller DOM renders faster, CSS content-visibility lets the browser skip off-screen work, and grouping DOM reads before writes avoids forced layouts, per the INP guide.
• Do less inside event handlers. Apply the visual update for the next frame and move everything else, such as analytics calls, to a later task.

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processItems(items) {
  for (const item of items) {
    renderItem(item);
    await yieldToMain();
  }
}

scheduler.yield() is not available in every browser, which is why the snippet falls back to setTimeout; web.dev's article lists current support. In real code, yield after a batch of items or a time budget rather than after every item.

If the site runs on a JavaScript framework, hydration and client-side rendering choices shape INP as well. Our post on how JavaScript frameworks affect SEO covers those choices.

How to fix CLS

Layout shifts come from content that arrives without space reserved for it. The web.dev CLS optimization guide lists the causes and their fixes:

• Images and video. Add width and height attributes, or reserve space with CSS aspect-ratio.
• Ads, embeds and iframes. Reserve space with min-height, and size a variable ad slot to the smallest ad you serve. The guide calls ads one of the largest contributors to layout shifts on the web.
• Late-loading content. Place banners and widgets lower on the page, use placeholders, or load them when the user asks. Shifts within 500 milliseconds of user input do not count toward CLS, per the guide.
• Web fonts. Use font-display: optional, or match the fallback font's size with size-adjust, and preload critical fonts.
• Animations. Animate transform instead of top, left or other layout properties.

Also make pages eligible for the back/forward cache, which restores a page on back navigation without repeating its shifts. The web.dev top recommendations name Cache-Control: no-store headers and unload event listeners as reasons a page cannot use it.

What to skip when time is short

• Chasing a Lighthouse score of 100. Lighthouse cannot measure INP, per web.dev, and the Search Console report is built from real-user field data, per Google.
• Pages with too little traffic to have field data. Search Console groups them at the origin level or leaves them out, according to Google's report help, so a template-level fix reaches them anyway.
• Shaving image bytes before fixing load delay, for the reason the LCP guide gives above.
• Rebuilding the front end before trying the template-level fixes in this post.

How to confirm the fix worked

Field data moves slowly. After you ship, start validation on the issue in the Core Web Vitals report; Google monitors it for 28 days and marks it fixed if it does not reappear in that window, per Google's report help. For faster feedback, collect your own field data with Google's open-source web-vitals library, which reports LCP, INP and CLS from real visits to the analytics tool you already use.

For framework code, the technical SEO checklist for developers shows image and font settings in Next.js that help LCP and CLS. Speed is also only one part of page health: the free page analysis scores any URL for SEO, AEO and GEO from 0 to 100 if you want the rest of the page checked while you work on performance.

The short version: read field data, find the failing metric on the template that earns the most traffic, apply its first fix from the table above, ship, and track the result.