How to Test Page Speed Before You Switch Hosts

To test page speed before switching hosts, you must measure the new host from the outside, under realistic conditions, and compare it to your current setup using the same methodology. The goal is not to find the fastest number on a synthetic dashboard, but to understand how the host's network, server stack, and configuration will behave for your specific visitors, so run these tests from multiple vantage points and at different times of day.

Why a Simple Ping Is Not Enough

A ping measures round-trip time to the server, but it tells you nothing about how quickly the server can generate and deliver a full page. The bottleneck is almost never the network hop itself; it is the time the server spends processing PHP, querying a database, and assembling the response. You need to measure time to first byte (TTFB) and total download time for a real document, not just an ICMP echo. The most direct tool for this is curl, which lets you see the exact headers and timing breakdown for any URL.

curl -s -o /dev/null -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com

Run that against your current host and the prospective host, using the same URL structure (for example, a homepage and a typical article page). Look at the TTFB value first. If the new host shows a TTFB above 500 milliseconds for a simple page, that is a warning sign, because the server side is slow before any assets are even transferred. A low TTFB, under 200 milliseconds, suggests the server is configured well, but you still need to check the total time, because that includes the download of HTML, CSS, and JavaScript.

Measure the Full Page, Not Just the Document

Modern pages are composed of dozens of requests. A host can serve a fast HTML document but then deliver static assets from a slow disk or a misconfigured CDN, which ruins the experience. To test page speed before switching hosts properly, you need to simulate a browser. The curl command above only fetches one file. Instead, use a headless browser tool such as lighthouse or webpagetest, which you can run from your own machine against any public URL. These tools will give you a breakdown of server response time, render blocking resources, and time to interactive.

lighthouse https://example.com --output=json --output-path=./report.json --chrome-flags="--headless"

When you run this against the prospective host, pay attention to the server-response-time metric in the JSON output, but also to the total-byte-weight and the number of render blocking requests. A good host cannot fix a bloated page, so you need to isolate the host's contribution. Create a minimal test page on the new host: a single HTML file with no external assets, and then a simple PHP script that echoes a short string. Measure those with curl to get a clean server side number, then compare the same minimal files on your current host. This removes the variable of your application code.

Check the HTTP Headers and Compression

The server configuration makes a measurable difference. Inspect the response headers from the new host, because they reveal how the server is tuned. Use curl -I to fetch only the headers. You want to see Cache-Control, Content-Encoding: gzip or br, and Keep-Alive set properly. A host that sends no compression headers for text files is forcing larger transfers, which slows every page for every visitor.

curl -I https://example.com/minimal-test.html

Look for the Server header to see what software is running, and check whether it includes a version number, which is a security concern. More importantly, test how the server handles a request for a static file with a cache buster query string, and then request it again to see if the Age header appears, indicating a caching layer. If the host uses a reverse proxy such as Varnish or Nginx, you should see a short TTFB on repeat requests. If every request shows the same TTFB with no sign of caching, the host may be running a plain Apache setup without opcode caching, which will struggle under load.

Test Under Concurrency and From Multiple Locations

A single request from your office tells you almost nothing about how the host behaves under real traffic. You need to simulate multiple simultaneous users. Use a tool like ab (ApacheBench) or wrk to send a burst of requests to the prospective host. Be careful with this, because you do not want to trigger a denial of service protection, so keep the concurrency low, around 10 to 20 requests, and the total count under a few hundred.

ab -n 200 -c 10 https://example.com/minimal-test.html

Read the Requests per second and the Time per request lines. If the new host falls below half the throughput of your current host on the same minimal file, that is a clear red flag. But also run the test from a different network, because your local ISP may have a peering issue with the host's data center. Use a free web based speed test service that lets you choose a location, or ask a friend in another region to run the same curl command. The host's own speed test page is not trustworthy, because it often points to a cached file on a CDN that does not reflect the actual server load.

Inspect the TLS Handshake and Protocol Support

Page speed is not only about HTTP. The TLS handshake adds latency, especially for mobile visitors on slower networks. Check which TLS protocol versions the new host supports and whether it enables HTTP/2. You can use openssl to see the negotiated protocol, or simply run curl -I --http2 and look for the HTTP/2 status line. If the host only supports HTTP/1.1, that is a performance penalty for modern sites that make many parallel requests, because HTTP/1.1 limits connections per domain.

curl -I --http2 https://example.com/

Also check whether the host sends an alt-svc header for HTTP/3. That is not essential, but if you see it, the host is likely running a modern edge setup. More important is the certificate chain: a slow certificate validation can add hundreds of milliseconds. Use openssl s_client -connect example.com:443 -servername example.com and look at the time it takes to complete the handshake. A host that uses a short certificate chain with OCSP stapling will be faster than one that forces a full chain download.

What to Do Next

Run the same set of tests on your current host and the prospective host, using the same minimal files and the same test times, then compare the numbers side by side. If the new host is consistently within 20 percent of your current host on TTFB and total time, the difference will be imperceptible to your visitors. If it is slower, ask the host's sales or support team for the specific server configuration, such as whether they use Nginx with PHP-FPM and opcache, and whether they offer a staging environment where you can run the same tests before paying. Only after you have verified the numbers from at least three locations should you make the switch, and keep the old host running for a week so you can compare real traffic analytics after the move.