Insights · Engineering · Nov 1, 2024 · 7 min read
Core Web Vitals in plain language: LCP, INP and CLS for business owners
LCP, INP and CLS describe things every visitor feels: how fast your page appears, how quickly it responds and whether it jumps around. Here is what each means, why Google cares and what fixing a poor score involves.
Core Web Vitals are three measurements Google takes from real visits to your website: how quickly the main content appears (Largest Contentful Paint, or LCP), how fast the page responds when someone clicks or taps (Interaction to Next Paint, or INP), and how much the layout shifts around while loading (Cumulative Layout Shift, or CLS). They matter because Google uses them as a ranking signal, and because they describe the experience your customers actually have on your site. Most poor scores trace back to a short list of fixable causes, and a good developer can usually diagnose them in an afternoon.
Key takeaways
- LCP measures how long the main content takes to appear, INP measures how quickly the page reacts to a click or tap, and CLS measures how much the layout jumps around.
- Google grades your site on data from real visitors collected over a rolling 28-day window, not on a one-off test from your office Wi-Fi.
- The usual culprits are oversized images, heavy third-party scripts, slow server responses and layouts that load without reserved space.
- Fixing vitals is ordinary, well-understood web development work on images, scripts, templates and hosting, not a dark art.
- Improvements take roughly a month to show fully in Google's reports, so treat vitals as ongoing hygiene rather than a one-time project.
What do LCP, INP and CLS actually measure?
Each metric captures one moment in a visit where a slow or clumsy site loses people. Together they answer three questions every visitor silently asks: can I see it, can I use it, and can I trust it to hold still?
LCP: how long until the page looks loaded
Largest Contentful Paint is the time from clicking a link to the moment the biggest visible element, usually a hero image or a headline, finishes rendering. It is a proxy for the feeling of "the page is here." A visitor staring at a blank screen does not care that your analytics script loaded quickly; they care that the thing they came to see has not appeared yet.
INP: how quickly the page responds when someone acts
Interaction to Next Paint measures the delay between an action, such as tapping a menu, clicking "add to cart" or typing in a field, and the screen visibly responding. It replaced the older First Input Delay metric in 2024 and is stricter, because it looks at interactions across the whole visit rather than just the first one. A page with poor INP feels broken even when it eventually does the right thing: buttons seem dead, menus lag, and people tap twice and end up somewhere they did not intend.
CLS: how much the page jumps around
Cumulative Layout Shift scores visual stability. Every time content moves after it first appears, the shift is added to the score: an ad loads and shoves the article down, a font swaps and reflows the text, an image pops in above the button you were about to press. High CLS is the metric behind the familiar frustration of tapping "accept" and hitting an ad instead.
Why does Google care about three numbers?
Google's business depends on people trusting search results to lead somewhere useful. Sending a searcher to a page that takes ages to appear, ignores their taps and rearranges itself under their thumb damages that trust, so Google folded these measurements into its page experience signals. Vitals are not the main ranking event: relevant, well-written content still comes first. But between two otherwise comparable pages, the one that loads fast and holds still has the edge.
The more practical reason to care is that the metrics describe your customers' patience. The same slow load that hurts your ranking is quietly costing you enquiries and abandoned carts every day, whether or not Google is watching. That is why we treat vitals work as conversion work as much as engineering work, and why it sits naturally alongside analytics and conversion rate optimisation.
A fast, stable site is not a technical vanity project. It is the difference between a visitor who stays and one who quietly gives up.
Where do the scores actually come from?
This is the part that confuses most business owners. There are two kinds of data, and they often disagree.
Field data is collected from real Chrome users visiting your site, aggregated over a rolling 28-day window in the Chrome User Experience Report. This is what Google judges you on, and it is what appears in Search Console's Core Web Vitals report. Google's published targets, current at the time of writing, are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, each measured at the 75th percentile of visits, meaning roughly three quarters of your visitors need to have a good experience, not just the average one.
Lab data comes from tools like Lighthouse and PageSpeed Insights running a simulated visit on a throttled connection. It is useful for diagnosis, because it produces a repeatable test you can run before and after a fix. But it is not what you are ranked on, and a lab score of 60 with healthy field data is a far better position than the reverse.
If you check nothing else, open Search Console and look at the Core Web Vitals report. It tells you, in Google's own accounting, which pages pass and which fail on real visits.
What usually causes bad scores?
In our experience the causes are unglamorous and repeat from site to site. Oversized images shipped at full camera resolution. Dozens of marketing and tracking scripts added over the years and never removed. Cheap shared hosting that takes a second to even begin responding. Themes and page builders that load everything on every page. Ads, banners and embeds that arrive late and push content around. Very little of it is exotic.
| Metric | What the visitor feels | Typical causes | Where the fix usually lives |
|---|---|---|---|
| LCP | Staring at a blank or half-empty page | Huge images, slow server response, render-blocking scripts and stylesheets | Image pipeline, hosting and caching, template cleanup |
| INP | Buttons and menus that feel dead or laggy | Heavy JavaScript, too many third-party tags, long tasks blocking the browser | Script audit and removal, code splitting, deferring non-essential work |
| CLS | Content jumping as it loads, mis-taps | Images and ads without reserved space, late-loading banners, font swaps | Layout rules in the theme or template, font loading strategy |
One pattern deserves special mention: third-party scripts. Every chat widget, heat-mapping tool, ad pixel and pop-up plugin is code your visitors download and run. Individually each seems harmless; collectively they are the most common reason we see for poor INP. The fastest performance win on many sites is simply an honest inventory of which of these tools still earns its keep.
What does fixing them involve?
Vitals work follows a predictable arc. First, diagnosis: separating field data from lab data, identifying which template types fail (product pages behave differently from blog posts), and tracing each failing metric to specific causes. Second, the fixes themselves, roughly in order of typical effort:
- Images. Serve modern formats, size them to the space they occupy, compress them properly and lazy-load anything below the fold. Often the single biggest LCP win.
- Hosting and caching. Move to hosting that responds quickly, add a content delivery network and cache pages so repeat work is not redone for every visitor.
- Script hygiene. Remove tags nobody uses, load the rest after the page is interactive, and consolidate overlapping tools.
- Layout stability. Reserve space for images, embeds and ads before they load, and tune how fonts swap in so text does not reflow.
- Deeper rebuilds. When a theme or page builder is the bottleneck, the honest answer is sometimes rebuilding key templates: heavier work, but it fixes the cause rather than the symptoms.
None of this requires exotic skills, but it does require care: performance fixes touch live templates, and a clumsy change can break layouts or tracking. It is bread-and-butter work for a disciplined web development team, and it should always end with measurement, not just a deployment.
What results can you realistically expect?
Be wary of anyone promising a specific ranking jump from vitals work. Realistic expectations look like this: pages move from "failing" to "passing" in Search Console; bounce rates on slow templates improve; mobile visitors on mid-range phones and patchy connections, often the majority, get a noticeably better experience; and your content competes on its merits instead of being handicapped by its container. Because field data accumulates over a 28-day window, the official numbers catch up roughly a month after fixes ship.
Expect maintenance, too. Every new plugin, tracking tag and campaign landing page can reintroduce weight, so the sites that stay fast are the ones where performance is checked as part of routine publishing, not rediscovered in a panic every couple of years.
How OlDevs can help
OlDevs has been building and repairing websites from Vancouver since 2014, and Core Web Vitals work sits squarely in what we do every week: diagnosing failing pages, fixing images, scripts, templates and hosting, and verifying the results in real field data rather than a screenshot of a lab score. One accountable team handles the engineering and the measurement, you see a working demo every week, and you own all the code and accounts when we are done. If your Search Console report is showing red, or your site simply feels slow and you want a plain-spoken assessment of why, request a quote and we will reply within one business day.
FAQ
Questions on this topic.
Yes, they are part of Google's page experience signals, but they act more like a tiebreaker than the main event. Strong, relevant content still comes first. Where you and a competitor are otherwise well matched, better vitals can favour your page, and a slow, unstable page can hold otherwise good content back.
Google's published targets, current at the time of writing, are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, each measured at the 75th percentile of real visits. In plain terms, roughly three quarters of your visitors should see, use and read the page without waiting or watching it shift.
It depends on the cause. Image and caching fixes can ship within days, while script cleanups and template changes usually take a few weeks of focused work. Because Google reports field data over a rolling 28-day window, expect about a month after the fixes ship before the official numbers fully reflect them.
Keep reading
More from the studio.
Web security and privacy in 2026: what changed and what to do now
Passwords gave way to passkeys, privacy law arrived in force, accessibility got deadlines and AI added new risks. What changed through 2026 and the checklist to…
Performance marketing that proves itself: attribution basics for non-marketers
Attribution decides which marketing gets credit for a sale. No model is perfect; the aim is a fair, consistent method that shows where budget actually works.
What an AI copilot actually costs to run in production — and how to keep it reliable
Model fees are the smaller share of a copilot's running cost. Tokens, latency, monitoring and guardrails are the larger one, and they decide whether it stays…
Let’s connect
Want this applied to your business?
Tell us what you’re building. We’ll reply within one business day with next steps and a tailored quote.