Most advice on how to choose web hosting starts with price and storage. For speed, start somewhere else: hosting is the one part of website speed that design and front-end work can’t make up for. If the server takes a second and a half to start sending a page, every image, font and script waits behind it. Equally, a premium host won’t rescue a page weighed down by oversized images and a dozen marketing tags.
So the job isn’t finding “the fastest host”. It’s matching the hosting type to your site, checking the few things that decide how quickly a server responds, and testing whether your current host really is the bottleneck. No rankings or affiliate picks: hosts change too often for a list to stay true.
The short answer
- Match the hosting type to the site. For a typical WordPress business website, good managed WordPress hosting or a managed VPS is the sensible default. The cheapest shared plans are a common cause of slow sites.
- Check the stack, not the marketing: a supported PHP version, HTTP/2 or HTTP/3, server-level page caching and guaranteed CPU and memory.
- Host close to your visitors, and add a CDN if they are spread across regions.
- Measure time to first byte (TTFB). web.dev rates 0.8 seconds or less as good. If real visitors regularly wait longer, the hosting is likely part of the problem.
- Own the account, in your business’s name, with backups you have actually restored.
What hosting controls, and what it doesn’t
Every page view starts with a request to your server, which builds the page (on WordPress, with PHP and database queries) and sends back the HTML. The time until its first byte arrives is TTFB. It includes looking up the domain and opening a secure connection as well as the server’s own work, so distance matters as well as power.
Hosting decides most of that window through the server’s resources, its software stack, its caching and its location. It doesn’t control what happens after the HTML arrives: images, scripts, fonts and third-party tags.
TTFB isn’t a Core Web Vital, but it eats into one. Largest Contentful Paint is timed from the moment the visitor starts loading the page, so a server that takes a second to respond has already used two-fifths of Google’s 2.5-second “good” threshold. Core Web Vitals explained covers the metrics, and the website speed optimisation guide shows where hosting sits in the whole performance stack.
Shared, VPS, cloud and managed WordPress hosting compared
Hosts use these labels loosely, so judge a plan by what it includes rather than what it’s called.
Shared hosting
Many websites share one server’s CPU, memory and disk, and the host looks after it. It is the cheapest, simplest option.
The catch is contention: when a neighbouring site gets busy, yours can slow down, and plans cap what each account may use, not always visibly. Good shared hosting suits a small, well-cached brochure site. The trouble is the bottom of the market, where plans are often cheap because servers are crowded.
VPS (virtual private server)
A VPS divides a physical machine into virtual servers, each with its own allocation of CPU and memory, so busy neighbours affect you far less and the server can be configured for your site.
That freedom comes with responsibility. On an unmanaged VPS, someone has to tune the stack, apply security updates, set up backups and watch it. If nobody on your side will, choose a managed VPS. An unpatched server is only fast until it is compromised.
Cloud hosting
“Cloud” can mean a platform where you rent servers and databases by usage, or just a host’s name for a VPS. The real thing scales quickly and can spread a site across regions, which suits sharp traffic peaks or strict availability needs. For a typical business website it mostly adds cost and complexity, not speed.
Managed WordPress hosting
The host runs a stack built for WordPress, usually with server-level caching, automatic backups, staging sites and WordPress-aware support. Read the limits: plans are often priced by visits or storage, and some hosts block plugins that clash with their caching.
Side by side
| At a glance | Shared | VPS | Cloud | Managed WordPress |
|---|---|---|---|---|
| Resources | Shared, often capped | Allocated to you | Scale on demand | Depends on plan |
| Who runs the server | The host | You, unless managed | You or a specialist | The host |
| Page caching | Sometimes | Only if set up | Only if set up | Usually built in |
| Main risk | Slow at busy times | Nobody patching it | Cost and complexity | Plan limits |
| Best for | Small, low-traffic sites | Sites with someone to run them | Heavy or spiky traffic | Most WordPress business sites |
Managed WordPress hosting vs shared hosting: the speed difference comes less from hardware than from the caching, tuning and responsibility included. Shared hosting vs VPS: a VPS reduces contention, but only helps if someone configures and maintains it.
Is hosting your bottleneck? Test it with time to first byte
Check before you move: a new host won’t fix a 3 MB hero image. Why is my website slow? covers the full diagnosis; these checks focus on the server.
1. Start with real-visitor data
Run a key page through PageSpeed Insights. When Google has enough real-user data, the field section reports TTFB alongside the Core Web Vitals. How to read PageSpeed Insights explains why field and lab results differ.
2. Measure cached and uncached pages separately
This is the check most people skip. A cached page is served ready-made, so its TTFB mostly reflects distance. An uncached page is built by PHP and the database, so it shows what the server can really do. Time the first byte from a terminal, a few times:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://www.example.com/
Then repeat with a query string nobody has requested before (?nocache=1, then ?nocache=2), which usually forces a fresh build. Many caches add a response header reporting HIT or MISS; curl -sI plus the address shows it.
3. Test from where your customers are, and over time
A terminal only measures from where you sit, so use WebPageTest to run the same page from near the server and from near your customers. Then open the Crawl stats report under Settings in Google Search Console: it charts the average response time for what Googlebot fetches and flags host availability problems. A rising trend, or spikes on your busiest days, suggests a server struggling under load.
Reading the results
| What you see | What it usually means |
|---|---|
| Cached fast, uncached slow | Caching hides a weak server. Search, baskets, forms and logged-in areas still feel it |
| Everything slow | No effective page caching, or an underpowered server |
| Fast nearby, slow far away | Distance. A closer data centre or a CDN beats a bigger plan |
| Slow only at busy times | Resource limits or a crowded shared server |
| Fast TTFB, slow LCP | Not hosting. Look at images, scripts and fonts |
| Sluggish WordPress dashboard | The admin area bypasses the page cache, so it exposes raw server speed or heavy plugins |
How to choose web hosting: what to check before you pay
Ask for each of these in writing. A good host answers quickly and specifically.
Resources you can count on
Ask how much CPU and memory the plan guarantees, not how much storage is “unlimited”. On WordPress hosts, ask about PHP workers: how many uncached requests the server handles at once. When they run out, visitors queue.
A current PHP version you control
Newer PHP versions are often faster, and only supported versions still get security fixes. Check the host offers versions php.net lists as supported, keeps OPcache on (it saves compiled PHP between requests), and lets you switch version yourself so you can test upgrades on staging first.
Modern protocols and compression
HTTP/2 fetches many files over one connection; HTTP/3 runs over QUIC, which copes better with patchy mobile networks. Look for TLS 1.3 and Brotli or gzip compression too.
Check it yourself. In Chrome DevTools, open the Network panel, right-click a column header and enable Protocol. You want h2 or h3, not http/1.1.
Caching at the server
Server-level page caching is often faster and more dependable than a plugin alone, and an object cache such as Redis helps pages that can’t be fully cached. Ask what the host provides, what it excludes and how you clear it. Website caching and CDNs explained covers each layer.
Hosting location, and a CDN for spread-out visitors
Choose a data centre near most of your visitors. Before the first byte arrives, a browser needs several round trips to the server to connect, agree encryption and send the request, and each takes longer the further away the server is. If customers are spread across countries, a CDN serves cached copies from near each of them.
Backups, uptime and support
Look for daily off-server backups kept for weeks, not days, and restores you can run yourself. Test one on a staging copy, and keep an independent copy of your own; the WordPress security guide explains why.
A 99.9% uptime promise still allows around 43 minutes of downtime in a 30-day month, and a missed target usually earns service credits, not compensation for lost enquiries, so run your own monitoring. Before you commit, ask support something technical, such as what their page cache excludes. The answer previews the help you’ll get when something breaks.
Price it over three years. The gap between a crowded shared plan and good managed hosting is often small next to the build cost and the enquiries a slow site loses. The three-year worksheet in website pricing models puts it in proportion.
Put the hosting account in your business’s name
Hosting is often bought by whoever builds the site, on their account, bundled into a monthly fee. That works until the relationship ends, the card on file expires or the one person with the login leaves.
This isn’t about distrust. Owning the account lets you change provider without asking permission, and moving your website to a new host can then be done without downtime or lost email.
Frequently asked questions
What is the best hosting for website speed?
There isn’t one for everyone. The fastest host for your site is close to your visitors, runs a current, well-tuned stack with server-level caching, and guarantees enough resources for your traffic. For most WordPress business sites, that points to good managed WordPress hosting or a well-run managed VPS.
Will a CDN make up for slow hosting?
Partly. A CDN serves cached pages and files from near your visitors, hiding a slow server for anything it can cache. Anything personal or built on demand, such as search results, baskets and account pages, still comes from your server.
Does server location affect SEO?
Only slightly. Google’s documentation calls server location a possible hint about a site’s audience, but not a definitive signal, because many sites use CDNs or host in another country. Speed and reliability for visitors and Googlebot matter more. To reach people in different countries and languages, use a clear multilingual structure with hreflang, which works wherever the server is.
Choosing hosting as part of the build
Pick the hosting type that suits the site and whoever will look after it, check the stack and support before you pay, measure TTFB before blaming the server, and keep the account in your name.
On a new website, decide hosting with the build, not after it: the CMS, theme, caching and server have to suit each other. When we design and build a WordPress website, the hosting sits in your business’s account and you get full admin access at handover. If your current site is slow and you can’t tell whether the server or the pages are to blame, start with a free website audit, or tell us what your website needs.