Diagnosing a slow WordPress site, in order of payoff

Unoptimized images show as a slow LCP on a photo-heavy page, and are fixed by correct sizing and modern formats. Plugin count shows as slow INP and a heavy main thread, and is fixed by removing rather than replacing. Theme weight shows as render-blocking CSS and JS, and is fixed by a lighter theme or a rebuild. Hosting shows as slow server response under load. The database shows as a slow admin and slow archives, fixed by cleanup, indexes and caching.

Start at the top and measure between steps. The project's own guidance covers the surface, and the deeper performance reference goes further. The thresholds to measure against are in Web Vitals, with optimizing INP for cause two, which is, in our experience, the one WordPress sites fail and the one speed plugins do not touch.

A caching plugin is not a fix for causes one to three. It makes a heavy page heavy-and-cached. The plugin count that caused the problem does not shrink because a cache sits in front of it.

And a lab score is not the measurement. Field data at the 75th percentile is what the thresholds are defined against, which is why a perfect synthetic score and a failing Core Web Vitals report are not a contradiction. On a low-traffic local site there may be no field data at all — in which case use lab data at the same thresholds and label it as lab.

When it is not fixable in place: when causes three and four dominate and the theme is the architecture. That is a rebuild decision, not a speed decision.