You switched to better hosting. Or you're paying good money for it already. And yet, your Core Web Vitals are still orange. Maybe even red. So... was the hosting a waste of money?
No. But it was never going to be the whole story either. Let's break down what hosting can fix, what it can't, and how to find out which one is holding your shop back.
What hosting actually does for your performance: TTFB
Time to First Byte (TTFB) measures how long it takes before the very first byte of your HTML arrives in the browser. Google considers anything under 800ms good, and above 1.8 seconds poor.
This is the one metric where your hosting and server setup do a lot of the heavy lifting. The TTFB consists of multiple phases: redirects, DNS lookup, connection time and server response time. In the real user data we collect, most time is typically spent in that last part: your server thinking about what HTML to send back.
And here's the thing: TTFB is the first domino. It's one of the four LCP sub-parts, and according to both CrUX data and our own RUM data, it's the biggest one. If your TTFB is 1.5 seconds, that delay carries straight over into your First Contentful Paint and your Largest Contentful Paint. Your users are staring at a blank tab while nothing has even started downloading yet.
Knowing that LCP is the most failed Core Web Vitals metric out there, a healthy TTFB is not a nice-to-have. It's your foundation.
So a fast server fixes my TTFB?
Mostly, yes. But even with great hosting, we keep running into the same TTFB killers in real user data:
- Cache misses you don't know about.Tracking parameters like
srsltidorgclidquietly bypass your caching layer, because the URL looks "new" to your cache. The page then gets fully generated by Magento or Shopify on every single visit. We've seen this make TTFB over 100% worse on affected pageviews. - Redirects. Server side redirects count towards your TTFB. Ads are a usual suspect here.
- A caching strategy that only works in theory. Your homepage might be cached perfectly, while your category pages with filters are a cache miss party.
This is exactly why lab tools won't tell you the truth here. Lighthouse tests one URL, once, from one location, without your real traffic mix. Your actual users arrive from Google Ads with five tracking parameters attached, on a 4G connection, hitting an uncached filter page. That's the TTFB that counts. That's also the TTFB Google counts for Core Web Vitals.
Where hosting stops: render-blocking resources
Now for the uncomfortable part. Say your TTFB is a beautiful 300ms. The HTML arrived almost instantly. Great hosting, money well spent.
The browser still won't paint a single pixel.
Why? Because by default, every CSS file in your <head> is render-blocking. Synchronous JavaScript too. The browser refuses to show anything until those files are downloaded and parsed. Your hero image might be sitting there, fully downloaded and ready to go, while the browser waits for a 300KB stylesheet, a consent script and that one A/B testing tool from 2021.
In other words: a fast server delivers a blank page faster. Congratulations!
This shows up in the LCP sub-parts as resource load delay and element render delay. And our data confirms it: after TTFB, element render delay is the second biggest LCP bottleneck we see across sites. That part is 100% on your frontend, your theme and your third parties. Your hosting provider can't fix it for you, no matter how much you pay them.
Hosting and frontend: you need both
So which one should you care about? Wrong question. They multiply, they don't substitute:
| Situation | Result |
|---|---|
| Slow hosting + clean frontend | Users wait for the server, then everything appears |
| Fast hosting + render-blocking mess | Users wait for the server a little, then keep waiting anyway |
| Fast hosting + clean frontend | This is the one. |
The business case for getting both right is well documented. Renault cut their LCP by 1 second and saw bounce rate drop 14% while conversions went up 13%. Vodafone improved LCP by 31% and sold 8% more. These weren't redesigns. They were performance fixes.
How to find out which side is your problem
You don't have to guess, and please don't. This is a 15 minute job with sub-part data from your real users:
- Look at your TTFB first. Above 800ms at the 75th percentile? Talk to your hosting provider and review your caching strategy. Segment by cache hit versus miss, and by pages with tracking parameters. If cache misses dominate, hosting horsepower isn't your problem; your caching rules are.
- TTFB fine, LCP still slow? Then look at resource load delay and element render delay. Audit what's render-blocking in your
<head>: CSS, fonts, synchronous scripts, third parties. Inline your critical CSS, defer the rest, and don't lazyload your LCP image. (Yes, we still see that one weekly.) - Watch it per template. Your homepage, category pages and product pages each have their own bottleneck. One number for your whole site hides where the real pain is.
The nice thing about real user monitoring is that you don't wait 28 days for CrUX to slowly confirm what happened. A cache problem or a render-blocking third party shows up in your data the same day. Which also means: one month of measuring is genuinely enough to find your first quick wins.
So if you've recently got access to RUMvision: don't let it sit there collecting dust. Drop in the snippet (5 minutes, we promise), let it collect a few days of traffic, and open the LCP breakdown. Your data will tell you whether to call your hosting provider or your developer first.
The health check will do a lot for you, way more than just looking at your TTFB.
Either way, you'll stop guessing. And your users will notice before Google does.
