Core Web Vitals Optimization: A Practical Guide

What Core Web Vitals are

Core Web Vitals are three metrics Google uses to judge how a page feels to real visitors. Largest Contentful Paint (LCP) is a measure of loading: when the main content appears. Interaction to Next Paint (INP) is a measure of responsiveness: how fast the page visibly reacts to a tap, click or key press. Cumulative Layout Shift (CLS) is a measure of visual stability: how much content moves while the page loads.

Google publishes a good threshold for each one, and a page passes only when all three are good at the 75th percentile of visits, measured separately for mobile and desktop. The verdict comes from field data: timings collected from real Chrome users and published in the Chrome User Experience Report (CrUX). PageSpeed Insights shows that field data for a page, and falls back to the whole site when a single page has too few visits.

Interaction to Next Paint replaced First Input Delay (FID) as the responsiveness metric on 12 March 2024. First Input Delay only measured the delay before the first interaction was handled, so a page could pass while every later click lagged. INP looks at interactions through the whole visit. Any guide that still quotes a 100-millisecond FID target is out of date.

Measure before you change anything

Open PageSpeed Insights and test your home page and your three most visited pages, on mobile first. Note the field data for each metric, not just the lab score at the top. Then open the Core Web Vitals report in Search Console, which groups your URLs into good, needs improvement and poor. That report tells you how many pages fail and which metric fails most often.

Lab scores from Lighthouse and Chrome DevTools are for debugging, not for the verdict. They run on a simulated device and connection, so they change from run to run. Use them to find the cause of a problem, then judge the fix by the field data.

Fix LCP: make the main content appear sooner

Largest Contentful Paint is usually a large image, a hero banner or a headline block. Four fixes cover most slow LCP scores.

1. Shrink the LCP image. Compress it, serve it in a modern format such as WebP or AVIF, and size it to the space it fills. A 4,000-pixel photograph shown at 800 pixels wide wastes most of its download.
2. Preload the LCP image. Add a preload hint for the hero image so the browser fetches it first, instead of discovering it late in the page.
3. Cut server response time. A slow server delays everything after it. Check Time to First Byte, and fix slow database queries, uncached pages and distant hosting before you chase smaller wins.
4. Remove render-blocking resources. Stylesheets and scripts in the head hold up the first paint. Defer scripts that are not needed for the first screen, and inline only the CSS the top of the page needs.

Check what the LCP element actually is before you start. PageSpeed Insights names it under the LCP diagnostic. If it is a background video or a slider, no amount of image compression will fix it; the element itself has to change.

Fix INP: make the page answer taps faster

Interaction to Next Paint is slow when the browser's main thread is busy. Long JavaScript tasks, third-party scripts and heavy event handlers all add delay between a tap and the visible response.

1. Break up long tasks. Split JavaScript work longer than 50 milliseconds into smaller chunks, so the browser can answer an input between them.
2. Defer third-party scripts. Chat widgets, social embeds, tag managers and analytics scripts are the usual suspects. Load them after the first interaction, or remove the ones nobody uses.
3. Reduce JavaScript on the page. Remove unused libraries, and avoid shipping the same code twice through overlapping plugins or themes.
4. Avoid work on every keystroke. Search boxes and filters that run a full search on each character typed will block the page. Add a short delay, and only run the search when the user pauses.

Test INP by using the page the way a visitor does: tap the menu, open a filter, type in the search box, submit the form. A lab test that never clicks anything cannot measure INP properly.

Fix CLS: stop the layout moving

Cumulative Layout Shift happens when content appears late and pushes what is already on screen down or sideways. Ads, images without dimensions, web fonts and late-loading banners are the usual causes.

1. Give images and videos width and height. Reserve the space before the file loads, so the text below does not jump when the image arrives.
2. Reserve space for ads and embeds. An ad slot with no fixed size will shove the article down when the ad loads. Set a minimum height for the slot, even when no ad fills it.
3. Load web fonts carefully. A font swap changes line heights and moves text. Use font-display: swap, and keep fallback fonts close in size to the web font.
4. Do not insert content above existing content. Banners, cookie notices and pop-ups that appear at the top of the page after it loads are the worst CLS offenders. Place them at the bottom, or reserve their space in advance.

