Choosing web hosting for speed: what to look for

Shared, VPS, managed WordPress, cloud and static hosting compared for speed, what really decides server response time, and how to test a host.

In this guide

Why hosting comes first
The main kinds of hosting
What actually decides server speed
Match the hosting to the site
How to test a host before you commit
Questions to ask a host
Moving without breaking things
When a host is not the problem
Check your own page
Sources

Why hosting comes first

Before a browser can show anything, it needs the first byte of the page from your server. How long that takes depends on where the server is, how much work it does for each visit, how powerful it is, and whether it can hand back a saved copy instead. All of the front-end work in the rest of this series starts after that moment. Google's own guidance on speeding up the first byte puts hosting first: before other approaches, make sure the host can handle the traffic you send it.

A quick check: Lighthouse 13 marks the server response of your page as slow when the server takes more than 600 milliseconds to start answering. If your page cannot pass that test even with a cache, the server is the limit and no amount of image compression will fix it. The time to first byte guide shows how to measure it, and how to reduce server response time shows what to fix before you move.

The main kinds of hosting

Type	What it is	Speed	Control	Good for
Shared	Many sites on one server, sharing its resources	Generally the slowest and the least predictable	Little	Small, mostly static sites
Managed WordPress or store hosting	Shared or dedicated resources tuned for one platform, with caching built in	Good to very good, depending on the plan	Limited by the host's rules	Business sites and stores that want it handled for them
VPS (virtual private server)	A guaranteed slice of a server that you or a provider manages	Good, if configured well	High	Sites that need their own settings
Dedicated server	A whole machine for your site	Very good, if managed well	Full	Large sites with heavy, steady traffic
Cloud or platform hosting	Resources rented by the hour, often in many regions	Very good, scalable	High	Applications and sites with changing traffic
Static or edge hosting	Pre-built pages served from a CDN	The fastest first byte	Limited to what can be pre-built	Sites that do not need a database for every visit
Hosted builders (Wix, Squarespace, Shopify)	Hosting included in the platform	Decided by the platform	None over the server	Owners who want no server to manage

Two cautions about the table. First, the words do not guarantee anything: a cheap "VPS" can be slower than a well-run shared plan, and one provider's shared plan can beat another's. Second, "managed" covers a wide range. Some managed hosts configure a page cache, an object cache, a current PHP version and a CDN for you; others add a dashboard to a plain server.

What actually decides server speed

When a page is slow to start, these are the usual reasons. They are what to compare between hosts.

Power and sharing. How much processor time and memory your site is allowed, and how many other sites compete for it. If an application has too little memory it struggles to serve pages quickly.
Concurrency. How many visitors can be served at the same moment. A site that is fast for one visitor and slow when ten arrive is short of workers, which is common on small plans for sites that run PHP.
Caching. Whether the host provides a page cache and an object cache, so that most requests never reach the database. This is often a bigger difference than raw power. See caching explained.
Software versions. A host that keeps the language runtime, the database and the web server up to date gives you the performance improvements that come with each release. For PHP sites, a current, supported PHP version matters, and so does having the opcode cache switched on.
Storage and database speed. Fast disks and a well-set-up database make every dynamic page cheaper.
Network and protocols. Modern hosts and CDNs offer HTTP/2 and HTTP/3 and TLS 1.3, which shorten the connection steps before the first byte. See HTTP/2 and HTTP/3 and HTTPS and TLS speed.
Location. A server far from your visitors adds delay to every request, for a reason physics will not let anyone fix. Host near your visitors or put a CDN in front (see what a CDN does).
Background jobs. Backups, scans and scheduled tasks that run at busy hours slow the site for everyone.

Match the hosting to the site

Your site	A sensible starting point
A brochure site of a few pages that rarely changes	A static or edge host, or a small managed plan with a CDN
A WordPress business site	A managed WordPress plan, or a VPS with a page cache and an object cache
An online store	A plan built for stores, or a VPS or cloud setup with object caching, because carts and checkouts cannot be cached whole
A site with a lot of traffic or large spikes	Cloud hosting with a CDN in front, and a page cache
A site for visitors on several continents	Any of the above plus a CDN, so that every visitor is near a copy
An application with logins and live data	Cloud or VPS with an object cache and a CDN for the static files

How to test a host before you commit

Sales pages describe features. Measurements describe results. Before you move, or when you are choosing, test:

Measure the first byte from where your visitors are. Run the page through a test that can choose a location, or ask someone in your market to check. Compare the same page across hosts.
Test cached and uncached. The first view after a purge shows what the server can do alone. Later views show what the cache does. You need both numbers.
Use your own site, not a demo. Ask for a trial or a staging copy of your real site. A demo page proves nothing about your database and plugins.
Test at a busy hour. The slowest time is the one that matters.
Look at the protocol. In Chrome DevTools, the Network panel can show the protocol column, where h2 is HTTP/2 and h3 is HTTP/3.
Check public data. For some platforms, projects publish real-user response times by host. Treat them as a hint, because they depend on the sites that are on the host.

Questions to ask a host

Which PHP version (or other runtime) can I run, and how soon do you add new ones?
How much memory and how many workers does my plan include?
Do you offer a page cache and an object cache, and are they on by default?
Is there a CDN included, and does it cache HTML?
Where are the servers, and can I choose?
What runs on the server at busy hours: backups, scans?
Can I test a copy of my site before I switch?
What happens when traffic spikes: does the site slow down, or do you scale?

Moving without breaking things

Copy the site to the new host and test it there, using the host's temporary address or a change to your own computer's hosts file.
Lower the DNS lifetime (TTL) a day or two before the switch, so that the change spreads quickly.
Switch the DNS records, keeping email records intact.
Check the certificate, the redirects and the main pages.
Keep the old host running for a few days in case of surprises.
Watch the first byte and Search Console for a few weeks.

When a host is not the problem

If the first byte is fine and the page is still slow, look elsewhere. A new host will not fix a large image, a render-blocking script or a heavy theme. Check the LCP breakdown before you move: if the first byte is a small part of the total, hosting is not where the time goes.

Check your own page

Run the free audit and look at the server response time for your page. If it is high with a cache in place, the host is the limit. If it is low, spend your effort elsewhere.

Sources

Optimize Time to First Byte on web.dev: hosting, CDNs and caching, and what to ask of a host.
Time to First Byte (TTFB) on web.dev: what the first wait is made of.
Evolution of HTTP on MDN: HTTP/1.1, HTTP/2 and HTTP/3.