A site can load in three seconds, look polished, and still fail Core Web Vitals. This surprises people, because “fast” and “passing” are not the same thing to Google. Core Web Vitals are three specific, field-measured metrics, and a page fails the moment any one of them slips into the wrong band, no matter how fast the other two are or how good the site looks on your own screen.
This guide explains what each metric actually measures, the current official thresholds, and, honestly, which of the three your hosting can genuinely influence and which ones live almost entirely outside its reach. That last part matters, because most hosting content overstates its own effect on all three, and that is not accurate.
📖 The server-side half of the picture
One of the three vitals depends heavily on how fast your server answers. Read What Is Time to First Byte (TTFB) and Why It Matters, on the metric that sits underneath everything that follows.
What Core Web Vitals Actually Measure
Core Web Vitals are three metrics Google uses to score real-world page experience, and the word “real-world” is doing real work in that sentence. They are not measured in a lab or on your development machine. According to Google’s own web.dev documentation, the current thresholds for a “good” score are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift at or below 0.1.
Each metric covers a different dimension of experience. LCP measures loading, how long until the largest visible piece of content appears. INP measures responsiveness, how quickly the page reacts when someone clicks, taps, or types. CLS measures visual stability, whether elements jump around unexpectedly while the page settles.
Google scores these at the 75th percentile of actual visits collected through Chrome’s User Experience Report, not the average and not your best case. A page passes a metric only when three out of every four real visits meet the good threshold, which means a site that feels fast on your own fibre connection can still fail if a meaningful share of real visitors are on slower networks or devices. For the ranking signal specifically, Google uses the mobile measurement of these three metrics rather than the desktop one, a consequence of mobile-first indexing.
Largest Contentful Paint: Where Hosting Genuinely Matters
LCP measures the time from navigation start until the largest content element, usually a hero image or a block of text, finishes rendering on screen. It is the metric most directly tied to how fast a page feels to load.
This is also the one metric where hosting has a real, measurable effect, and the mechanism is straightforward. Before any content can render, the browser has to receive the first byte of the response from the server, the metric known as TTFB. LCP inherits that time completely, because nothing else on the page can start until the server has answered. A server that takes 900 milliseconds to respond has already spent more than a third of the entire 2.5 second LCP budget before a single pixel has painted, leaving everything else, image download, rendering, layout, to fight over what remains.
This is precisely why infrastructure choice shows up here more than anywhere else in the Core Web Vitals picture. A dedicated server with no shared tenancy delivers consistent, low TTFB, while a slow or oversubscribed shared host can eat the LCP budget before the front end even gets a chance.
Interaction to Next Paint: Why Hosting Helps Only Indirectly
INP measures how long the page takes to visually respond after a user interacts with it, and it replaced an older metric, First Input Delay, because it captures the full interaction rather than just its start.
Here the honest picture changes considerably. JavaScript running on the browser’s main thread dominates INP, not anything happening on the server. A long, blocking script that runs after a click delays the next paint regardless of how fast the server delivered the page in the first place. A fast server helps only indirectly, by getting the page’s scripts to the browser sooner and not adding its own delay on top of an already heavy script. It cannot fix a script that blocks the main thread for half a second once it starts running.
The practical consequence is that fixing INP usually means changing the codebase, breaking up long tasks and deferring non-critical JavaScript, not changing where you host the site. Good hosting removes one possible source of delay. It does not touch the rest.
📖 The mobile side of this picture
Field data is measured across real devices, and mobile often tells a different story. Read Website Speed: Mobile Is Slower Than Desktop, on why the gap appears and what narrows it.
Cumulative Layout Shift: The One Hosting Barely Touches
CLS measures unexpected movement of visible elements while a page loads or while someone is reading it, the jarring jump when an image finally loads and pushes the text you were reading down the screen.
Of the three vitals, this is the one furthest from anything a server controls. CLS is almost entirely a front-end concern. Images and embeds without reserved width and height cause it, along with fonts that swap in and reflow text, and content, banners, or ads that appear after the initial layout has already settled. None of these have anything to do with how fast or slow the underlying server is.
Being honest about this matters, because it would be easy to imply that better hosting improves all three vitals. It does not. A dedicated server can deliver the fastest possible TTFB and still sit behind a page with a poor CLS score, because the cause lives entirely in the markup and the CSS, not in the infrastructure underneath it.
How much hosting actually influences each metric
| Metric | Good threshold | Hosting’s influence |
|---|---|---|
| LCP | Under 2.5s | High, via TTFB |
| INP | Under 200ms | Indirect only |
| CLS | At or below 0.1 | Minimal to none |
Thresholds per Google’s official web.dev documentation. Influence reflects the technical mechanism behind each metric, not a claim about any specific hosting provider.
Table showing three Core Web Vitals metrics. LCP under 2.5 seconds, hosting has high influence via TTFB. INP under 200 milliseconds, hosting helps only indirectly. CLS at or below 0.1, hosting has minimal to no influence.
Why This Is Not Just an SEO Metric
It is tempting to file Core Web Vitals under technical SEO housekeeping and move on, but the business evidence behind them is concrete, not theoretical.
In a controlled A/B test documented by Google’s own case study, Vodafone tested two otherwise identical landing pages, one with a 31 percent better LCP score than the other. The version with the faster LCP produced 8 percent more sales, a 15 percent improvement in the rate visitors became leads, and an 11 percent improvement in the rate visitors reached the cart. This was not a correlation pulled from aggregate industry data. It was a direct, isolated test of one variable, LCP, against real purchasing behaviour.
The result is a useful reminder that Core Web Vitals scores are not an abstract ranking checkbox. They signal whether real visitors stay, engage, and convert, and the Vodafone test shows that the effect shows up in actual revenue, not just in a Search Console report.
A server that does not eat your LCP budget
Swify dedicated servers deliver consistent, low TTFB from a Netherlands data centre, with no shared tenancy competing for resources. Full root access, enterprise SSD and NVMe storage, and 1Gbps unmetered bandwidth. From €120/month.
→ Explore Swify Dedicated ServersFrequently Asked Questions
What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. They are measured from actual Chrome user data at the 75th percentile, not from lab tests, so a page passes only when most real visits meet the good threshold for all three.
Google introduced these as part of its page experience signals, and they now function as one input among several ranking factors. Read What Is Time to First Byte (TTFB) and Why It Matters for the metric underlying the one vital hosting influences most.
What is a good LCP score?
According to Google’s official documentation, a good LCP score is under 2.5 seconds, measured at the 75th percentile of real visits. LCP measures how long it takes for the largest visible content element to render, and it is heavily influenced by server response time, since nothing on the page can begin rendering until the server has answered the initial request.
This is why hosting choice affects LCP more directly than the other two Core Web Vitals. Read Website Speed: Mobile Is Slower Than Desktop for how this plays out differently across devices.
Does a faster server improve INP?
Only indirectly. INP is dominated by JavaScript execution on the browser’s main thread after a user interacts with the page, not by server response time. A faster server helps by delivering scripts sooner and not adding its own delay, but it cannot fix a long-running script that blocks the main thread once it starts executing in the browser.
Most INP problems are solved by breaking up long JavaScript tasks, not by changing hosting infrastructure. Read What Is Time to First Byte (TTFB) and Why It Matters for the part of the pipeline hosting does control directly.
Does hosting affect Cumulative Layout Shift?
Barely, if at all. CLS is caused by unexpected movement of visible elements, typically from images or embeds loaded without reserved dimensions, fonts that reflow text on swap, or content injected after the layout has settled. All of these live in the front-end code and design decisions, not in server infrastructure, so even the fastest possible hosting does not fix a poor CLS score on its own.
Fixing CLS is a front-end task: reserve space for every image and embed before it loads. Read How to Setup a Dedicated Server for the infrastructure side of a new site once the front end is handled.
How is Core Web Vitals data actually measured?
Core Web Vitals are measured from real Chrome user sessions collected in Google’s Chrome User Experience Report, not from a single lab test on one machine. Google evaluates the 75th percentile of these real visits over a rolling window, meaning a page passes a metric only when at least three out of every four actual visits meet the good threshold, across the mix of devices and connections real visitors use.
This is why a site can feel fast during your own testing and still fail in Search Console, if a meaningful share of real visitors are on slower conditions than yours. Read Website Speed: Mobile Is Slower Than Desktop for how that gap shows up in practice.
Do Core Web Vitals actually affect search rankings?
Yes, as one input among Google’s page experience signals, though content relevance and quality remain the dominant ranking factors. The stronger case for prioritising Core Web Vitals is commercial rather than purely about rankings. In a Google-documented A/B test, Vodafone improved LCP by 31 percent and measured 8 percent more sales on the faster version, a direct link between the metric and real purchasing behaviour.
This suggests Core Web Vitals matter more for conversion and retention than for search position alone. Read Downtime Impact on Revenue and User Trust for how the same logic applies to availability.