CLS is the cheapest metric to fix, and the easiest to break again. Every new banner, embed or ad slot needs a reserved space, or the score drifts back.

A worked example

The worked example below uses a small ecommerce product page. Its field data shows LCP at 4.2 seconds, INP at 320 milliseconds and CLS at 0.28. All three fail.

PageSpeed Insights names the LCP element as a 2.1 MB hero photograph, served at full camera resolution. The INP diagnostic points to a chat widget and a review carousel script. The CLS diagnostic points to the hero image, which has no width or height, and a cookie banner that appears at the top of the page.

The fix order follows the size of the problem. First, the hero image is resized to the display width, compressed to WebP and preloaded, which brings LCP to about 2.4 seconds in the lab test. Second, the chat widget is set to load after the first user interaction, and the carousel script is deferred, which brings INP to about 180 milliseconds. Third, width and height are added to the image, and the cookie banner is moved to the bottom of the screen with its space reserved, which brings CLS to about 0.02.

The lab scores improve the same day. The field verdict takes longer: the 28-day rolling window needs enough new visits at the improved speed before the page moves from poor to good. That is normal, and it is why you should not re-test the field data every day.

Common mistakes

• Chasing the lab score. A Lighthouse score of 100 does not mean the page passes. The verdict uses field data from real users on real devices and connections.
• Fixing desktop first. Most traffic is mobile, and mobile is assessed separately. A page can pass on desktop and fail on mobile.
• Adding a speed plugin and stopping. Caching and minification help, but they do not fix a 2 MB hero image, a chat widget that blocks the main thread, or an ad slot with no reserved space.
• Testing once. Performance drifts as new scripts, images and banners are added. Check the Search Console report monthly, and after every site change.
• Ignoring the template. If 200 product pages fail the same metric, the cause is in the shared template, not in 200 separate pages. Fix it once, in the template.

Glossary

• Field data: measurements from real users visiting your site, collected by Chrome and reported in CrUX.
• Lab data: measurements from a simulated test in Lighthouse or DevTools, useful for debugging but not for the verdict.
• LCP: Largest Contentful Paint, the time until the largest content in view finishes rendering.
• INP: Interaction to Next Paint, the delay from a tap, click or key press until the page shows the next frame.
• CLS: Cumulative Layout Shift, a score for how much visible content moves without the visitor asking it to.
• CrUX: Chrome User Experience Report, the public dataset of real-user timings that powers the field data in PageSpeed Insights and Search Console.
• TTFB: Time to First Byte, the time from the request to the first byte of the response; a slow TTFB delays LCP.

Checklist: run this before you call the job done

• [ ] PageSpeed Insights field data checked for the home page and top three pages, mobile and desktop.
• [ ] The LCP element named, and the fix aimed at that element.
• [ ] Hero images resized, compressed and preloaded where they are the LCP element.
• [ ] Third-party scripts listed, with any unused ones removed and the rest deferred.
• [ ] Width and height set on every image and video above the fold.
• [ ] Space reserved for ads, embeds and banners.
• [ ] INP tested by tapping, typing and submitting, not by loading the page alone.
• [ ] Search Console Core Web Vitals report checked, and the fix date noted so the 28-day window can be judged fairly.
• [ ] The same checks repeated after any theme, plugin or template change.

Core Web Vitals work is maintenance, not a one-off project. A page that passes today can fail after a new chat widget, a heavier hero image or an extra tracking script. The routine above takes an hour a month on a small site. If the fixes need development help, Adziq's web design services and SEO services cover site speed as part of a wider technical review, and the SEO vs Google Ads guide explains where speed fits beside paid traffic.

Common questions

Sources

• Web Vitals (web.dev)

Adziq sells marketing services and does not accept payment for placement in its articles. See our editorial policy.