Disclosure: This article includes affiliate links to tested WordPress hosting providers, allowing us to earn a commission at no extra cost to you so we can remain independe
A useful WordPress speed test answers four separate questions: how quickly the server responds, how the page renders in a browser, how performance changes under concurrent traffic, and whether results are consistent over time. One PageSpeed score cannot answer all four.
Step 1: Define the decision
Decide whether you are diagnosing a slow live site, comparing hosts, validating an upgrade, or planning a campaign. Choose representative URLs: homepage, article, landing page, search, login, and safe dynamic route. A WooCommerce store must include cart and checkout sandbox behavior.
Write an acceptance budget. For example, require zero errors at 10 concurrent dynamic users, p95 server response below one second for a safe search, and good field Core Web Vitals where data exists. Thresholds should reflect the business, not an arbitrary grade.
Editor's Pick. Our team's current top recommendation for this category. (Affiliate link coming soon — we only link programs we've vetted.)
Step 2: Record the environment
Capture host, exact plan, data center, test date, WordPress and PHP versions, theme, plugins, CDN, page cache, object cache, and page bytes. Note background jobs, backups, or imports.
For comparisons, clone the same fixture. Match PHP versions and remove third-party analytics, ads, consent tools, and remote fonts. Hash or archive the fixture so later tests use identical content.
Step 3: Test DNS, connect, TLS, and TTFB
Use a tool that exposes phases, such as command-line HTTP timing, WebPageTest, or browser developer tools. DNS lookup, TCP connection, TLS negotiation, and start-transfer may be reported separately.
Send 20–30 requests from a fixed region. Report median, p75, p95, and maximum. Do not quote only the fastest. Say whether connections were reused.
Test near the server and near the audience. A distant probe measures network path as well as hosting. Warm DNS for server-focused tests but include cold browser tests for user experience.
Step 4: Identify cache HIT, MISS, and BYPASS
Inspect documented response headers or the hosting dashboard. SiteGround uses x-proxy-cache states. LiteSpeed platforms expose cache headers. Cloud/edge providers have their own identifiers.
Run three sets:
- HIT: repeated anonymous requests after cache warmup.
- MISS: purge the URL before each of at least 10 cycles.
- BYPASS: a safe intentionally uncached route or logged-in session.
Never average these together. HIT measures cache delivery; MISS and BYPASS reveal WordPress, PHP, and database work.
Step 5: Run a browser test
Use WebPageTest, PageSpeed Insights, Lighthouse, or GTmetrix with a specified location, device, and connection. Run at least three times and use the median. Preserve result links or reports.
Inspect:
| Metric | What to inspect | Good field threshold |
|---|---|---|
| LCP | Hero/text render and request priority | ≤2.5 s at p75 |
| INP | Long tasks and interaction handlers | ≤200 ms at p75 |
| CLS | Missing dimensions and injected UI | ≤0.1 at p75 |
| TTFB | Server/edge response | Context-dependent |
| Total blocking time | Lab proxy for main-thread blocking | Lower is better |
Field thresholds are from real-user data; lab tools simulate one device. Do not claim a field pass from Lighthouse alone.
Step 6: Read the waterfall
Find the initial HTML request and its wait time. Then locate the LCP resource. Check whether it starts late, is too large, or has low priority. Identify render-blocking CSS, font chains, redirects, and third-party scripts.
If HTML is slow on MISS, inspect hosting and WordPress. If HTML is fast but LCP is slow, optimize the page. If browser CPU bars show long tasks, reduce JavaScript. If layout shifts, reserve dimensions and space.
Step 7: Run a controlled load test
Use k6, Loader.io, or another tool only against a site you own and have permission to test. Prefer staging and synthetic data. Begin with one virtual user, then five and 10. Add realistic sleep time rather than an infinite request loop.
Track requests per second, median, p95, maximum, HTTP 429/5xx/timeouts, and content validity. Monitor host CPU, RAM, PHP workers, entry processes, database, and disk.
Run cached and dynamic scenarios separately. Stop when errors or sharp latency growth appears. The purpose is to find safe capacity, not crash shared infrastructure.
Step 8: Test consistency over time
Repeat small TTFB sets morning, afternoon, and night over several days. Shared hosting can vary with account density and maintenance. Cloud routing and CDN caches also vary.
Add external uptime monitoring from more than one region. Monitor an application endpoint as well as cached homepage HTML. Record DNS, TLS, timeout, 5xx, and content failures separately.
Step 9: Change one variable
Form a hypothesis: the hero is too large, page cache is missing, a plugin makes slow queries, or the server is saturated. Change one element, purge relevant caches, and repeat the same run.
Changing theme, CDN, minification, PHP version, and host at once produces no useful attribution. Keep before/after raw data and test functional behavior after optimization.
Step 10: Interpret the result
Fast HIT plus slow MISS means caching works but origin/application generation needs improvement. Fast TTFB plus poor LCP points to front-end assets. Rising BYPASS p95 with CPU or worker saturation suggests a larger plan. High latency without resource pressure may indicate external APIs or database locks.
Compare against the acceptance budget defined in Step 1. A small improvement with no user or business effect is not necessarily worth a migration.
Common mistakes
Testing only the homepage hides slow templates. Running one test rewards random variance. Testing from the wrong continent confounds origin latency. Leaving one host's CDN on while disabling another's creates an unequal comparison. Counting a 503 response as fast is a validation failure.
Browser extensions, local Wi-Fi, and logged-in cookies can change manual tests. Use clean automated environments and report configuration.
FAQ
Which speed-test tool is best?
WebPageTest offers detailed browser control and waterfalls; PageSpeed Insights combines lab and field data; GTmetrix is approachable; k6 measures controlled load. Use more than one because they answer different questions.
How many runs are enough?
Use at least three browser runs and 20–30 server-timing requests per state. More repetitions and multiple days improve confidence.
Should I clear cache before testing?
Test both. A warm HIT represents repeat anonymous traffic; purge-and-MISS and BYPASS reveal origin and dynamic performance.
Can I load-test shared hosting?
Only with permission and conservative ramps, preferably on staging. Aggressive tests can violate terms and affect other customers.
Recommendation
Measure WordPress in layers: TTFB percentiles, verified cache states, browser waterfalls, controlled dynamic load, and multi-day consistency. Keep the fixture and tool settings fixed, validate every response, and change one variable at a time. Upgrade hosting only when the evidence identifies server or resource capacity as the bottleneck.