“The site is slow” is not something you can act on. Whether the time goes into the server building the response, the transfer, or the browser painting the screen decides which files you open — and they have nothing in common. WordPress is perfectly capable in all three segments; sites get slow when one of them has been left unattended.
So the first thirty minutes of performance work are not spent in an editor. They are spent splitting the request into segments and collecting numbers. Skip that and you will usually improve something, but not the thing that was costing time, and the site will feel exactly the same.
Three segments
Divide the journey from request to finished screen into three parts. Each has different causes and different tools.
The simplest way to measure the first one is curl. It reports the time to the first byte only, so browser extensions and local caches cannot distort it.
curl -s -o /dev/null -w '%{time_starttransfer}n' https://example.com/If that number is small and the page still feels late, the server is not your problem. If it is large, no amount of staring at the browser waterfall will help — that is the signal to move on to the query profile in the next part.
A measurement protocol
Numbers are only comparable when the conditions are held still. Fix these five every time.
Login state is the one that slips most often. A browser logged in as an administrator is supposed to bypass the page cache, so numbers taken there are not the visitor experience. A slow admin screen and a slow public page are separate problems and usually have separate causes.
Three runs and a median is not ceremony. The first request misses the cache, the next hits it, and a noisy neighbour on the host can move the figure again. Publish “twice as fast” off a single reading and the next measurement will contradict you.
One hypothesis at a time
Once the segment is narrowed, form one hypothesis and change one thing. Change three and you will not know which one helped, nor which one to revert when the number gets worse. The smallest useful loop is split the segments, one hypothesis, one change, re-measure, record — and keeping that loop short is what sets your overall pace.
The loop ends with a record for a reason. Note the things that did not improve alongside the ones that did. A report that keeps only the flattering numbers loses credibility for all of them the first time one is challenged. “We changed this and it made no difference” is the cheapest asset you can leave the next engineer.
More on tooling and metrics lives in the performance archive, and the before/after protocol as we actually run it is published on the process page.
Next part
If server time is the culprit, queries come next. The following part is about reading a query profile — because slow queries and duplicated queries are different problems with different fixes.