Core Web Vitals Explained for Non-Developers

Someone has probably sent you a report full of coloured bars and acronyms and told you your website has a problem. This explains what those measurements actually mean, in language that does not assume you write code, and what typically causes each one to go wrong.

The useful thing about Core Web Vitals is that they measure experiences you already recognise: waiting for a page to appear, tapping something and nothing happening, and text jumping around as you try to read it.

The short answer

Core Web Vitals are three measurements of how a page feels to use. LCP asks how long until the main content appears — aim for under 2.5 seconds. INP asks how quickly the page responds when you interact — aim for under 200 milliseconds. CLS asks how much the layout jumps while loading — aim for under 0.1. They are measured on real visits, not in a lab.

Largest Contentful Paint: how long until I see something useful?

LCP measures the time until the largest visible element in the initial view has rendered — usually a hero image, a large heading, or a banner. It is the moment a visitor stops looking at a blank screen and starts looking at your page.

Target: under 2.5 seconds.

What typically causes a poor LCP

• A slow server. If the server takes a second to start responding, you have spent a large share of the budget before anything is sent. Cheap shared hosting is a frequent culprit.
• An oversized hero image. The single most common cause. A large photograph at full camera resolution is exactly the element being measured.
• Lazy-loading the hero image. Well intentioned and counterproductive — you are deferring the precise thing the metric measures.
• Render-blocking CSS and fonts. The browser waits for these before painting anything.
• Autoplaying background video. It competes for bandwidth with the content people came for.

What usually fixes it

Better hosting; resizing the hero image and serving it in a modern format; loading it eagerly and with priority; reducing render-blocking resources; and replacing hero video with a lightweight poster image that loads the video afterwards.

Interaction to Next Paint: does the page respond when I touch it?

INP measures how quickly the page visually responds when you interact — tap a button, open a menu, tick a checkbox. It looks at interactions across the whole visit and reports a figure representing the overall responsiveness, so one slow moment does not define the score but a consistently sluggish page does.

This is the metric people feel most viscerally. Tapping a menu and watching nothing happen for half a second is the experience of a website feeling broken.

Target: under 200 milliseconds.

What typically causes a poor INP

• Too much JavaScript. The browser can only do one thing at a time on the main thread. While it is busy running scripts, it cannot respond to your tap.
• Third-party scripts. Chat widgets, heatmaps, tag managers and pixels all run code you did not write and cannot optimise.
• Heavy work on interaction. A filter that re-sorts hundreds of items synchronously will block everything while it runs.
• Expensive animation. Particularly on mid-range phones, which is what most visitors actually use.

What usually fixes it

Shipping less JavaScript; auditing and removing third-party scripts nobody uses; deferring non-essential work; and testing on real mid-range hardware rather than a development machine.

Cumulative Layout Shift: does the page stay still while I read it?

CLS measures how much content moves around unexpectedly while the page loads. It is the metric behind the universal experience of going to tap a link, having an advert load above it, and tapping something else entirely.

It is scored as a ratio rather than in seconds — how much of the screen moved, and how far.

Target: under 0.1.

What typically causes a poor CLS

• Images without dimensions. The browser does not know how much space to reserve, so everything below jumps when the image arrives. The most common cause by a wide margin.
• Adverts, embeds and iframes inserted without reserved space.
• Web fonts swapping in at a different size to the fallback, reflowing the text.
• Banners and notices injected at the top of an already-rendered page.
• Content loaded after render and pushed into the middle of the layout.

What usually fixes it

Setting width and height on every image and embed; reserving space for anything that loads late; choosing fallback fonts with similar metrics; and placing dynamic content where it will not push existing content around.

How the three interact

This is the part that catches people out, because the metrics pull against each other and a fix for one can quietly damage another.

Lazy loading helps CLS but can wreck LCP

Lazy-loading images is good practice and reserves you from downloading things nobody scrolls to. Apply it to the hero image and you have deferred loading the exact element LCP measures. The rule: lazy-load everything below the fold, load the hero eagerly and with priority.

