WordPress performance debugging checklist

A slow WordPress site is rarely slow for a mysterious reason. In almost every case we are called to, the cause is one of five things, and the fastest way to the answer is to check them in order instead of buying a bigger server.

Measure before you touch anything. Load the page with the browser devtools open and note two numbers: the time to the first byte and the time to the largest element. A slow first byte is a server problem — PHP, the database, a remote API. A fast first byte with a slow page is a front-end problem — images, fonts, scripts. These two paths share almost no fixes, so guessing wrong costs a day.

If the server is slow, install Query Monitor and read the page you are debugging. It shows the number of queries, the slowest one, the HTTP requests made during rendering and which plugin issued them. The usual culprits:
— a plugin calling an external API on every page load with no cache and no timeout;
— a query on a meta field with no index, on a table with hundreds of thousands of rows;
— autoloaded options that have grown to several megabytes;
— a theme running `wp_query` in a loop instead of one query with `post__in`.

Test your caching, do not assume it. Full-page cache in front of PHP is the single biggest win a content site can have, and a plugin's configuration screen is not evidence that it works. Request a page twice and read the response headers; if nothing tells you the cache was hit, it was not. Watch out for the two classic cache killers: a cookie set on every visit, and a query string appended by an ad platform.

On the front end, the wins are boring and reliable: serve images in WebP at the size they are displayed, set explicit width and height, lazy-load everything below the fold, self-host fonts and preload only the one you use above the fold. A hero image exported at 4000 pixels wide costs more than every plugin on the page combined.

Check the hosting last, when you already know what the application does. Object caching with Redis helps a site that runs many small queries; more CPU helps a site that runs heavy PHP; neither helps a site that waits on someone else's API.

Then write the result down: what was slow, what changed, what the numbers are now. Performance work that is not measured tends to be undone by the next plugin update.