Most business owners ask the wrong question about their website's performance. They're not thinking about how fast their site is, or whether Search Console shows a green checkmark. The real question is whether they're losing visitors and revenue before the page even finishes loading, and whose job it is to make sure that doesn't happen.
Core Web Vitals isn't a technical exam for Google. It's a business metric with consequences you can measure in real money. A slow page doesn't hurt Google, it hurts the business.
A client rarely writes to us because they've been studying their Core Web Vitals report. They write because they've seen problems flagged in Search Console and have no idea how serious it is, whose fault it is, or what it will cost to fix. In that moment, the worst thing a digital partner can do is answer with technical jargon. The right answer starts by explaining what these three numbers actually measure, and why they matter not just to Google but to the client's revenue.
Before diving into any report, it's worth trying this on yourself. Open your own product or service page on your phone, on mobile data, on an average device. Scroll down, then tap a button. The half-second stall after the tap, the button that jumps out from under your finger, the image that jerks into place — that's exactly what Google measures, and exactly what your visitor experiences right before they move on to a competitor.
These three metrics aren't abstract technical data. They're a translation of real user impatience into a number.
One thing is worth keeping in mind: a tool can measure the problem, but deciding which problem is worth fixing is a human call. That decision is the difference between a green checkmark and a page that actually converts better.
What Core Web Vitals actually is
Core Web Vitals consists of three metrics. All three measure what a real visitor actually experiences in their own browser, not what a lab test would show under ideal conditions.
- LCP (Largest Contentful Paint): how long it takes for the page's largest, most visually dominant element to appear, typically a hero image or a headline. Good: under 2.5 seconds.
- INP (Interaction to Next Paint): how long it takes between a click, tap, or keystroke and the visible response. Good: under 200 milliseconds.
- CLS (Cumulative Layout Shift): how much elements jump around while the page loads, in other words, visual stability. Good: under 0.1.
INP replaced the older First Input Delay metric in March 2024. FID only looked at the delay of the very first interaction. INP, on the other hand, tracks every interaction on the page, which gives a much stricter and more realistic picture of how smooth the experience actually feels to a visitor.
What most clients get wrong about the measurement
The most common misunderstanding is that a client runs a speed test on their own machine, gets a good result, and can't understand why Search Console still flags a problem.
The explanation is simple, it's just rarely spelled out. Core Web Vitals isn't a lab measurement, it's real user data that Google collects from visitors using Chrome, aggregated over a rolling 28-day window. A page counts as passing a given metric only if at least 75% of visits fall into the good range. So a single quick test says nothing about real-world performance, only the aggregated experience of many visitors counts.
The other common misunderstanding is that a client applies the result to the entire website, while Google actually evaluates at the URL level. The homepage might be excellent while the product pages perform poorly, and that gap easily gets lost if someone only looks at one overall number.
Why this isn't just an SEO question
This is where a technical report turns into a business question. Fortunately we don't have to take our own word for it, the numbers speak for themselves.
Core Web Vitals is officially a ranking factor, but in practice it rarely decides a position on its own. It tends to tip the scale when two similarly relevant pages are competing for the same spot in the results. The real stakes are far more tangible than that, and we don't have to stay theoretical, because Google itself has published documented case studies of what happens when a company actually improves these metrics.
Vodafone Italy ran an A/B test comparing two landing pages that were visually and functionally identical, where the only difference was LCP. The version with 31% better LCP drove 8% more sales, a 15% better lead-to-visit rate, and an 11% better cart-add rate, purely from the speed improvement.
Indonesia's Tokopedia improved its LCP by 55% by preloading loading elements and optimizing images. As a result, average session length grew by 23%.
French retailer Cdiscount improved all three metrics, which led to a 6% revenue increase during their Black Friday sale.
Commissioned by Google, Deloitte analyzed more than 30 million mobile sessions across 37 European and American brands in the Milliseconds Make Millions study. Just a 0.1-second speedup increased retail conversion by 8.4% and average cart value by 9.2%, and on travel sites, conversion by 10.1%. A tenth of a second, an amount you wouldn't consciously notice.
These numbers matter to a client because they translate a technical report into business language. A slow, jittery page isn't bad because Google says so. It's bad because the visitor leaves before it loads, or accidentally taps the wrong button when the page shifts under their finger.
A 100 score on PageSpeed isn't a business goal. A converting visitor is.
INP, the metric that's hardest to fix
If there's one thing a client needs to understand about these three metrics, it's that they're not equally hard to fix.
LCP and CLS can typically be improved with well-established technical steps: preloading images, inlining critical CSS, preloading fonts, or giving images and videos explicit dimensions so content doesn't shift around them. Fixing INP, by contrast, requires rethinking the JavaScript architecture at a fundamental level, how the developer breaks up long operations that block the browser's main thread into smaller, interruptible chunks. That's a far more time-consuming and expensive task than compressing an image or setting up a cache. If a client asks why INP can't be fixed in a week, this is the distinction worth pointing to.
An everyday example makes this easy to grasp. A visitor taps the cart button or a filter on mobile, and the page doesn't respond for a moment. To them it's just a brief flicker of doubt, but often that's enough to make them close the page, thinking something got stuck. That's the moment INP measures.
One clarification worth making, because it's easy to misread: INP is the most expensive to fix, but statistically it's not what trips up most sites. Web Almanac data shows 77% INP pass rates and 81% CLS pass rates on mobile, but only 62% for LCP. So most sites fail on loading, not on responsiveness. If someone starts by proposing a JavaScript rewrite for you, it's worth asking what makes them think INP is actually the bottleneck.
And that's exactly what makes 2026 a turning point. INP has been a live metric since March 2024, but plenty of sites are still running on the JavaScript architecture they built back in the more forgiving First Input Delay era. That's where the bill is coming due now, and it won't be settled by compressing an image, but by heavier development work. Whoever doesn't look at it this year will pay more for it next year.
And in 2026 the yardstick itself is shifting too. The Chrome team is turning on so-called soft navigation measurement by default from Chrome 151. Until now, on a React- or Vue-based site where a click doesn't reload the entire page, Google effectively only measured the very first load, the in-between steps, where the visitor actually makes decisions, fell out of the picture. From now on, those become measurable too. Exactly how this will show up in Google's dataset hasn't even been announced by the Chrome team yet. But the direction is clear: fewer and fewer parts of your website will remain unmeasured.
Which tools measure what, and what each one actually shows
Clients often mix up the different tools, even though they measure completely different things.
The Lighthouse and PageSpeed Insights Diagnostics tab give you lab data, the result of a single simulated load under a given network and device condition. It helps you understand what's causing a problem, but it's not what Google bases its ranking decision on. The Search Console Core Web Vitals report and the Chrome UX Report (CrUX), on the other hand, show real user data, and that's what the ranking evaluation is based on. If a page doesn't have enough real visitor data, Google falls back to a URL group or even domain-level data, which is why a brand-new page might show up differently in the report at first than it does a few months later.
In practice, this means a development team diagnoses and iterates using PageSpeed Insights, but the real confirmation only shows up in Search Console a few weeks after the fix, because the 28-day rolling window has to absorb the new data first.
What most commonly causes the problem on WordPress sites
On WordPress sites, performance problems almost never come from the framework itself. A handful of recurring causes tend to be behind it:
- An unoptimized featured image — uploaded without compression or the right format (e.g. WebP or AVIF), which alone drags down LCP.
- An overloaded plugin list — every additional plugin loads its own CSS and JavaScript, often even on pages where it isn't needed at all.
- An accumulation of third-party scripts — chat widgets, ad pixels, and analytics tools each seem harmless on their own, but together they put real strain on INP.
- Carelessly configured visual page builders — prone to generating unnecessarily deep, nested elements, which hurts both load speed and visual stability.
An expensive, well-known theme or page builder guarantees nothing on its own. Most performance problems come from the plugins, scripts, and unoptimized media piled on top, not from the framework itself.
The green checkmark you can buy
There's one type of offer worth being wary of: guaranteed green Core Web Vitals. It's the same false promise as the old "guaranteed number one spot on Google," just dressed up in more technical language. Core Web Vitals is calculated from real visitor data, which neither you nor your service provider produces, your visitors do, on their own phones, on their own mobile connections. Nobody can guarantee that.
In practice, this usually means someone fixes the lab score, not reality. An optimization plugin goes in, PageSpeed Insights climbs above 90, the report looks great, and a month later Search Console flags exactly the same thing it did before, because the visitors' actual experience never changed.
The other recurring pitch is a platform switch: replace WordPress because it's slow. There's a grain of truth in it. Based on the Core Web Vitals Technology Report, which draws on Google's own data, Search Engine Journal found that roughly 44% of WordPress sites pass all three metrics, compared to around 85% for closed, centrally maintained platforms. But that doesn't mean WordPress is slow. It means WordPress leaves the decision up to you, and if nobody makes that decision, the result will be average. The platform sets the floor, not the ceiling: a disciplined, well-built WordPress site is easily green, and a closed platform loaded up with scripts can easily fail.
For a Hungarian SME, this distinction matters a lot, because switching platforms typically costs several times more than fixing up the existing site. So anyone who responds to a Search Console report by immediately proposing a new website isn't solving the problem. They're selling a bigger invoice.
When not to start, and why we say this too
Let's be honest: it's not worth diving in on every site, and hardly anyone tells a client that.
If a site sees only a few hundred visitors a month, the Search Console warning is real, but it isn't the most expensive problem, traffic and the offer itself come first, not half a second. If the real issue is that the visitor doesn't understand what the page offers, or doesn't trust it, a faster page will just lose them faster. And if fixing INP would require rewriting the entire JavaScript architecture on a site that's getting replaced within six months anyway, that money is better spent on the new system, not patching up the old one.
In cases like that, we say: don't worry about this right now. A vendor sells you the package you asked for. A partner sometimes talks you out of it, because what's at stake is the client's business outcome, not the billable hour.
Often the real question isn't what to optimize, but whether the current technical setup even supports search in general, and modern, AI-based search engines in particular. A page can be fast and still invisible if its structure isn't understandable to people or to machines. This is exactly where an AI Visibility assessment is worth more than another speed optimization package, because it shows where the site actually stands before we commit to anything.
And this is where the two layers meet at the same point. According to server-log analysis from Vercel and MERJ, the major AI crawlers, GPTBot, ClaudeBot, PerplexityBot, do download JavaScript files, but they don't execute them. They only see what's already in the HTML sent by the server. So the same heavy, client-side JavaScript layer that's hurting your INP is often also hiding your content from AI systems. Not two separate projects: one technical decision, two consequences.
What we actually need to tell the client
When a client comes to us with a Core Web Vitals problem, there are three things we always clarify before getting into any technical detail:
A problem doesn't necessarily mean someone made a mistake. A website's performance keeps changing, every new blog post image, every new third-party script, every new feature affects it. Core Web Vitals isn't a one-time task, it's a question of ongoing maintenance.
There's always a concrete, identifiable cause behind the number, and that cause can differ from URL to URL. So the first step is never guessing, it's measuring, without it a team can easily start fixing things that aren't even the problem actually hurting real traffic.
The fix is almost never a single big project, it's the result of many small, incremental decisions building on each other. On a well-maintained site, this takes ongoing attention, not a six-month overhaul.
The tool measures the problem. Which one is worth solving is always a call the business goal makes.
Common misconceptions worth clearing up
One widespread misconception is that fixing it once means you're done. Core Web Vitals is a dynamic metric, adding a new marketing tool, a new banner, or even an ad pixel can drag the result back down, which is why ongoing monitoring matters just as much as the initial fix.
The other misconception is that mobile and desktop performance are the same. Google typically measures the mobile experience more strictly, and since most of a website's traffic comes from mobile, that's the view worth fixing first.
The W5labs approach
For us, Core Web Vitals never comes up as a standalone technical task, it's part of the development process from the start of every project. When we find a performance problem on a client's website, the first step is always measurement and identifying the specific causes, not slapping on a generic optimization package. Two equally poorly performing pages can have entirely different causes behind them, and the fix will differ accordingly.
A fast page isn't a competitive advantage on its own, but a slow page is a clear competitive disadvantage. Core Web Vitals is just one layer. A fast page without a clear business strategy, good content, and a technical structure that both people and AI search engines can understand is still just a silent, fast page. Speed, content, communication, discoverability, and AI visibility are all layers of the same system. We're not patching one metric, we're looking at whether the whole system serves business growth.
W5labs designs and builds the digital systems businesses grow on. Strategy plans the system, Creative shapes its communication, Development builds it, and Support keeps it running and protects it, because Core Web Vitals isn't a one-time fix, it's ongoing attention. Together, this is the digital infrastructure that carries a client from strategy through to growth.
A tool can still measure the problem, but deciding which problem is worth fixing, what's fine to leave as is, and when page speed isn't the issue at all, that's a human decision. Behind every one of those decisions at our company stands a specialist who puts their name on it.
If you're curious, we'll walk through together how well your current website, content, and digital presence support business growth, and how visible all of that is to modern, AI-based search engines. We don't just build faster pages, we build digital growth systems that deliver a lasting competitive advantage.
