How to improve Core Web Vitals: a practical checklist

A checklist for passing LCP, INP and CLS: which fix helps which number, the order to work in, and a four-week plan for a typical business site.

In this guide

Before you start
Which fix helps which number
The checklist
A four-week plan for a typical small business site
What a pass looks like
Check your own page
Sources

Before you start

Four things make the rest of the work easier.

Know your numbers. Check the real-visitor result for mobile in PageSpeed Insights for your home page and two or three important pages. Write down LCP, INP and CLS for each. If a number is already green, you do not need to touch it. The Core Web Vitals guide explains the marks and the rules.
Take a backup, and work on a copy of the site if you can.
Choose one failing metric. The one that is furthest into the red, or that fails on most of your pages.
Decide how you will test. The same page, the same device setting, three runs and the middle result.

Which fix helps which number

A small number of changes help more than one metric. Do those first.

Fix	LCP	INP	CLS
A page cache and a fast server	Yes
The main image: right size, not lazy-loaded, high priority	Yes
Width and height on images, space for embeds and banners			Yes
Fewer, smaller web fonts and a matched fallback	Yes		Yes
Remove unused scripts and plugins	Yes	Yes
Defer scripts the first screen does not need	Yes	Yes
Control third-party scripts	Yes	Yes	Yes
Inline the critical CSS and unblock the first paint	Yes
Break up long tasks and do less in event handlers		Yes
A smaller page structure and `content-visibility`		Yes
Animate with transforms, not layout properties			Yes

Third-party code is on the list three times for a reason: chat widgets, ads and embeds slow the load, block responses and move the page.

The checklist

1. Server and cache (LCP)

The server answers in under about 600 milliseconds with the cache on.
A page cache is on, and the pages that are personal are excluded.
A CDN is in front of the site if visitors are far from the server (what a CDN is).
No redirect chains: links go to the final address.

See time to first byte and caching explained.

2. The main image (LCP)

The main image is a normal img element, not a CSS background or a script-built slide.
It is not lazy-loaded.
It has fetchpriority="high", and it is the only one with it, or one of two.
It is the size it is displayed at, in WebP or AVIF, with a fallback.
If it is on another domain, a preconnect hint exists.

See how to fix a slow LCP and image optimization.

3. Scripts (LCP and INP)

Every script is needed. Unused plugins and tags are removed.
Scripts that the first screen does not need have defer or async.
Large bundles are split so each page loads only what it uses.
Third-party tools load later, or behind a click.
The tag manager is tidy.

See third-party scripts and render-blocking resources.

4. Responsiveness (INP)

You have tried the interactions visitors use most, with the CPU slowed down.
The slowest interaction's longest part is known: input delay, processing or presentation.
Heavy work in handlers is split up, so the visible change comes first.
The page is not much larger than it needs to be.

See how to fix a slow INP and Total Blocking Time.

5. Visual stability (CLS)

Every image, video and embed has a set size or an aspect ratio.
Banners and bars are overlays, or have space reserved from the first frame.
Late content has a placeholder of about the right height.
Web fonts have a matched fallback and a sensible display setting.
Animations use transforms.

See how to fix layout shift and web fonts and speed.

6. Keep it that way

Test your top pages monthly.
Test before and after adding any plugin, script or large image.
Review third-party tags every quarter.

A four-week plan for a typical small business site

This is an illustration, not a promise. It shows the order, and how long the real-visitor data takes to respond.

Week 1: measure and quick wins. Record the numbers. Turn on the cache. Fix the main image. Set sizes on images. Remove unused plugins and tags. Test.

Week 2: scripts and the first paint. Defer scripts. Deal with the heaviest third party. Handle fonts. Inline critical CSS if blocking CSS is a problem. Test.

Week 3: the specific failing number. If INP fails, record the slow interactions and fix the longest part. If CLS fails, use the layout shift list. If LCP still fails, look at the four parts again. Test.

Week 4: confirm. Watch the real-visitor numbers move. They cover a rolling 28 days, so the full effect of Week 1 shows by Week 5. Do not add anything new meanwhile, so that the data is clean.

What a pass looks like

A page passes when LCP, INP and CLS are all good at the 75th percentile for real visits, for mobile and desktop separately. Passing is not permanent: new scripts, plugins and images undo it, and the data covers only the last 28 days. Check again after major changes, and set a reminder to look every month.

Check your own page

Run the free audit and tick off the checklist against the report. The items that the report flags are your list; the rest you can leave. Work through them in the order above, and test after each one.

Sources

Web Vitals on web.dev: the three metrics and how a page passes.
Optimize Largest Contentful Paint, Optimize Interaction to Next Paint and Optimize Cumulative Layout Shift on web.dev: the guidance behind each section.
Chrome UX Report methodology: the 28-day window.