Slow WordPress sites are rarely mysterious. The same culprits appear again and again: render-blocking scripts, oversized images, plugins injecting assets on pages that never use them, database bloat, and hosting that cannot serve a uncached page in under a second. Caching layers are still worth having — but a cache over a slow page is a fast slow page.
Measure first, from the right place
Field data (real user metrics, where volume allows) shows the truth; lab tools show it in a form you can debug. The discipline is measuring the same URLs with the same tool before and after, so the improvement is a fact rather than a feeling. LCP, INP and CLS each point at a different class of problem, and each class has a different fix.
The usual suspects, in order of payoff
First: asset behaviour. Themes and plugins enqueue CSS and JavaScript globally when they are needed on one page. Unloading them where they do nothing is often the single largest win. Second: images — modern formats, correct intrinsic sizes, lazy loading below the fold. Third: the database — autoloaded options and expired transients that grow quietly for years. Fourth: hosting, which you should only pay to change after the software causes are fixed.
Keep the win
Performance regresses because nobody watches it. The fix is a monitoring threshold with an alert, plus a rule that new plugins get audited for the assets they inject. Speed is not a project; it is a property you maintain.
