Website hosting — what to choose and what it actually costs

Hosting is bought once and remembered twice: when the site stops working, and when the second-year invoice arrives.

This piece is about that second moment as much as the first: what it actually costs to keep a company website on a server, how to spot the moment your plan stops being enough, and what all of that shows up as in speed — the question that comes up most often, and usually gets answered with a rule of thumb someone made up.

The advertised price is almost never the price

Let's start with the thing that upends every price comparison: the figure on a provider's page is usually a first-year price, and the bill you actually pay after can be several times higher.

We wrote down prices from the price lists of Polish providers on 25 and 26 August 2026, as part of our own research into the cost of the tools around a company website. Sixteen of the thirty-nine offers we collected have a recorded jump at renewal. Eight pairs for shared hosting look like this (net prices per year, PLN):

Two things are worth taking from it.

The jump is often a multiple, not a few per cent. A plan at PLN 39.90 net in the first year renews at PLN 678.99. That is not a price rise — it is a different price for the same product, stated up front in the small print.

The order of the advertised prices says nothing about the order of the bills. At the same provider the Biznes plan is cheaper than Start in year one (19.90 against 39.90) and more expensive after renewal (698.99 against 678.99). A comparison made on promotional prices leads to a choice that turns out worse after a year.

There are also providers without this mechanism — one price for the whole term, stated plainly. The one question worth asking before you buy: what does renewal cost — worth having in writing, not from a phone call.

The full annual bill — domain, certificate, mail and the rest — is broken down in our piece on web hosting cost.

Four kinds of hosting, and the moment you need to move

Every guide describes the kinds of hosting. Fewer describe how you will know yours has stopped being enough — the only part of this actually useful to you.

Shared hosting puts a handful to a few dozen sites on one machine. For a company site with a contact form it lasts a long time, and there is no reason to pay for more. The signal to move is not visitor count, it is how the site behaves at peak times and provider notices about exceeded resource limits.

A VPS is a carved-out slice of a server with its own configuration. People pick it not for raw power but for control: a specific software version, your own services, access shared hosting does not give you.

A dedicated server is a whole machine — sensible under constant heavy load, or when security rules out sharing hardware.

Cloud is capacity billed by usage. Sensible for uneven traffic — a season, a campaign, event sign-ups — as long as you accept a bill that grows with traffic and someone has set a spending limit.

What is deliberately missing: a measured traffic threshold. "Shared hosting is enough for up to ten thousand visits" sounds precise and is a made-up number — load is decided not by how many people arrive, but by what the site does on each visit.

What you are actually buying in a hosting package

The price list shows disk space, because it is the one line that is easy to compare. The result, though, is decided by everything else the table leaves out.

Disk space is almost never the bottleneck for a company site — a few gigabytes lasts for years, unless you store video there.

Power and limits are what you are actually buying: simultaneous requests, memory per process, database queries allowed. Often vague or absent — and what decides whether the site survives the day after a newsletter.

A certificate is usually included today, and should be: encryption is not an add-on, it is the minimum for a browser not to warn visitors away.

Mail is sometimes bundled in, and often the weakest part of the bundle. If correspondence has to work reliably, a separate service is worth considering.

Backups and support differ most between offers, and never show up in a comparison table. We come back to both below.

What to weigh this against. Providers with similar specs on paper can still differ several times over on renewal price for what looks like the same plan. The difference sits in limits, support and backups — not gigabytes.

What your site actually needs from a server

Worth knowing before a vendor says "we'll just put it on whatever."

A WordPress site needs a current PHP version and a database, and — once plugins are involved — noticeably more memory than its disk size suggests. The common symptom of an undersized plan is not a crash, it is a panel that lags when you save a post.

A Node.js application — Next.js, Nuxt and the like — needs somewhere to run as a process, not just a file server. Plenty of cheap shared plans do not offer that at all, so "can we run a Node app there" is the first question, not the last.

A shop adds a database working harder on every cart, and security requirements from handling payments — where "the cheapest plan will do" runs out fastest.

A static site — generated in advance as finished files — is the least demanding of all, and fits even on plans that carry nothing else.

The takeaway: the order is the reverse of what people expect. First you know what the site is built on, then you choose the server. Choosing hosting first usually ends in an upgrade, or a move, by month three.

What hosting actually changes about speed — our own measurement

This is usually where someone promises "fast hosting will speed up your site," and nobody measures it. We can, because we collect measurements from this site's real visitors.

The metric where hosting shows up most clearly is TTFB — time to first byte, what happens before the browser has drawn a single pixel. Between 26 July and 11 September 2026 we collected 10,003 measurements, of which 2,744 are TTFB specifically.

Our result at the 75th percentile: 803 ms, with 75% of measurements in the "good" band. For reference, web.dev gives a rough guide: a good TTFB is 0.8 seconds or less, a poor one is above 1.8 seconds — and it points out that TTFB is not one of the Core Web Vitals. Our 803 ms therefore sits right on the edge of the good band.

What that means for you:

• TTFB is not the whole of speed, but it is its floor. Everything the browser does starts after this point; no image optimisation claws that time back.
• Hosting accounts for part of this number, not all of it. The rest is how the site is built: fresh assembly on every visit, or handing over something already built. Our biggest single gains came from code changes, not the server — measured, and covered in our piece on testing a site.
• If your TTFB is high, changing hosting is the first thing to check — the second is why the server is doing that much computing at all.

