Google measures how your website feels to use — how fast it loads, whether the content jumps around, and how quickly it responds when someone clicks. Those measurements have names, and they influence where you rank.
You do not need to be a developer to understand Core Web Vitals. Each of the three metrics describes an everyday frustration you have felt on other people's websites: waiting for a page to show anything useful, tapping the wrong button because an advert shoved everything down, or clicking something and wondering whether the site noticed. This guide explains what each metric measures, what counts as a good score, and what typically drags scores down.
What are Core Web Vitals?
Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: Largest Contentful Paint (loading speed), Cumulative Layout Shift (visual stability) and Interaction to Next Paint (responsiveness). Each one captures a familiar frustration — a page that takes ages to show its content, content that jumps around while loading, or a button that ignores your tap. Google collects these measurements from real Chrome users and uses them as part of how it ranks pages.
LCP — the wait before the page feels loaded
Largest Contentful Paint measures how long it takes for the largest visible element — usually a hero image or the main headline — to appear on screen. It is a good proxy for the moment a visitor thinks "right, it's here". A page can technically be responding long before that, but until the main content renders, the visitor is staring at a blank or half-built screen and deciding whether to wait.
CLS — content that jumps around
Cumulative Layout Shift measures how much the page moves without the visitor doing anything. The classic case: you go to tap a link, an image or banner finishes loading above it, everything shifts, and you tap something else entirely — sometimes an advert, sometimes "buy now". CLS adds up every unexpected shift during the visit; a low score means the page stays where it first appeared.
INP — the lag after you act
Interaction to Next Paint measures how long the page takes to visibly respond after a click, tap or key press. When a visitor presses "Add to basket" and nothing changes for a second, they press it again, or assume the site is broken. INP looks at interactions across the whole visit, so a page that starts snappy but bogs down as scripts pile up still gets caught.
What is a good Core Web Vitals score?
Google's published thresholds for a good experience are an LCP of 2.5 seconds or less, a CLS of 0.1 or less, and an INP of 200 milliseconds or less. To count as passing, a page should meet these thresholds for at least 75% of visits. Results between the good and poor thresholds fall into a needs-improvement band.
The 75% detail matters more than it looks. Your page might load quickly on your office connection and your new laptop, and still fail for the many visitors on older phones and mobile networks. The thresholds are judged against real-world visits, not against the best-case test in your own browser.
Do Core Web Vitals affect Google rankings?
Yes. Core Web Vitals are part of Google's page experience signals, which contribute to how pages rank in search results. They are one factor among many — relevant, useful content still matters more — but when two pages compete on similar content, the one that loads faster and behaves more predictably has the advantage. And regardless of ranking, slow or unstable pages lose visitors on their own.
That last point is worth sitting with. Even if the ranking effect were zero, a visitor who waits too long, mis-taps because the layout shifted, or gives up on an unresponsive checkout is a lost enquiry or a lost sale. Core Web Vitals are useful precisely because they measure the experience your customers actually have, not an abstract technical property.
What causes a poor Core Web Vitals score?
The usual culprits are heavy, unoptimised images, scripts that block the page from rendering, and elements that load late and push other content around. Most of these are fixable without redesigning the site: compressing images, deferring non-essential scripts and reserving space for banners and embeds go a long way.
- Heavy images hurt LCP. A photograph uploaded straight from a camera can be many times larger than it needs to be for the space it occupies. Compressing images, serving modern formats and sizing them for their actual display size is usually the single biggest LCP win.
- Render-blocking scripts hurt LCP and INP. Every script and stylesheet the browser must download and run before painting the page delays the content. Third-party tags — chat widgets, analytics, marketing pixels — accumulate quietly over the years, and each one adds weight.
- Late-loading elements hurt CLS. Images without declared dimensions, cookie banners injected at the top of the page, embeds and adverts that claim their space only after arriving — all of them shove the content around. Reserving space in advance fixes most of it.
- Heavy JavaScript hurts INP. When the browser's main thread is busy running scripts, it cannot respond to the visitor's tap. Trimming and deferring script work keeps the page responsive.
Keeping an eye on them without becoming a specialist
Core Web Vitals drift. A new marketing tag, a redesigned banner or one oversized campaign image can push a passing page into the poor band without anyone noticing, because the people adding those things are rarely the people measuring performance. The practical answer is to measure continuously rather than once.
SiteControl measures LCP, CLS and INP on every crawl of your site, alongside page weight and render-blocking resources, and tracks the trend over time. Every finding comes with a plain-language explanation and concrete fix steps — in a Simple view for owners and a Technical view for whoever does the fixing. Performance sits next to the rest of your site quality on the same crawl: security headers and cookie consent behaviour are checked from the same platform, so one scan gives you the whole picture.