How to choose a web host: compare measured speed, not reviews

To choose a web host, decide three things in order: where the server should be (near most of your visitors), what kind of plan your site needs (shared, managed or a VPS), and which of two or three candidates is actually fastest for your site, which you find out by measuring your own pages on each during the trial, not by reading reviews. The number to compare is time to first byte (TTFB), cached and uncached, because it is the part of page speed the host owns. The pillar guide, TTFB: what it is and what is good, explains what goes into that number.

Hosting reviews are usually written by people paid per sign-up, with benchmarks run on an empty site. This guide shows how to measure hosts fairly and how to decide between shared hosting and a VPS. The examples use WordPress, but the method works for any server-rendered site.

Quick answer

• Location first: the data centre closest to most of your visitors (your analytics has the country split).
• Plan type by site: brochure sites and blogs are fine on good shared hosting with a server-level page cache; shops and membership sites need fast uncached pages, so managed hosting with an object cache or a VPS someone maintains.
• Measure your real site on each candidate during the trial or money-back period: three runs per page, cached and uncached, same time of day.
• Targets: a cached page under 200 ms from a nearby location; uncached under 500 ms on a good managed host. The report rates field TTFB good at 800 ms or less.
• Check real customers: the Core Web Vitals history of sites already on that host shows their field TTFB over 40 weeks.
• Price last: "unlimited" plans ration CPU and PHP workers instead of storage.

Why TTFB is the host's number

Before the first byte arrives, nothing of yours has run in the browser. The time goes to DNS, the TCP connection and TLS handshake (distance and the host's network), and the server's own work: handing back a cached HTML file in a few milliseconds, or starting PHP, loading WordPress, the theme and every plugin, querying the database and building the page. On a shared server that last part includes waiting for a CPU slot.

Your theme and plugins decide how expensive the uncached build is; the host decides the CPU, the database speed, the server-level cache and the distance. That is why the same site moved between hosts can go from 900 ms to 250 ms with no setting changed.

Shared hosting vs VPS vs managed hosting

The plan type decides more than the brand. Match it to how your site is used:

Shared hosting vs VPS comes down to uncached traffic and time. If almost every view is a cached page, a good shared host is enough and the difference goes on the theme. If most views are personal (cart, checkout, account, search), you are buying uncached speed, and a VPS gives the most of it per euro. The catch is that updates, backups, PHP tuning and the night the disk fills up are yours, unless you add a server panel such as RunCloud, SpinupWP or Ploi, or pick managed hosting instead.

How getReport checks it

The test fetches the page from Frankfurt with a fresh connection, as a first-time visitor would, and records the time to the first byte of the final response plus every redirect hop. The speed module adds Lighthouse's server response time from its throttled run, and the field TTFB from Chrome users when the site has enough traffic to be in the Chrome UX Report.

The lab number is one request from one place; the field number is the 75th percentile of real visitors on their own networks, including their distance from the host. When the lab number is fine and the field number is not, the host is far from your audience. When both are slow, the server is slow.

Step 1: know whether you are measuring cached or uncached

Every serious WordPress host serves a page cache, at the server (LiteSpeed, nginx FastCGI cache, Varnish) or through a plugin. A cached hit tells you about the host's network and web server; a miss tells you about its CPU and database. You need both, because logged-in users, the checkout, search results and the first visit after every edit are misses.

To force a miss, add a query string with a new value on every run, such as https://example.com/?nocache=1027. Most page caches either skip URLs with unknown parameters or store them as a separate page, so the first request is built from scratch. Some hosts strip unknown parameters; then measure while logged in, in the browser's DevTools Network tab. Run the TTFB test on both URLs three times each and keep the median. A cached hit under 200 ms with a miss over 1.5 s is a typical shared host; the same miss under 500 ms is what you pay a managed host for.

Step 2: put the same site on each candidate

Benchmarks on a demo site or a fresh install prove nothing: a blank WordPress builds in 50 ms anywhere. Use the trial or money-back period and move a copy of your real site with the host's migration tool or a plugin such as Duplicator. Use the temporary domain every host gives you, so DNS does not change and the live site stays where it is.

On each copy, test the same pages: the home page, your heaviest category or archive, and one product or post. Same time of day, three runs each, cached and uncached. Fill in the table:

Keep the report links; they are the evidence when someone asks why you chose.

Step 3: read the field data of sites already on the host

Your copy has no visitors, so it has no field data. Real customer sites do. Find a few from the host's showcase, from agencies that name their host, or from response headers that name the platform (such as x-kinsta-cache or x-litespeed-cache, visible in the report's technical detail). Run the Core Web Vitals history on three or four of them: the TTFB line at the 75th percentile over up to 40 weeks is what real people experienced on that infrastructure, with themes and plugins as messy as yours. A host whose customer sites all sit at 400-600 ms is not going to give you 150 ms. Only sites with enough Chrome traffic are in the dataset, so pick bigger ones.

