I’ll research current data on hosting performance, Core Web Vitals, and conversion impact before writing.Let me get more specific data on hosting infrastructure, TTFB, and server response time.I have strong data. Let me write the article now.
Cheap hosting is a tax you pay every single day
Somewhere in your company, a decision got made to save forty pounds a month on hosting. Maybe it was years ago, before you arrived. Maybe a developer picked the cheapest plan that would run WordPress and nobody questioned it. That decision is still being made, every hour of every day, in the form of slower page loads, lost enquiries, and search rankings that quietly slip while your team blames the content.
Here is the uncomfortable shape of it. Hosting is the one infrastructure choice that touches every page, every visitor, and every conversion you will ever generate. Get it wrong and no amount of image compression, lazy loading, or clever caching plugins fully undoes the damage. You can spend months optimising around a slow server. You will never out-optimise the server itself.
What we see on most mid-market B2B sites is a host chosen for its sticker price, then a long, expensive campaign to patch over the consequences. That is backwards. The cheap host is not saving you money. It is the most expensive line item you have, you just are not seeing the cost on an invoice.
The bottleneck has a name, and it is TTFB
Before a single image appears, before any of your fonts or scripts load, the browser sends a request and waits for your server to respond. That wait is Time to First Byte (TTFB). It is the rawest measurement of how fast your hosting actually is, and it is the thing cheap hosting gets wrong most often.
Why does it matter so much? Because everything else is stacked on top of it. TTFB is a foundational metric; this means that time added to the TTFB will also be added to the Largest Contentful Paint and the First Contentful Paint. Your server’s slowness does not stay contained on the server. It pushes back every visible moment of the page load.
The threshold to aim for is clear. A good Time to First Byte is 800 milliseconds or less at the 75th percentile. This means that 75% of your users should receive the first byte of the response within 800ms. Anything above 1.8 seconds is genuinely poor, and on a congested shared server that number is alarmingly easy to hit during a traffic spike.
The relationship to your Core Web Vitals is mechanical, not vague. TTFB is the first phase of LCP. The LCP timeline is: TTFB + resource load delay + resource load duration + element render delay = LCP. High TTFB pushes the entire LCP timeline later, making it the single most impactful factor in LCP scores. Put the other way around, a fast server hands you a head start. A server delivering 50ms TTFB gives you 2,450ms of headroom to achieve a “good” 2.5s LCP.
This is why hosting is not a footnote in a performance project. It is the opening move. Google’s own engineers are blunt about it: before you even consider other optimization approaches, hosting should be the first thing you consider.
What the 2025 data actually shows about slow servers
The clearest illustration of how badly this can go comes from recent field data. According to the 2025 Web Almanac, sites with poor LCP spend an average of 2.27 seconds on TTFB alone, which nearly exhausts the entire 2.5 second LCP threshold before the browser even begins to render the page.
Read that again. The server eats almost the entire performance budget before any content draws. Those sites were never going to pass Core Web Vitals, regardless of how lean their front-end code was. The race was lost at the server.
What “cheap hosting” is actually selling you
The reason a budget plan costs four pounds a month is that you are not the only tenant. With shared hosting, your website’s resources are hosted on a single physical server. It’s called “shared” because multiple websites borrow bandwidth, CPU, RAM and storage from that same server.
That arrangement carries a specific, recurring risk. In shared hosting, your website’s performance can be influenced by the other websites on the same server. If one website experiences a surge in traffic or consumes a disproportionate amount of resources, your website’s speed and performance could suffer. Your site can grind to a halt because of a stranger’s marketing campaign on a domain you have never heard of.
And the gap is not marginal. A site loading in under one second on cloud infrastructure might take three to five seconds on a congested shared server. Concrete benchmarks back this up: migrating to an autoscaled WordPress setup on AWS has been shown to improve Time to First Byte (TTFB) from 135ms to 55ms, a 2.5x performance boost under load.
The villain here is not the hosting company. It is the assumption that hosting is a commodity, that one box of server is the same as another, and that the only variable worth comparing is the monthly price. That assumption is what quietly costs you customers.
Now put a revenue number on it
Slow pages are not an abstract technical concern. They show up directly in your conversion rate, and the research on this is remarkably consistent.
The drop-off is steep and well documented. Even a one-second delay in page load time can result in a 7% decrease in conversions. On mobile, where so much B2B research now happens, the cliff is even sharper. According to recent research, 53% of website visits are abandoned when a mobile site takes three seconds or longer to load.
For B2B specifically, the difference between a fast site and a slow one is not a few percentage points. It is a multiple. B2B sites loading in 1 second have 3x higher conversion rates than 5-second sites and 5x higher than 10-second sites. Cloudflare puts the same idea into pounds and pence: one study found that on average, a two-second delay in a website’s page rendering led to about a 4% loss in revenue per visitor.
Run that through your own numbers. If your site generates leads worth real money, a two-second improvement is not a vanity metric. It is the difference between hitting pipeline targets and missing them. The forty pounds you saved on hosting is being dwarfed by the enquiries that never arrive.
The slow server also costs you visibility
The revenue loss compounds because slow hosting also touches search. On 12 March 2024, Google removed the last of the ambiguity here. Google updated their official documentation to state that Core Web Vitals are used by their ranking systems.
Be honest about the weight of this signal, though. Google’s own John Mueller has been consistent: Core Web Vitals are not major ranking factors, and content quality still does the heavy lifting. Treating Vitals as a magic lever for rankings is a mistake.
The real mechanism is more interesting, and it is one cheap hosting sabotages at the root. Better Core Web Vitals improve user engagement, which can indirectly benefit rankings through increased time on site and lower bounce rates. A slow server drives people away before they read a word. That behaviour, the instant bounce back to the search results, is exactly what Google’s systems are built to notice.
There is a structural trap on shared hosting that compounds this. If a specific URL does not have sufficient CrUX data, Google falls back to the entire origin’s CWV scores. This means poor performance on high traffic pages can drag down rankings for low traffic pages across your entire site. One slow, popular page can tarnish how Google perceives the speed of your whole domain.
Why optimising after launch is the expensive path
The standard playbook goes like this. Build the site on cheap hosting. Launch. Notice the speed scores are bad. Hire someone to fix them. Install caching plugins, compress images, defer scripts, and slowly claw the numbers back. Months pass. Budgets get spent. The site ends up acceptable.
The trouble is that most of that effort is treating symptoms. TTFB is typically 10-30% of total page load time, but it is the portion most directly controlled by your hosting infrastructure. You can lazy-load every image on the page and the server still makes the visitor wait before any of it begins.
There is a real ceiling here. Traditional CDNs cache only static assets (images, CSS, JS) and do not reduce TTFB for the HTML document itself, which is the most critical component. The single most important byte, the start of your HTML, still depends on how fast your origin server can generate the page. If that server is overloaded and underpowered, no front-end trick saves you.
This is the philosophy behind how we work at NexusBond. We set performance budgets before a single design is signed off, and TTFB is one of the first numbers in that budget. We make the hosting and infrastructure decision early, while it is still cheap to change, rather than discovering after launch that the foundation cannot carry the build. Fast by default beats fast after months of patching, and it costs a fraction as much.
Caching helps, but it does not rewrite physics
Good caching is genuinely powerful. Serving a pre-built HTML page instead of generating it on every request can take TTFB from several hundred milliseconds down to almost nothing for cached pages. On well-configured infrastructure with an event-driven server and integrated caching, cached pages can return in under 20 milliseconds.
The catch is in the word “cached”. The pages that matter most for conversion, a logged-in dashboard, a search results page, a personalised quote, a checkout, are frequently the ones that cannot be cached because they are different for every visitor. If you’re running a larger application with many users that involves personalization, database querying, and other intensive server-side operations, your choice of hosting becomes critical to lower TTFB in the field. For those pages, raw server horsepower is the only thing that helps.
What to actually look for in a host
The goal is not to chase the most expensive option. It is to match the infrastructure to what your business genuinely needs, then refuse to compromise below that line. Cloud hosting earns its keep precisely because it solves the noisy-neighbour problem. Cloud hosting allows each user to have their own individual pool of resources thanks to virtualization. Other websites cannot hog resources that your site needs to perform well. Maximizing resources and allocating more only where necessary improves performance and stability.
When you are evaluating a host, Google’s engineers point to two questions most people never ask:
- How much memory is your application instance actually given? If your application has insufficient memory, it will thrash and struggle to serve pages up as fast as possible.
- Does the provider keep the backend stack current? As new versions of application backend languages, HTTP implementations, and database software are released, performance in that software improves over time. A host running ancient PHP is leaving free speed on the table.
Beyond that, look for an event-driven web server rather than an older process-based one. LiteSpeed’s event-driven architecture and integrated caching deliver lower TTFB than Apache’s process-based model, particularly under concurrent load. Look for NVMe storage, HTTP/2 or HTTP/3, Brotli compression, and the ability to add object caching with Redis or Memcached for database-heavy pages.
And measure honestly. Lab scores are not what Google uses. Only real user Core Web Vitals data affects SEO. PageSpeed scores and Lighthouse data don’t influence rankings at all. Judge your host on field data from real visitors, not a one-off test from a fast office connection.
The total cost picture, told straight
When you tally everything, the cheap option frequently loses on pure economics, not just performance. Shared plans sit around four to fifteen pounds a month, but that headline price hides the maintenance burden, the downtime risk, and the lost revenue from slow loads. Shared hosting carries a base cost plus 3 to 5 hours per month of maintenance time, plus potential revenue loss from downtime and slow page loads. Decent cloud hosting for a small business site can start in a similar range while removing the resource contention that causes the slowdowns in the first place.
So the calculation is not “cheap versus expensive”. It is “a small known cost now versus a large hidden cost forever”.
What to do this week
You do not need a migration project to find out where you stand. Start with three concrete steps you can complete in an afternoon.
- Pull your real TTFB. Open PageSpeed Insights and look at the field data section, not the lab score. If your TTFB at the 75th percentile is above 800ms, your hosting is actively holding back every other metric. If it is above 1.8 seconds, treat it as urgent.
- Test under load, not at rest. A cheap server often looks fine at 3am and falls over during your busiest hour. Check your analytics for your peak traffic window and run tests then. The noisy-neighbour effect only shows up when the server is busy.
- Put a pound figure on the gap. Take your monthly site revenue or lead value, and apply the 7% conversion drop per second of delay to whatever your TTFB is costing you. The number is usually large enough to end the “but the hosting is so cheap” conversation on its own.
If those numbers come back ugly and you want a second opinion on whether your hosting is the bottleneck or something downstream of it, you can book your free discovery call and we will look at your specific setup with you.
The site you are running today was shaped by a hosting decision someone made to save a little money. You get to decide whether that decision keeps costing you, or whether this is the week you stop paying the tax.
Ready to get started?
