Core Web Vitals, explained
LCP, CLS and INP without the jargon: what Google is actually measuring, why it affects your rankings and your bookings, and the handful of things that genuinely move the score.
Core Web Vitals sounds like something only a developer should worry about. It is not. Strip away the acronyms and it is Google writing down three things every visitor already feels about your website: does it show up quickly, does it hold still while it loads, and does it react when I tap. That is the whole idea.
Here is each one, why Google bothers to measure it, and the short list of things that actually change the number.
LCP: how long until the page shows up
LCP stands for Largest Contentful Paint, which is a clumsy way of saying “the moment the main thing on the page finishes loading.” Usually that is your hero image or your headline. It is the point where a visitor stops staring at a blank screen and thinks, right, the page is here.
Google's target is under 2.5 seconds, measured on a real phone. Most of the time a slow LCP comes from a few usual suspects: an enormous unoptimised hero image, a slow server, or a pile of scripts and fonts that have to load before anything can paint. Optimise the images, cut the scripts, and LCP usually falls into line. This is the single vital most worth fixing first, because it is what people mean when they say a site feels slow.
CLS: how much the page jumps around
CLS is Cumulative Layout Shift, which is the technical name for the most annoying thing on the web: you go to tap a button and the page lurches, an image loads above it, and you tap the wrong thing. Every one of those jumps gets added up, and that total is your CLS.
Google wants it under 0.1, which means “the page should barely move once it starts loading.” The fixes are unglamorous but reliable: give images and videos their dimensions so the browser reserves the space, stop ads and embeds from shoving content down the page, and load fonts so they do not cause a visible reflow. Get this right and the page feels solid instead of twitchy.
CLS is the vital most people have never heard of and most sites fail. It rarely shows on a fast laptop, because everything loads before you can interact. Test on a phone on mobile data and you will see the jumps your customers see every day.
INP: how quickly it responds
INP is Interaction to Next Paint, and it measures the lag between you doing something, tapping a menu, opening an FAQ, hitting submit, and the page actually responding. A low INP feels instant. A high one feels like the site is thinking about whether it can be bothered.
Google's target is under 200 milliseconds. High INP is almost always a JavaScript problem: the browser is busy running scripts and cannot get to your tap. This is exactly where a heavy platform hurts, because every plugin and page builder adds more script for the browser to chew through. Ship less JavaScript and INP takes care of itself, which is a big part of why a static-first build scores well here almost for free.
Why Google measures any of this
Because it correlates with whether people stay. Google's whole business depends on sending searchers to pages they will not immediately bounce off, and slow, jumpy, unresponsive pages get abandoned. So the vitals are a ranking input: not the biggest one, content and relevance still lead, but a real one, and a genuine tie-breaker between two otherwise equal pages.
The part most people miss is that the vitals pay off even if you ignore rankings entirely. A page that loads fast and holds still converts better, because visitors reach your call to action instead of leaving before it appears. Same traffic, more work booked. That is the real return behind our website performance work, and the deeper reason a slow platform costs you covered in why your site is slow, and the fix.
How to check yours in two minutes
Run your homepage through Google PageSpeed Insights. It is free and it gives you two readings: lab data, a controlled test, and field data, what real visitors actually got over the past month. The field data is the one Google uses, so that is the number to trust. Then do the same on a phone, on mobile data, and see whether the lived experience matches the score.
If you want the honest test, run this very page through it. We build every Igloo site to pass all three vitals by default rather than rescue them later, so the result is the argument. If your own site comes back poor and you cannot see how to fix it, that is usually the platform talking, and it is worth reading what a rebuild actually costs in how much a website costs in NZ.
People also ask
What are Core Web Vitals?
They are three things Google measures about how your page feels to a real person. LCP is how long until the main content shows up. CLS is how much the page jumps around while it loads. INP is how quickly it responds when someone taps or clicks. Fast to appear, steady while it loads, quick to react.
Do Core Web Vitals actually affect Google rankings?
Yes, but keep it in proportion. They are a real ranking input, not the ranking input. Content and relevance still decide most of it. Where the vitals matter is as a tie-breaker between similar pages, and as a conversion input in their own right: people leave slow, jumpy pages before they read a word, so a good score quietly lifts both rankings and bookings from the same traffic.
What counts as a good Core Web Vitals score?
Google publishes the thresholds. LCP under 2.5 seconds, CLS under 0.1, and INP under 200 milliseconds, all measured on real visitors using mobile. Hit all three and you pass. The catch is that the score is based on field data from real phones, so it reflects how your actual customers experience the page, not a lab test on fast hardware.
How do I test my own Core Web Vitals?
Run your page through Google PageSpeed Insights or the Lighthouse tab in Chrome, both free. PageSpeed shows two things: lab data (a controlled test) and field data (what real visitors got over the last month). The field data is the one Google uses for ranking, so that is the number that matters. You can test this very page the same way.
Why is my mobile score so much worse than desktop?
Because phones are slower and mobile networks are worse, and Google grades on mobile. A desktop on office wifi hides a lot of weight that a mid-range phone on mobile data exposes. If you only ever check the site on your laptop, you are seeing the easy version. Always judge it on a phone.
Can Core Web Vitals be fixed without rebuilding the site?
Often, yes. A lot of poor scores come from a handful of fixable culprits: huge unoptimised images, heavy JavaScript, slow-loading fonts, and ads or embeds that shift the layout. Fix those and the score moves. It is only when the platform itself is the ceiling, plugin bloat you cannot remove or a page builder you cannot escape, that a rebuild becomes the honest answer.
Want this handled, not homework?
This is the same thinking we bring to a build. Tell us what you are up against and we will point you, plainly, at the move that matters first.