I am going to start this one by telling you what is not in it. There are no Core Web Vitals scores for my sites in this post. Not a single LCP figure, no INP, no CLS. I tried to collect them properly on 19 September 2026, the PageSpeed Insights API answered HTTP 429 because the keyless daily quota was already spent, and I have not re-run it with a key yet. And even when I do, the field data section will stay empty, because Google’s field dataset only reports pages that get enough real-world visits, and my blogs do not come anywhere near that.
That could have been a reason to skip the topic. Instead it turned out to be the most useful thing about it, because it forced me to separate the part of Core Web Vitals that a cheap shared hosting plan actually touches from the much larger part that has nothing to do with your host at all. That separation is what this post is about, and I can support it with measurements I did take.
Who owns which metric
Google defines three metrics with three thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1 (Google’s documentation on Web Vitals). Every speed guide I have read treats these as one problem with one solution, usually “get faster hosting”. They are not one problem.
| Metric | What it measures | How much your hosting plan decides |
|---|---|---|
| LCP | When the biggest visible element finishes rendering | Partly. Server response is the first slice of it; images, fonts and render-blocking assets are the rest |
| INP | How quickly the page responds when someone interacts with it | Essentially none. This is your JavaScript: theme, plugins, ad scripts, embeds |
| CLS | How much the layout jumps while loading | None at all. This is markup and CSS: image dimensions, ad slots, late-loading banners |
So when someone tells you a faster plan will fix your Core Web Vitals, they are talking about part of one metric out of three. Worth knowing before you upgrade anything.
The one number I did measure, and what it costs me
On 20 September 2026 I measured time to first byte on my own sites: five requests each, roughly two seconds apart, from my home fibre connection in Valencia, Spain, using curl. I publish the median plus the minimum and maximum rather than a single number, because the single number would be flattering and misleading.
| Site | Median first byte | Range across five requests | Share of a 2.5 s LCP budget |
|---|---|---|---|
| This blog | 0.455 s | 0.379 s to 0.895 s | 18% at the median, 36% at worst |
| My second blog | 0.568 s | 0.534 s to 1.500 s | 23% at the median, 60% at worst |
Read the right-hand column slowly. At the median, this blog has spent roughly a fifth of its entire LCP budget before the browser has received one byte of HTML, and that is measured from a connection in the same country as the server. On the worst of five requests to my other blog, sixty per cent of the budget was gone before anything could start rendering. Whatever your theme does after that, it is doing it with the change from a very small note.
The reason is not mysterious, and it is the finding I did not enjoy: neither blog returns a page-cache header of any kind, so every request is assembled by PHP 8.3.33 from scratch. How I confirmed that, and what I am changing because of it, is a post of its own: I thought my blog was cached, and it was not.
Variance is the part nobody advertises
Look at the range column again: 0.534 s to 1.500 s on five consecutive requests to the same page. That is almost a factor of three, within about a minute, on a site with essentially no traffic of its own. Nobody was hammering it. Whatever else the server was doing in that minute, I have no view of it, and on a shared plan neither do you.
This matters for Core Web Vitals in a way a median hides, because the metric you are assessed on is a percentile across real visits, not your best afternoon. A plan that usually answers in half a second but occasionally takes a second and a half will fail more visitors than its average suggests. If I could publish only one number from this whole exercise, it would be the spread, not the median, and the fact that most hosting reviews publish neither should tell you something about how those reviews are made.
This is also the clearest practical difference I have found between the shared plan and the VPS I run my own small app on, where the same measurement came back tighter. I put the two side by side in the comparison of the shared plan and the VPS I pay for at the same time.
A hundred kilobytes of HTML before anything else loads
The other number from that afternoon: this blog’s homepage is 100,574 bytes of HTML uncompressed, served as 26,886 bytes thanks to Brotli. Compression is doing its job. What compression cannot fix is that a hundred kilobytes of markup is a lot of markup for a page that shows a headline, some text and a list of links.
That weight comes from the theme, and it is entirely within my control, unlike the server response time which I share with strangers. It is also the honest boundary of what I measured: HTML only. No stylesheets, no JavaScript, no images, no fonts. Those are what usually decide LCP in practice, and I have not measured them here, so I am not going to talk about them as if I had. A content delivery network does not shrink them either, which I looked into separately in the post on whether a CDN changed anything on my sites.
The two metrics your host cannot help with
INP and CLS are where a cheap plan stops being the excuse. Both are decided by what your pages load and how they are built.
- Every plugin that enqueues JavaScript on the front end is an INP risk. Not because plugins are bad, but because scripts you never look at run on every page view. The audit worth doing is a list of what actually loads on a post, compared against what you would miss if it were gone.
- Third-party embeds are the expensive kind. A comment system, a chat widget, an analytics tag and an ad script are four separate parties executing code in your visitor’s browser, and you control the timing of exactly none of them.
- CLS is mostly a markup discipline problem. Images and iframes with explicit width and height attributes, space reserved for anything that loads late, and nothing injected above content that is already on screen.
- Ad slots deserve their own line. This blog is applying to run display advertising, and ad units that load into unreserved space are one of the classic ways to wreck a CLS score that was fine the day before. If you monetise, the layout has to be built with the slot sizes already accounted for, not patched afterwards.
Lab data, field data, and why a small site has neither
PageSpeed Insights shows you two things on one screen and people conflate them constantly. The top section, when it appears, is field data: what real Chrome users experienced on that URL. The bottom section is a lab test run on demand in a simulated environment. Only the first is what Core Web Vitals assessment is based on.
A site with very little traffic gets no field data, because there is not enough of a sample to report. That is my situation and probably yours if you are reading a post about cheap shared hosting. Which leaves the lab test, which is genuinely useful for finding specific problems, and genuinely useless as a scoreboard: it is one simulated run on one connection profile, and it will move by ten points between two runs on the same page.
So the practical answer for a small site is to use the lab test as a list of things to fix, ignore the score, and treat the first-byte measurement you can take yourself as the one number you can track over time. How I collect that, and the other free tools in the rotation, is in the post on the free SEO tools I actually open.
My fix list for this blog, before touching the plan
For context on what “cheap” means here: the entry tier on my host’s shared hosting page is advertised at $2.99 a month on a 48-month term, renewing at $10.99 a month (Hostinger web hosting pricing, checked 20 September 2026). That is the price class this post is about. My running order is:
- Turn on page caching, then repeat the same first-byte measurement with the same script and compare against the figures above. This is the one change that should move the server slice of LCP.
- Get the PageSpeed Insights API key, run every published URL through it, and store the results with dates so that later comparisons mean something.
- Cut the homepage HTML down. A hundred kilobytes for a list of posts is theme weight I chose and can unchoose.
- Reserve the ad slots in the layout before any advertising script exists, rather than after.
- Leave the plan alone until the first three are done. Upgrading hosting to fix a site that is not cached would be paying for someone else to hide my own mistake.
When those numbers exist, they will be published here with the date, the method and the number of measurements, the same as everything above. If they turn out to be disappointing, they will be published anyway. A post about Core Web Vitals that only reports the runs that went well is not a post about Core Web Vitals, and there are already enough of those.