Ping measures how long a small packet takes to reach a server’s network card, and that number has almost nothing to do with how fast your site feels. It never touches PHP, MySQL, the filesystem, or any of the assets a visitor actually waits for. To test hosting speed properly you measure time to first byte on a real content page with cache off and again with cache on, from more than one location, and then compare full load time against those two figures.
I have watched people cancel good hosting because ping returned 200 ms, and I have watched people keep bad hosting because it returned 18 ms. The second group usually finds out during a traffic spike, when the server has to do actual work.
The short version
- Ping is a reachability check, not a speed test. It is useful for spotting packet loss on your own line.
- Measure TTFB cold (cache off) and warm (cache on), on a real published post, never on
wp-admin. - Run every test three times and read the second and third runs. The first one is always a cold start.
- Test from at least two locations: one near your server, one near your audience.
- The gap between TTFB and full load tells you whether the problem is the server or the page.
Why ping lies
Three reasons.
It hits the wrong machine. On shared hosting your domain often resolves to a load balancer, a reverse proxy, or a CDN edge. You are pinging that front door, not the PHP worker that builds your page.
It skips the expensive part. DNS lookup, TLS handshake, PHP boot, database queries, template rendering and HTML generation all happen after the packet you measured. On a typical WordPress page that work is the bulk of the wait.
It is measured from the wrong place. Your home connection has its own latency and its own route. A 12 ms ping from your desk in Kuala Lumpur says nothing about a visitor in Manchester.
Keep ping for one job: confirming the host is reachable at all, and checking whether your own connection is dropping packets before you open a ticket.
The four numbers worth collecting
| Number | How to get it | What a bad value means |
|---|---|---|
| TTFB, cache off | Purge the cache, then load a real post once | Server-side work is slow: PHP, database, CPU or disk |
| TTFB, cache on | Reload the same URL immediately | If this is not much faster, page caching is not working |
| Full load | DevTools Network, or a WebPageTest run | Front-end problem: images, fonts, third-party scripts |
| Requests and transfer size | Network tab, look at the totals at the bottom | Uncompressed images and plugin assets nobody needed |
Those four numbers tell you more than any single score out of 100.
Run the test so the numbers mean something
- Pick a real post with text and at least one image. Not the homepage, not a contact form, never
wp-admin— admin pages are uncached by design and will always look slow. - Purge the cache first, then load the page once to get a cold TTFB. Reload immediately for the warm figure.
- Repeat three times and keep the middle numbers. Discard the first run of each session.
- Kill local variables: no VPN, no mobile tethering for the baseline, nothing else downloading. Note the hour — shared servers behave differently at 3 a.m. and at 3 p.m.
- Test from a second location before drawing conclusions. A WebPageTest node or a phone on mobile data is enough.
From a terminal, this one line gives you the breakdown without a browser:
curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://yourdomain.com/a-real-post/Read the deltas, not the absolute values. A large jump from tls to ttfb means the server spends that time building the page. A large gap from ttfb to total means the HTML itself is heavy or the connection is slow. Note that total here covers only the HTML document, not the images and scripts.
Three tools that give usable numbers
WebPageTest is the one I reach for first. It runs a real browser from a location you choose, gives you TTFB, start render and the largest contentful paint, and a filmstrip you can scrub. Run it from a node near your server and one near your audience; compare first view with repeat view to see what caching buys you.
Chrome DevTools is better for isolating one request. Open the Network tab, click the HTML document, and look at the Timing panel: the “waiting for server response” segment is your TTFB, split from DNS, connection and TLS. Throttle to Slow 4G to see something closer to a phone on a train, not a desktop on fibre.
PageSpeed Insights is the only one of the three that shows field data — what real visitors actually experienced, collected by Chrome. If the field numbers are good and the lab numbers are bad, you have a test-environment problem, not a user problem. If it is the other way round, you have a problem that only shows up under real network conditions.
If you have access to raw logs, add your host’s own timings: $request_time in nginx, %D in Apache. That is the only number measured on the server itself, and it separates slow PHP from slow network.
Reading the result: four patterns
Fast TTFB, slow full load. The host is doing its job. Your page is heavy — unoptimised images, web fonts, analytics, embeds. Fix the page, not the plan.
Slow TTFB, fast load once it starts. The server takes too long to produce HTML. Usually a missing page cache, a plugin doing database queries on every request, or a host that is oversubscribed on CPU and disk.
Slow everywhere, including ping. Network or routing, or the machine is saturated. Check with a second location before blaming the host — if both locations are slow and a plain static file is fast, it is your application.
Slow only on your connection. Your route or your ISP. Confirm by testing on mobile data; if that is fast, the host is fine and your desk is the problem.
When the host really is the problem
These are the signals that survive a fair test: TTFB swings by several times between runs at the same hour; static files are fast but every PHP page is slow; the site crawls at the same time every day, which usually means backups or a noisy neighbour; and the server reports high IO wait while your CPU allowance is throttled.
When you open a ticket, ask for specifics instead of “my site is slow”: the PHP-FPM slow log, the MySQL slow query log, your disk IO limits, and whether your account has hit a CPU or memory cap in the last 24 hours. A host that answers those four questions is worth keeping.
Before you blame the host, rule out the usual suspects on your side: a plugin that queries the database for every post in a loop, WP-Cron firing on page loads, an external font or embed that times out, or malware injecting scripts. If the slowness came with strange traffic or files you did not create, start with the five-minute infection check. If pages return errors rather than just loading slowly, the error log will tell you which one. And if you are moving hosts to fix this, take a baseline first so you can prove the move helped — the migration checklist covers that.
Five-minute checklist before you open a ticket
- Cold TTFB on a real post, written down: ______ s
- Warm TTFB on the same post: ______ s
- Full load time, with request count and transfer size: ______ s / ___ requests / ___ KB
- Same test from a second location: ______ s
- Plain static file TTFB (an image on your own domain): ______ s
If the static file is fast and the post is slow, it is your application. If both are slow from both locations, it is the server or its network — and now you have numbers to send.
Right now, open a terminal and run the curl line above three times against one real post on your site. Write the three TTFB figures down. That is your baseline, and every change you make from here gets judged against it instead of against a ping.
Leave a Reply