Domain — what belongs to hosting, and what does not

A domain and hosting are two separate services with two separate bills, often sold together, which confuses people at purchase and costs them at the first move.

The domain is an address and belongs to you regardless of where the site is hosted — move it to another registrar and the site stays put. Hosting is where the site physically sits.

Three consequences follow. Keeping both with one provider is convenient, until you want to change only one. A domain has its own renewal cycle and its own post-promotion price, usually higher than at registration. And if a vendor registers the domain "in their own name," it is not your domain — one of the most expensive things that can happen when an agency relationship ends. Prices and cycles we break down in a separate piece.

When a CDN makes sense, and when it is spending with no return

A content delivery network keeps copies of your site's files around the world and serves each visitor from whichever copy is closest.

It makes sense when your audience is spread out geographically, or the site serves a lot of heavy files — images, video, downloads. Not worth it as a default add-on when your customers are in Poland and the server is in Poland or close by: the distance a CDN shortens is already short.

Worth knowing: getting started costs nothing. The largest provider offers a free plan covering DNS, content delivery and a certificate, with paid plans starting at 20 USD a month adding a firewall and image optimisation (our own pricing survey, captured 26 August 2026). For most company sites the free plan is enough, and a paid conversation only starts once security requirements or an uptime guarantee are on the table.

What the price list does not show

Limits you find out about on the day you cross them. Disk space is visible; limits on processing power, process counts and database queries sit next to it, unadvertised. Crossing them ends in a slower site, or an outage.

A "99.9% uptime guarantee" is a paid feature, not a property of hosting in general. Among content-delivery providers, a formal guarantee only appears on plans running several hundred dollars a month; cheaper plans offer intent, not compensation.

Backups can be an add-on. The question is not "do you back up," it is "how often, how far back, and what does restoring cost" — the third part is sometimes a separate paid service.

Mail on your domain is its own decision. Bundled mailboxes can be cheap and unreliable; moving mail to a specialist service is a common, sensible choice.

How you find out the site is down

The most expensive outage is the one you hear about from a customer. Uptime monitoring checks your site every few minutes from outside and alerts you when it stops responding — one of the few things here that costs nothing.

In our own pricing research, the most popular service of this kind has a free plan checking every five minutes across fifty monitors; paid plans start at 9 euro a month and cut that to one minute (captured 26 August 2026). The free plan is enough for a company site, and the gap between knowing in five minutes and knowing six hours later is the gap between an incident and an embarrassment.

The second question: who responds. Monitoring sends the alert; someone has to act on it. If the answer is "our vendor," a written response time is the difference between a contract and a hope.

Moving hosts — when it is cheap, and when it is not

Moving hosting is simpler than people expect, and pricier than the lists suggest, for one reason: the cost sits not in moving the files but in everything around them.

It is cheap when you move a site without changing its address or its technology: a copy of the files, a copy of the database, a domain switch, a check. Some providers do this for you at no extra charge.

It gets expensive when something else changes at the same time — the software version, the URL structure, the mail provider. At that point it is not a move any more, it is a migration, and it runs by its own rules; we lay them out in our guide to website migration.

One thing worth remembering regardless of scale: switching a domain is not instant. For a while, part of the internet sees the old server and part sees the new one — which is why the old one stays switched on for a few days after the move, rather than being turned off on the day you flip the switch.

Four checks to see if your current hosting is holding you back

Four checks, a few minutes each, none of them needs a developer.

1. Measure TTFB on your own site, in your browser's developer tools, with network throttling set to a mobile profile. Above roughly a second, it is worth asking what is taking that long.
2. Check when your plan renews, and for how much. In the provider's account panel, not on the marketing page — those are two different numbers.
3. Ask for a backup to be restored from a chosen day. Not confirmation that backups exist — that is the only way to find out whether the process actually works before you need it to.
4. Check who the domain is registered to. In the public registry (for .pl domains, the WHOIS service at dns.pl), not in an email from your vendor.

Where these numbers come from

• This site's TTFB, 803 ms at the 75th percentile — the web-vitals collection in our own database: 10,003 measurements from real users of this site between 26 July and 11 September 2026, of which 2,744 relate to TTFB.
• TTFB thresholds: good up to 0.8 s, poor above 1.8 s — web.dev, checked at source on 5 October 2026; a rough guide, TTFB is not a Core Web Vitals metric.
• Content-delivery plan pricing (the free plan and the 20 USD/mo entry paid tier) — our own pricing survey, captured 26 August 2026.
• Uptime-monitoring plan pricing (the free plan and the 9 EUR/mo entry paid tier) — our own pricing survey, captured 26 August 2026.
• The thresholds for moving between kinds of hosting — our own observation from our implementations, not a measured benchmark; we do not give a measured traffic threshold because none exists.
• Hosting prices in the first year and after renewal — our own research into the cost of tools around a company website: 39 observations in the infrastructure category, prices taken from Polish providers' price lists on 25 and 26 August 2026, 16 of them with a recorded renewal jump.