How to fix Core Web Vitals: LCP, INP and CLS

A poor Core Web Vitals report can look overwhelming: a red label, three abbreviations and a list of pages. In practice, most problems come from a handful of causes, and the same few fixes clear most of them. This lesson takes each metric in turn: what usually goes wrong, what to change, and how to confirm it worked.

If you need a refresher on what the three numbers mean and their good scores, see what are Core Web Vitals.

Step 1: find which metric fails, and where

Do not start fixing before you know what is wrong.

1. In Search Console, open the Core Web Vitals report. Start with mobile. It groups pages by the metric that fails, such as "LCP issue: longer than 2.5 s".
2. Open a group to see example pages. Pages built from the same template usually share the same problem, so fixing one template fixes them all.
3. Paste one example into PageSpeed Insights. The top section shows real-visitor data; the Diagnostics further down name the likely causes.

The free audit shows the same three numbers for any page, with the server response time next to them.

Fixing LCP: make the main content appear sooner

Largest Contentful Paint is usually the hero image or the main headline. It is slow for one of four reasons:

• A slow server. If time to first byte is high, everything else waits. Use page caching, a CDN and up-to-date hosting.
• A heavy image. Serve the main image in WebP or AVIF, at the size it is actually shown. A 3,000-pixel photo shown 800 pixels wide wastes seconds on a phone.
• A late image. Never lazy-load the main image at the top of the page. Add fetchpriority="high" to it so the browser fetches it first.
• Blocking files. Fonts, style files and scripts that load before the content hold it back. Defer scripts that are not needed straight away.

Fixing INP: make the page answer faster

Interaction to Next Paint measures how quickly the page reacts to taps and clicks. When it is slow, the browser is busy running JavaScript.

• Remove what you do not need. Old tracking tags, unused plugins, sliders and chat widgets often load scripts on every page.
• Load the rest later. Scripts for things below the fold can wait until the page is idle or until someone scrolls near them.
• Break up long tasks. For your own code, split heavy work into smaller pieces so the browser can respond in between. Your developer will know this as "yielding to the main thread".

Fixing CLS: stop the layout from jumping

Cumulative Layout Shift comes from things appearing and pushing content down. The fix is almost always to reserve the space in advance:

• Give every image and video a width and height, so the browser saves the right space before it loads.
• Reserve a fixed space for ads, embeds and cookie banners, or show them in a way that does not push content.
• Do not insert banners or notices above content that is already on screen.
• For web fonts, use font-display: swap with a fallback font of similar size, so text does not jump when the font arrives.

Step 2: confirm the fix

Real-visitor data covers the last 28 days, so improvements show slowly.

1. Check the page in PageSpeed Insights a few days after the change. The lab section updates at once and confirms the cause is gone.
2. In Search Console, open the failing group and click Validate fix. Google then watches the pages for 28 days and tells you whether they pass.
3. Look again after a month. Most groups move to good in one go.

Speed is one part of a healthy page. Crawling and indexing, explained simply and how to read the Crawl stats report cover what happens before a page can rank at all, and the viewport entry covers the mobile basics.

This is lesson 6 of the Technical SEO series.