Core Web Vitals: What Your Hosting Controls (and What It Doesn't)
If you’ve ever run your site through PageSpeed Insights, you’ve seen three acronyms in the “Core Web Vitals” box: LCP, INP and CLS. Google uses them as a signal of page experience, and they’re a decent proxy for whether real visitors find your site fast.
What nobody tells you on the results page is which of those numbers your hosting can actually change. Some it controls heavily. One it barely touches. Knowing which saves you from paying for a faster server to fix a problem that lives in your theme — or the opposite.
The three metrics, in plain terms
| Metric | What it measures | ”Good” threshold |
|---|---|---|
| LCP — Largest Contentful Paint | How long until the main content (usually the hero image or headline) appears | 2.5 s or less |
| INP — Interaction to Next Paint | How quickly the page responds when someone taps or clicks | 200 ms or less |
| CLS — Cumulative Layout Shift | How much the page jumps around while loading | 0.1 or less |
Google assesses these on real visitor data, at the 75th percentile — meaning three out of four visits need to hit “good.” Lab scores from a single test are useful for debugging, but the field data is what counts.
LCP: where hosting matters most
LCP is the sum of a chain: the server responds (TTFB), the browser downloads the HTML, discovers the hero image, downloads it, and paints it.
Hosting owns the first link of that chain, and it’s often the biggest one. A server that takes 1.2 seconds to respond has already used half the 2.5-second budget before the browser has seen a single byte. That’s why a cached, well-tuned server makes LCP drop so sharply — we covered how to measure it in what “high-performance hosting” actually means.
What hosting doesn’t control in LCP: a 3 MB hero image, a hero that’s lazy-loaded (it shouldn’t be), or a slider that waits for JavaScript before showing anything.
Hosting’s share of LCP: large.
INP: mostly your site’s JavaScript
INP measures how long the page takes to visibly respond after an interaction — opening a menu, adding to cart, typing in a field. Almost all of that time is spent running JavaScript in the visitor’s browser, on their phone.
The server can’t speed up a visitor’s phone. If INP is poor, the cause is almost always heavy scripts: page builders, chat widgets, tracking tags, sliders, and plugins that run code on every tap.
The exception: interactions that wait on the server, like an AJAX add-to-cart or a live search. There, a slow backend shows up in INP. For stores this matters — see WooCommerce hosting in Costa Rica.
Hosting’s share of INP: small, except for server-backed interactions.
CLS: not a hosting problem
CLS happens when things move after they first appear: images without set dimensions, ads or banners injected above the content, web fonts that swap in and change line lengths. All of that is decided by the theme and content.
A faster server doesn’t fix layout shift. Occasionally it can even make it more visible, since content appears sooner and then gets pushed.
Hosting’s share of CLS: essentially none.
What to do with this
- Open PageSpeed Insights and look at the field data first (the “Discover what your real users are experiencing” section), not just the lab score.
- If LCP is poor, check TTFB. If the server response is slow, that’s a hosting conversation. If it’s fast but LCP is still poor, look at your hero image and render-blocking resources.
- If INP is poor, audit scripts. Remove plugins and third-party tags you don’t need. This is a site problem, not a server one.
- If CLS is poor, fix dimensions. Set width and height on images and reserve space for anything that loads late.
What a LiteSpeed host takes off the table
On HOSTEMCLOUD, the server side of LCP is handled at the platform level: LiteSpeed with server-level page caching, HTTP/3, and Google Cloud compute. Install LiteSpeed Cache on WordPress and set the options that matter, and TTFB stops being the problem. From there, the remaining work is in the theme — and it’s much easier to fix knowing exactly where to look.
Frequently asked questions
Do Core Web Vitals affect Google rankings?
They’re part of Google’s page experience signals. They won’t outrank better content on their own, but between two similar pages, the faster one has an edge — and visitors notice either way.
Why is my mobile score worse than desktop?
Mobile tests simulate a slower device and network. Heavy JavaScript and large images hurt much more there, which is where most visitors actually are.
Will moving to a faster host fix my Core Web Vitals?
It fixes the server part of LCP. If your problems are INP or CLS, you need changes to the site itself.
Want TTFB off your list of problems? Get started with UNITY.