Core Web Vitals without the jargon: what each one measures and how to fix it

Core Web Vitals get treated as a mysterious Google requirement, and they are not. They are three measurements of things users genuinely complain about: the page took too long to show anything, it did not respond when I tapped, and it moved while I was reading it.

Understand what each one is actually measuring and the fixes become obvious and quite dull.

LCP: how long until the main thing appears

Largest Contentful Paint measures when the biggest element in the viewport finishes rendering. Usually that is a hero image or a block of heading text. It is the closest metric to "did the page feel like it loaded".

The cause is nearly always one of three things: an oversized hero image, a slow server response, or a render-blocking resource in the head. In that order of likelihood.

• Oversized hero image. Resize it to display dimensions, convert to WebP, and preload it. This alone fixes most LCP failures.
• Slow server response. If the HTML takes 800ms to arrive, nothing you do in the browser saves you. This is an infrastructure problem.
• Render-blocking CSS or fonts. Inline critical CSS and let fonts swap rather than block.

INP: how long until the page responds to a tap

Interaction to Next Paint replaced First Input Delay and measures something more honest: across the whole visit, how long does the page take to visibly respond when the user interacts. A page can load fast and still fail this badly.

The cause is almost always JavaScript occupying the main thread. Too much of it, running for too long, in one uninterrupted block. Splitting long tasks and deferring work that does not need to happen during load is the fix.

CLS: how much the page moves while you read it

Cumulative Layout Shift measures unexpected movement. Everyone has experienced this: you go to tap a link, an ad or an image finishes loading above it, everything jumps, and you tap the wrong thing.

The fix is genuinely simple and widely skipped: reserve space for anything that loads late. Width and height attributes on images. Fixed dimensions for ad slots and embeds. Never insert content above existing content after load.

Lab data versus real users

This distinction matters and trips people up. A synthetic test runs on one machine on one connection and gives you a repeatable number you can debug against. Field data comes from actual visitors on actual devices, and it is what Google uses.

You need both. Lab data to iterate quickly, field data to know whether it mattered. siteIQ runs the performance testing side and identifies which specific assets are hurting each metric, which is the part a bare score never tells you.

When it is not a front-end problem

Sometimes the HTML itself is slow to arrive, and no amount of image optimisation helps. That points at hosting, database queries, or missing caching, and it needs infrastructure work rather than front-end work. CodeAiMan's cloud and DevOps practice handles that end, and their website speed guide covers the diagnosis.

For sites being built rather than fixed, getting this right from the start is far cheaper. CodeAiMan's web development team builds in Next.js and React with these constraints assumed rather than retrofitted.

Frequently asked questions

Referenced in this article