Choosing web hosting: what the cheap plan actually costs you

A customer opens your site on the busiest day of a campaign — the day a discount goes live, or stock is about to run out — and the page freezes for three or four seconds. They hit back and click the next result instead. You never see it happen: no error appears, a line in your analytics just quietly disappears.

Most of the time that has nothing to do with design or content — it comes down to the power of the server behind the site. And the server itself usually gets picked once, in a hurry, by looking at the cheapest number on the page, because "hosting" reads as a background detail to most people. Nothing feels wrong in the first few months, because traffic is low — the problem surfaces exactly when the site grows, on campaign day, and by then fixing it costs far more.

Speed isn't a technical footnote — it's a sales question

The time between the browser sending a request and the server starting to answer is called Time to First Byte (TTFB). By Google's own measurement methodology, under 0.8 seconds is good, 0.8–1.8 seconds needs improvement, and anything over 1.8 seconds is poor. (web.dev/articles/ttfb)

That number isn't an abstract stat — it directly gates when the page's main content becomes visible (LCP), because the browser cannot render anything until the server has answered. If the server sits far from the visitor, its resources are split across hundreds of other sites, or the backend software is out of date, that wait stretches out — with nothing in the design having changed at all. It also isn't only a comfort issue: Google itself lists Core Web Vitals among the signals its "core ranking systems seek to reward." (developers.google.com/search/docs/appearance/core-web-vitals)

The practical fix: ask your provider for the actual TTFB number. If you don't know what your current hosting scores, that gap is already the problem — you cannot manage what you never measured.

What "unlimited" actually stands behind

Most cheap plans advertise "unlimited storage" and "unlimited bandwidth." That isn't a lie, but it isn't the whole story either. Shared hosting is generally built on the assumption that the large majority of customers only ever use a small share of what they're allocated — a provider sells the same server to many customers precisely because, in practice, almost no one hits the ceiling. The problem shows up the moment a site gets real traffic: unwritten caps on CPU time, file counts (inodes), or simultaneous connections surface behind the word "unlimited," and the contract often reserves the provider's right to suspend an account that puts too much strain on the box. (en.wikipedia.org/wiki/Overselling)

That doesn't mean avoiding "unlimited" plans altogether — for a small, low-traffic site they're entirely reasonable. It means the right question isn't "is it unlimited," but "what number is the real ceiling." The simplest way to find that ceiling is to ask the provider directly, in writing: how much CPU time is allotted, how many simultaneous connections are allowed, and what counts as "excessive load." An evasive answer, or one that boils down to "there's no real limit in practice," is a signal on its own — and at that point a plan with dedicated resources is usually cheaper than an emergency move mid-campaign.

Cheap hosting is weakest on exactly the day you need it most.

Six things worth checking before you pick one

1. Where the server actually sits

If most of your customers browse from Azerbaijan or the region, the server should be geographically close. Distance adds milliseconds to every request — small on its own, but it stacks straight into TTFB once dozens of requests are involved. Ask for the exact city of the data centre before you sign; "somewhere in Europe" isn't a specific enough answer.

2. Who else shares the resources

How many other sites live on the same server is rarely written on the pricing page. On shared hosting, a neighbouring site's traffic spike can slow yours down too — the cheaper the plan, generally, the more neighbours. A plan with dedicated resources (VPS or dedicated) usually costs several times more, but someone else's campaign can't slow your site down — worth weighing once your own traffic starts to grow.

3. How often backups actually run

The gap between a daily automatic backup and a weekly one is exactly how much content you lose when something breaks. The question isn't whether a backup exists, but how often it runs and how long restoring it takes — a backup that exists but takes two days to restore means the campaign is already over by the time it lands. Before signing, ask how restores are actually tested; an untested backup is a hope, not a backup.

4. Who is watching the SSL certificate

When a certificate expires, the browser shows a "not secure" warning and the visitor leaves immediately. It's worth knowing in advance whether renewal is automatic and who installs security patches — get "renews automatically" in writing, not as a spoken assurance.

5. What the incident response time actually promises

"24/7 support" and "an issue gets fixed within X hours" are not the same commitment. The second one is specific and can be written into a contract; the first one is usually just marketing language. Don't take "we offer support" at face value until a specific number is in the contract.

6. How many steps it takes to add resources

When traffic grows, does upgrading the plan take one click, or does it mean a new server, a migration, and days of waiting? Whoever doesn't ask this in advance usually finds out the answer at the worst possible moment — while the campaign is still running. Ask ahead of time: "if traffic triples tomorrow, what do I click, and how long does it take?"

How complicated switching hosts actually is

Many owners keep a hosting plan they already know is bad, worried a move means "the site goes down for days." The real delay comes from DNS caching: how long your domain's address record is treated as current is set by a number called TTL, and according to Cloudflare's own documentation that window can run from seconds to a full day — proxied records are usually just over 5 minutes, while ordinary records can be set anywhere from 30 seconds to 1 day in advance. (developers.cloudflare.com/dns/manage-dns-records/reference/ttl)

The practical fix: shorten the TTL a day or two before the move (say, from a day down to a few minutes) and keep the old server running until the new one is fully live. Done that way, the switch is invisible to visitors. When it isn't planned, "the site was down for a few hours" is usually a planning gap, not a technical inevitability.

The campaign-day test

The honest test is this: if your ad spend goes up, or a sale is announced, and the site gets 5 to 10 times its normal traffic in a day, how would the current hosting hold up? If the answer is "I don't know," that's the signal to switch — before the campaign, not during it.

If you want to measure your own speed and server side, our free speed and SEO audit tool pulls real TTFB and load numbers from Google's own measurement source and explains in plain language which part is the problem.

If you'd rather plan the server, domain, DNS, SSL and backups ahead of time, our hosting and infrastructure service exists for exactly that — the accounts open in your name, the keys stay with you, and we only set up and monitor.