Measure a slow WordPress workflow before changing settings so you can identify the actual bottleneck and judge whether a change improves it. A single score does not describe the whole website: public pages, logged-in administration, search and checkout can behave very differently.
IN THIS ARTICLE
01 Define a representative test
Select a small set of important URLs and actions. Record the device, connection, visitor location, login state and whether the cache is warm or cold. Note the time and any simultaneous jobs or traffic spikes. Use the same conditions for comparisons so a faster result is not merely a different test environment.
02 Gather a baseline
- Load the page in a clean browser session and note when its useful content appears and when it becomes responsive.
- Use browser developer tools to inspect the document response time, large assets, failed requests and external domains.
- Run a suitable performance test and distinguish laboratory results from real-user field data when available.
- Check hosting resource usage and WordPress errors around the same timestamp.
- Repeat a small number of comparable tests and keep the results before changing anything.
03 Example: record comparable network timings for one public page
Measure a small number of requests to the same public URL before changing caching or plugins. This curl request downloads the document but discards its body, then prints timing fields. It does not measure page rendering or JavaScript responsiveness in a browser.
curl --silent --show-error --output /dev/null \
--connect-timeout 3 --max-time 20 \
--write-out 'DNS=%{time_namelookup}s CONNECT=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n' \
'https://example.com/services/'The timings are cumulative milestones from the request start, so do not add them together. Record location, login state, cache state and timestamp with the result. A slow first byte can include proxy and network effects as well as origin work; compare it with browser and hosting evidence.
Expected result: The before-and-after comparison uses the same conditions and URL. A faster document response is accepted alongside working forms, stable layout and the browser’s actual user experience.
What does a slow first response suggest?
Investigate server-side processing, cache misses, database work and external requests performed before the page response. This is different from a page that responds quickly but spends several seconds downloading images or executing scripts. Separate these cases before installing another optimisation plugin.
Why do two speed tools disagree?
They may use different locations, devices, network simulations, cache states and scoring rules. Real-user metrics may cover a historical period rather than the latest deployment. Compare like with like and use the tools to identify actionable delays, not to chase one number without checking the actual customer experience.
04 Change one cause and verify business functions
Test the proposed change on staging, then compare the same live measurements after deployment. Record both the improvement and any side effects. Asset deferral, cache rules and script removal can break navigation, forms or checkout even when the score improves. Keep a reversible change record and prioritise visible responsiveness, stable layout and working customer journeys. If the delay remains unexplained, send support the URLs, timestamps, test conditions and relevant errors rather than only a screenshot of a score.