Shared, VPS, or Managed: How to Read a Hosting Spec Sheet

Hosting comparison pages are an exercise in advertising whatever is cheapest to print. Unlimited bandwidth, unlimited databases, a free domain, a 99.9% uptime promise. Meanwhile the specs that decide whether your site feels quick are either buried in a footnote or absent entirely. The good news is that the list of things that genuinely matter is short, and you can measure most of it before you hand over a card.

Where your page load actually goes

Before comparing tiers, it helps to know what you are buying. Here is a single request, broken into the parts a host does and does not control:

|--DNS--|--TCP--|--TLS--|---server thinks---|--transfer--|
    ^        ^       ^            ^                ^
    |        |       |            |                |
 your DNS  network  cert +     PHP, database,   bandwidth +
 provider  latency  handshake  filesystem      response size
                               ^^^^^^^^^^^^^
                               this is the part
                               a host mostly controls

DNS is usually somebody else's job. Network latency is mostly physics and geography. The TLS handshake is a fixed cost you pay once per connection. The part where the host earns or loses your money is the middle chunk: how fast PHP starts, whether the opcode cache is warm, how quickly the database answers, and how fast the disk is.

That middle chunk is what people mean by TTFB, and it is the number to compare.

The three tiers, honestly

What you control at each hosting tier

	Shared	VPS	Managed platform
Root access	No	Yes	No
Who patches the OS	Host	You	Host
Web server	Usually Apache or LiteSpeed	Your choice	Fixed by the platform
.htaccess honored	Usually yes	If you run Apache	Often no (nginx)
Noisy neighbors	Yes	Some (CPU steal)	Abstracted away
Scales by	Upgrading the plan	Resizing the box	Adding instances
Fails because of	Resource limits	Something you forgot to update	The bill

Shared hosting puts hundreds of sites on one machine with per-account limits on CPU, memory, and processes. Its reputation is worse than it deserves: for a blog, a brochure site, or a small store, a decent shared plan on modern hardware is genuinely fine. The real constraint is not raw speed, it is the ceiling — when a post does numbers, you hit a process limit and the site starts returning errors rather than just getting slower.

A VPS gives you root and gives you responsibility. You choose the stack, you tune it, and you are now the person who applies security updates on a Friday night. Fantastic if you want that control. A liability if nobody on the team wants to own it, because an unpatched VPS is meaningfully worse than shared hosting where somebody else is paid to care.

A managed platform sells you the operational work: deploys, runtime, scaling, backups. You give up config-level control, and .htaccess usually stops being a thing because most of them run nginx. Costs more per unit of compute, often less per unit of your time.

There is no correct tier. There is a correct answer to "who is going to run this," and the tier follows from it.

The seven specs worth comparing

1. PHP version, and whether OPcache is on. OPcache stores compiled PHP bytecode in memory so your code is not recompiled on every request. It is the single largest PHP performance factor on this list, and it is a one-line setting. A host running an end-of-life PHP version with OPcache off is telling you how much attention the platform gets.
2. HTTP/2 or HTTP/3. HTTP/2 multiplexes many requests over one connection, which removes the old six-connections-per-host bottleneck. HTTP/3 runs over QUIC and recovers faster on lossy mobile networks. Both are table stakes now; the absence of HTTP/2 is a genuine red flag.
3. Storage type. NVMe over SATA SSD is a real difference for database work, and both are a different universe from spinning disks. If a spec sheet just says "SSD storage," it is worth asking.
4. Where the database lives. Same machine means a socket connection and sub-millisecond latency. A separate database host adds a network hop to every single query. A page doing 40 queries feels that.
5. Datacenter location. Round-trip latency is bounded by the speed of light through fiber, and no amount of caching fixes a transatlantic hop on an uncached request. Host near your audience, not near yourself.
6. Backups: frequency, retention, and restore. Everyone advertises backups. The questions that matter are how often, how far back, whether you can restore a single file or only the whole account, and whether restoring costs extra. A backup you have never restored is a hypothesis.
7. Whether you can set response headers. If you cannot set Cache-Control and security headers, you cannot do a meaningful chunk of the performance and hardening work. On Apache and LiteSpeed that means .htaccess with AllowOverride permitting it.

Reading the fine print

Three phrases that consistently mean something other than what they say:

• "Unlimited bandwidth." Bandwidth is metered and paid for by somebody. What this means is "no counter in the dashboard, subject to the acceptable use policy." The real limit lives in the terms of service, usually as a fair-use clause. Go read it.
• "99.9% uptime." That is up to about 43 minutes of downtime a month, and the guarantee is typically backed by a credit on your next invoice rather than anything resembling your actual losses. Also check what counts as downtime — scheduled maintenance often does not.
• "Free migration." Frequently one site, done once, on their schedule, and it may not include your custom cron jobs or mail. Worth having, not worth choosing a host over.

And the pricing pattern that catches everyone: the headline number is a first-term promotional rate, often requiring a multi-year prepay, and it renews at two or three times that. Compare renewal prices, not introductory ones. This is not sharp practice exactly, it is just standard, and it is entirely avoidable if you look.

Measure it yourself

You do not need a benchmarking suite. curl reports the whole breakdown, and the numbers are cumulative from the start of the request:

curl -o /dev/null -s -w \
'dns:     %{time_namelookup}\n\
connect: %{time_connect}\n\
tls:     %{time_appconnect}\n\
ttfb:    %{time_starttransfer}\n\
total:   %{time_total}\n' \
https://example.com/

Because they accumulate, you get each phase by subtracting: TLS handshake time is time_appconnect minus time_connect, and server processing is roughly time_starttransfer minus time_appconnect. That last figure is the one to compare between hosts.

Run it several times. The first request pays for DNS resolution and a cold cache, and the difference between run one and run five is itself informative. Then run it against a page that hits the database rather than a static file, because a cached homepage tells you very little about the platform under load.

If a host offers a trial or a short money-back window, use it to test the thing you actually care about: import a real database, load a real page, and check TTFB from the region your visitors live in.

Cheap wins after you have chosen

Whatever tier you land on, a few things are worth doing on day one:

• Confirm OPcache is enabled. A phpinfo() page or php -i | grep opcache.enable answers it in seconds.
• Set cache headers on your static assets. This is the highest-leverage change available on any host, and it does not require their cooperation beyond letting you set headers.
• Turn on compression for text responses.
• Confirm HTTP/2 is actually in use: curl -sI --http2 https://example.com | head -n 1 should show HTTP/2.

On Apache or LiteSpeed all of that lives in .htaccess, and our .htaccess generator will assemble the cache, compression, and HTTPS blocks with the module guards already in place. On nginx none of it applies — the file is read by nobody — and you will need the equivalent in a server block, which typically means either root access or a support ticket.

The short version

Pick the tier that matches who is willing to operate the server, not the tier with the best marketing. Then compare the seven specs above rather than the feature checklist, read the renewal price instead of the promotional one, and measure TTFB from where your users are before you commit to a year.