The hosting speed check adds a second view: it names the network and managed host behind any site and, once getReport has checked 50 sites on that host, shows their median and slowest-quarter first byte next to yours. Field data vs lab data explains why the numbers differ and which to trust when.

Step 4: read the rest of the report

A full report on your test copy shows what else the host provides:

• HTTP/2 and HTTP/3: which protocol the page negotiated and whether HTTP/3 is advertised. HTTP/1.1 only, in 2026, means an old stack.
• Compression: text compressed with Brotli or gzip, or not at all.
• Cache headers on static files: managed hosts usually set long lifetimes on CSS, JS and images; on shared hosting you may have to set them yourself.
• TLS: 1.2 at minimum, ideally 1.3.
• Redirect hops: a host that adds its own redirect has added a round trip to every first visit.

Step 5: discount for distance

The test runs from Frankfurt. A host in Virginia looks about 100 ms slower from there than it is for a visitor in Chicago, and a host in Frankfurt looks faster than it will be for that visitor. Judge each host from where your visitors are. A CDN fixes distance for static files and cached pages only: the checkout, search and logged-in views still travel to the origin. A CDN in front of a slow origin shows a fast cached TTFB and a slow uncached one, which your table already separates. What a CDN is and what it fixes covers the details.

Platform notes

• Managed WordPress hosts: the page cache sits at the server and usually cannot be turned off, so query strings may be stripped; log in to measure the miss. Many cap PHP workers per plan, which shows as uncached TTFB rising with concurrent visitors. Ask for the worker count.
• Shared cPanel hosting: look for the server: LiteSpeed header. LiteSpeed's server cache with the LiteSpeed Cache plugin is the fastest thing a cheap plan offers.

Once the choice is made, the site migration checklist covers the move without losing rankings.

How to verify

• The table has cached and uncached medians for the same three pages on each host, measured from the same place in the same week.
• The field TTFB of at least three real sites per host is filled in, or marked "not in CrUX".

Common mistakes

• Comparing a cached hit on one host with a miss on the other. Both numbers, both hosts, same pages.
• Trusting the host's own benchmark. It was measured on an empty site, often from next door.
• Choosing the fastest host from Frankfurt for visitors in Sydney. Distance is TTFB you cannot configure away.
• Migrating before measuring. Measure on the trial domain first; the migration only needs doing once.

Questions people ask

How do I choose a web host?

Choose by location, plan type and measured speed. Pick a data centre near most of your visitors, match the plan to your site (shared for brochure sites, managed or a VPS for shops), then compare cached and uncached TTFB of your real site on two or three candidates during their trial. Check what is included: page cache, object cache, current PHP, HTTP/2 and HTTP/3, backups and support. Price comes last.

Is shared hosting or a VPS better for my website?

Shared hosting is enough when most visits hit cached pages, as on brochure sites and blogs: with a server-level cache they answer in under 300 ms. A VPS is better when many visits are uncached, such as carts, checkouts and member areas, because its CPU is not shared. It also makes you responsible for updates, security and backups, so choose managed hosting if nobody will look after the server.

What is the fastest web hosting for WordPress?

There is no single fastest host, only the fastest one for your site and your visitors. Hosts with a server-level page cache, a current PHP version, an object cache such as Redis and a data centre near your audience usually serve cached pages in under 200 ms. Put a copy of your own site on two or three candidates during their trials and compare cached and uncached TTFB.

Is managed WordPress hosting worth it?

It is worth it when your time costs more than the price difference. Managed hosts include a server-level page cache, automatic updates, daily backups, staging sites and support that knows WordPress, and they are often faster than shared plans out of the box. For a small brochure site on a good shared host with a caching plugin the gain may be small, so measure TTFB on both before deciding.

Should the data centre be near my visitors or near me?

Near your visitors. Every uncached request makes several round trips to the server before the page starts to arrive, and each one gets longer the further away the server is. Check where your traffic comes from in your analytics and pick the host's data centre closest to most of it. Where you or your team sit does not matter for speed.

How long should I test a host before deciding?

At least a few days, covering busy and quiet hours. Shared servers vary with their neighbours' load, so one good afternoon proves little. Run cached and uncached TTFB tests two or three times a day on the same pages, write the numbers down and compare the medians and the slowest results. Most hosts offer a trial or a money-back period long enough for this.

Does changing web host affect SEO?

Not if the URLs stay the same and the site stays up. Google treats a host move without URL changes as routine; crawling may slow briefly while Googlebot learns the new server's capacity. Lower the DNS TTL a few days before, keep the old host running until DNS has switched everywhere, and check that the new server returns the same pages, status codes and robots.txt. A faster host can improve Core Web Vitals.