Core Web Vitals for non-engineers

Three letters that decide how your page feels

Core Web Vitals sound like something only a developer should worry about. They are not. They are Google's attempt to measure, in numbers, three things every visitor feels in the first few seconds on your site: how fast the page shows up, how quickly it responds when they tap something, and whether it stays still or jumps around while it loads.

You do not need to write a line of code to understand them. What you do need is the ability to tell when a page is failing one of them and to hand your developer a clear, specific request instead of "the site feels slow". This is that translation.

If you want the wider picture of how the pieces fit together, our SEO guide for founders covers where Core Web Vitals sit in the larger crawl-index-serve story. Here we go deep on the three metrics themselves.

LCP: how long until the page looks ready

LCP stands for Largest Contentful Paint. In plain English: how long it takes for the biggest, most important thing on the screen to appear. Usually that is your hero image, a headline, or a banner.

If someone lands on your page and stares at a blank white screen for four seconds before your main image shows up, your LCP is bad. Google wants it under 2.5 seconds.

What makes it slow, and what to ask for:

• Heavy, unoptimised images. A 4MB hero photo is the single most common culprit. Ask your developer to compress images and serve them in a modern format like WebP or AVIF.
• A slow server. If the page takes a long time just to start responding, no amount of image trickery will save it. Ask whether the hosting or the database queries behind the page are the bottleneck.
• Render-blocking files. The browser sometimes waits for scripts and stylesheets before it draws anything. Ask your developer to "defer non-critical JavaScript and inline the critical CSS". You do not need to know what that means; they will.

INP: how snappy the page feels when you use it

INP stands for Interaction to Next Paint. It measures the lag between you doing something (tapping a button, opening a menu, ticking a box) and the page actually reacting.

You know that feeling when you tap "Add to cart" and nothing happens, so you tap again, and then two things happen? That is bad INP. Google wants interactions to respond in under 200 milliseconds.

INP replaced an older metric called First Input Delay in 2024, so if a tool or an old article mentions FID, it is out of date.

What makes it bad, and what to ask for:

• Too much JavaScript running at once. When the browser is busy executing a pile of scripts, it cannot respond to your taps. Ask your developer to "break up long tasks" and audit third-party scripts.
• Heavy third-party tags. Chat widgets, analytics, ad scripts, and tracking pixels all compete for attention. Ask which ones are actually earning their keep, and load the rest later.
• Bloated frameworks doing work on the wrong device. Cheap phones are far slower than the laptop your developer tests on. Ask them to profile the page on a mid-range mobile, not just their machine.

CLS: whether the page stays still

CLS stands for Cumulative Layout Shift. It measures how much the content jumps around as the page loads. You have lived this: you go to tap a link, an ad or image loads above it, everything shifts down, and you tap the wrong thing.

Google wants CLS under 0.1, which is a small, technical-looking number that simply means "the page should barely move".

What causes it, and what to ask for:

• Images and videos with no reserved space. When media has no defined width and height, the browser does not know how much room to leave, so everything reflows when it arrives. Ask your developer to "set explicit dimensions or aspect ratios on all media".
• Ads and embeds that pop in. Reserve a fixed slot for them so the content around them does not lurch.
• Fonts that swap late. A web font loading after the page renders can reshuffle the text. Ask about "font-display and preloading the main font".

Where this fits in the bigger picture

Core Web Vitals are part of what Google calls page experience, and page experience is one of many signals that feed into how your pages get served in search. It is not a magic lever. A fast, stable page with thin content will not outrank a slightly slower page that genuinely answers the question better. Google's own getting started with Search documentation frames it the same way: Google rewards content that helps people, and speed is one ingredient, not the whole recipe.

The honest version is this. Good Core Web Vitals will not save mediocre content, but bad ones can quietly cost you, especially on mobile, where most people now browse and where Google primarily indexes. A page that loads in five seconds and jumps around loses visitors before your content gets a chance.

How to check yours without being technical

You do not need special tools to get a first read:

• Open your most important pages on your phone, on mobile data, not office wifi. Count the seconds until you can read and tap things. That rough feel is most of what the metrics measure.
• Run a free lab test. Google's PageSpeed Insights gives you LCP, INP and CLS for any public URL, with a colour-coded pass or fail. Paste in your homepage and your top landing page.
• Look at real-world data if you have it. Google Search Console has a Core Web Vitals report based on actual visitors, which matters more than a one-off lab score.

If you want the precise definitions and thresholds in one place, see our Core Web Vitals glossary entry.

What to hand your developer

The whole point of understanding these three metrics is that you can now write a request that gets acted on. Instead of "make the site faster", you can say:

• "Our LCP on the landing page is 4.1 seconds. The hero image is 3MB. Can we compress it and serve WebP?"
• "INP is failing on mobile. Which third-party scripts can we defer or remove?"
• "The blog jumps around as it loads. Can we set dimensions on the images so the layout stops shifting?"

That is the difference between a vague complaint and a ticket someone can close. You do not have to fix Core Web Vitals yourself. You just have to know enough to point at the right thing.