Core Web Vitals in plain English (and what to actually fix)

Core Web Vitals is Google's attempt to measure whether a page feels good to use, in numbers. There are three, and each corresponds to an ordinary question a visitor would ask without knowing they were asking it.

They are a modest ranking factor. They are a substantial conversion factor, which is the better reason to care: a visitor who taps your phone number and hits an ad because the layout shifted is a lost customer regardless of where you rank.

LCP: did the main thing appear?

Largest Contentful Paint measures how long until the biggest element in the viewport is drawn — usually your hero image or headline. It is a proxy for 'has the page started being useful yet'.

The four usual causes, in order

1. An enormous hero image. A 4 MB photo straight off a phone. This one cause accounts for a large share of failing small business pages, and it is the easiest to fix.
2. Slow server response. Shared hosting under load, or a page that queries a database several times before returning anything. Anything over about 600ms to first byte is worth investigating.
3. Render-blocking resources. Stylesheets and fonts that must download before anything is painted.
4. Client-side rendering. A page that ships an empty shell and then builds itself in JavaScript. The visitor watches a blank screen while the framework boots.

The fixes that matter

• Compress and resize every image — 1600–2000px wide is plenty for a full-width hero.
• Serve WebP or AVIF rather than JPEG or PNG.
• Set explicit width and height on every image.
• Preload the hero image; lazy-load everything below the fold — and never lazy-load the hero itself, which is a common and self-defeating mistake.
• Self-host fonts rather than fetching them from a third-party CDN at render time.
• Subset fonts to the characters you use and limit yourself to two or three weights.
• Use font-display: swap so text is readable while the webfont loads.
• Serve pre-rendered HTML where you can, rather than building the page in the browser.

INP: does it respond when tapped?

Interaction to Next Paint measures the delay between a tap or click and the screen visibly updating. It replaced First Input Delay because FID only measured the *first* interaction, which flattered pages that were fine once and sluggish thereafter.

The cause is nearly always the same: the browser's main thread is busy running JavaScript, so it cannot get to your tap. On small business sites the JavaScript usually belongs to somebody else.

• Chat widgets. Often the single heaviest thing on the page. Ask honestly whether yours produces enough enquiries to justify it; many are installed and then never monitored.
• Tag managers with a decade of accumulated tags. Audit what is actually firing. Old pixels for campaigns that ended years ago are extremely common.
• Multiple analytics tools measuring roughly the same thing.
• Social embeds. An Instagram feed or a Facebook page plugin can pull in hundreds of kilobytes of script for a widget nobody scrolls to.
• Page builder bloat. Some builders ship the JavaScript for every module they support, whether or not the page uses them.

CLS: does it stop moving?

Cumulative Layout Shift measures content jumping as the page loads. It is the metric behind the universal experience of going to tap a link and hitting something else because a banner loaded above it.

Causes and fixes

How to test properly

1. 01PageSpeed Insights firstRun your URL through pagespeed.web.dev. Read the top section — 'Discover what your real users are experiencing' — before the score. That section is field data from actual visitors; the big number below it is a lab simulation.
2. 02Understand the difference between lab and fieldLab data is a single simulated load on a throttled connection: repeatable, useful for debugging, not reality. Field data comes from real Chrome users over 28 days and is what Google actually uses. A great lab score with poor field data means real visitors are on worse devices and connections than the simulation assumed.
3. 03Check Search ConsoleThe Core Web Vitals report groups your URLs by status and by shared cause, which tells you whether a problem is one page or a template affecting fifty.
4. 04Test on a real phoneA mid-range Android on cellular data, away from your office wifi. This is the single most informative test available and it costs nothing.
5. 05Test the pages that matterYour home page, your top service page and your contact page. Not just the home page, which is usually the most optimised page on the site.

The eighty-twenty list

If you only do five things, do these. On a typical small business site they account for most of the achievable improvement.

1. Compress and correctly size every image, and serve WebP.
2. Set width and height on every image and reserve space for anything injected.
3. Remove third-party scripts that do not earn their place.
4. Self-host fonts, two weights maximum, with font-display: swap.
5. Serve HTML that is ready to render rather than assembling the page in the browser.