Most WordPress sites are slow for structural reasons, and a plugin rarely fixes them. The time goes into four layers: the server and hosting, the database, render-blocking CSS and JavaScript, and third-party scripts. Performance conversations usually start with a score instead. Someone runs PageSpeed Insights, sees a red number and asks for a plugin that turns it green. The score is a symptom. The cause almost always sits in one of those four layers, and no plugin reaches all of them. So I fix the structure first, in order, and then prove the result with field data.
Where the time goes
Open the network panel on a slow WordPress page and read it from the top. The first row, the HTML document, already tells you half the story. If time to first byte is above 600 ms, the server is doing too much work on every request. Usually there is no page cache, the database has grown without indexes, or a plugin runs expensive queries on each load.
Next come the CSS and JavaScript rows. Themes and page builders ship everything on every page, and the browser cannot paint until the render-blocking files arrive. After that you get images, fonts and third-party scripts: analytics, chat widgets, ad tags. Each one is small on its own. Together they push Largest Contentful Paint past the 2.5 s threshold and keep the main thread busy long after the page looks ready.
A fast WordPress site is not a site with fewer features. It is a site where every byte has a reason to be on this page.
Diagnose with field data first
A lab tool runs one test on one device from one location. Your users do not browse like that. Start with the Chrome UX Report (CrUX) for your origin and your key URLs. It shows the 75th percentile of LCP, INP and CLS across real visitors over 28 days. If the field data is good and the lab score is bad, you have a reporting problem, not a performance problem. If both are bad, the field data tells you which metric and which pages to fix first. This is roughly how I read it:
- Time to first byte above 600 ms: server, caching and database.
- LCP above 2.5 s with a fast TTFB: render-blocking CSS/JS, hero image or fonts.
- INP above 200 ms: JavaScript on the main thread, usually third parties and builders.
- CLS above 0.1: images without dimensions, late-loading fonts, injected banners.
Fix in order, measure after each step
Order matters because each layer hides the one below it. Get page caching and object caching working first, so the server stops being the bottleneck. Then deal with render-blocking assets: load CSS per template, defer non-critical JavaScript, and preload the hero image and the two font files you actually use. Only then look at third-party scripts, and be ready to remove the ones nobody can defend.
Ship each change on staging, compare lab results before and after, and then wait. Field data needs two to four weeks to reflect a change, so don’t judge a fix by a single lab run on the day you deploy it.
What good looks like
For a content site on decent hosting, I aim for TTFB under 200 ms from cache, LCP around 1.5 s on mobile, INP under 150 ms and CLS at zero. WooCommerce gets more room on cart and checkout, but the catalogue pages should hit the same numbers. Once you are there, the PageSpeed score takes care of itself.