Deferring JavaScript helps INP but can delay rendering

Pushing scripts later frees the main thread and improves responsiveness. Defer something the page needs in order to render its main content, though, and LCP suffers. The distinction is between scripts that produce visible content and scripts that add behaviour afterwards.

Font strategies trade CLS against perceived speed

Hiding text until a custom font loads avoids a visible reflow but leaves the page blank for longer. Showing a fallback immediately gets content on screen faster but causes a shift when the real font swaps in. Choosing a fallback with similar metrics to your web font makes that swap almost invisible, which gets you both.

Aggressive optimisation plugins can make things worse

Plugins that combine, minify and defer everything indiscriminately frequently break layouts or delay critical resources. They can improve a lab score while making the real experience worse. Change one setting, measure, then move on — and always test on staging.

Why the thresholds are measured on real visits

This detail matters more than people expect. These metrics are assessed at the 75th percentile of real user experiences — meaning three quarters of visits must meet the threshold, and the slowest quarter is what determines whether you pass.

It is not about how the site feels on a developer's laptop on fast office Wi-Fi. It is about a mid-range phone on mobile data, which is how a large share of your visitors actually arrive.

Practically: a lab tool giving you a score in a controlled environment is useful for diagnosis, but field data — real measurements from real visitors, visible in Search Console — is what actually counts. A site can score well in a lab test and fail on field data.

What this means for ranking

Worth being precise, because this gets oversold in both directions.

Google's documentation on page experience states plainly that there is no single page-experience ranking signal, and that Search always aims to show the most relevant content even when page experience is sub-par. It also notes that good scores in Search Console or third-party tools do not guarantee that pages will rank at the top.

So: fast pages will not rescue a site that answers nobody's question. What they reliably do is stop you losing people who never waited to find out. If two pages are similarly useful, the one that does not test the visitor's patience has an advantage — and the visitor certainly notices.

The platform does not decide this

This is the part worth internalising if you are choosing technology.

WordPress can be genuinely fast. What makes it slow in practice is accumulation — a plugin each quarter, unoptimised images, no caching. That is a maintenance failure, not a verdict on the platform.

Elementor sites can perform well. Modern Elementor is considerably leaner than its old reputation and can be used to build fast websites when properly developed and optimised. It does not make a site fast on its own, and nobody should tell you it does. How to keep an Elementor website fast is the practical version of that.

Next.js can be slow. A carelessly built React site — shipping far more JavaScript than the page needs, unoptimised images, heavy client-side work — will happily fail all three metrics. The framework gives you a high ceiling, not a guaranteed floor.

Platform, implementation, hosting, optimisation and content all influence performance. Choosing a modern framework buys you potential, not results. If you are weighing platforms, Next.js vs WordPress covers the wider comparison.

How to check your own site

1. Open Search Console and find the Core Web Vitals report. This is field data from real visitors — the authoritative view.
2. Run your most important pages through PageSpeed Insights. Read the field data section at the top, not just the lab score below it.
3. Check mobile separately from desktop. They frequently differ substantially.
4. If you fail something, start with images. On content sites it is the cause more often than everything else combined.

Key takeaways

• LCP is how long until the main content appears — under 2.5 seconds.
• INP is how quickly the page responds to interaction — under 200 milliseconds.
• CLS is how much the layout jumps while loading — under 0.1.
• They are measured on real visits at the 75th percentile, not on your laptop.
• Images are the most common cause of failing LCP and CLS; JavaScript is the most common cause of failing INP.
• No platform guarantees good scores. Implementation and maintenance decide them.

Where to go next

If your site is failing these, the fixes are usually well understood rather than mysterious. The technical SEO checklist puts them in context with the rest of the structural work, and WordPress maintenance covers keeping performance from drifting once it is fixed.

If you would like someone to diagnose it properly, that is what SEO and website performance covers — get in touch and I will tell you what is actually causing it.