Most WordPress speed advice is a list of twenty things to do, presented as if they're equally important.
They aren't. Two or three fixes account for the large majority of the gain on a typical site, and if you do them in the wrong order you'll spend a weekend on font optimisation while an unoptimised hero image sits there costing you three seconds.
So this is the priority order, with the measurement step first — because doing this without measuring is how people "optimise" a site into being slower.
The short version
The three metrics Google grades you on, at the 75th percentile of real visitors:
| Metric | What it measures | Good | Poor above |
|---|---|---|---|
| LCP | How fast the main content appears | Under 2.5s | 4.0s |
| INP | How fast the page responds to interaction | Under 200ms | 500ms |
| CLS | How much the layout jumps while loading | Under 0.1 | 0.25 |
The priority order:
- Measure — field data, not just lab
- Hosting and TTFB — the ceiling on everything else
- Images — usually the single biggest win
- Caching — the biggest gain per hour of effort
- Scripts and plugins — where INP lives
- Fonts and render blocking — real, but smaller
- Re-measure — honestly
Do them in that order. Steps 2 to 4 typically deliver most of the improvement.
Measure first: field data versus lab data
The distinction that trips up nearly everyone.
Lab data comes from a simulated test — Lighthouse running on a virtual device with throttled network. It's the big number at the top of PageSpeed Insights, and it's a diagnostic tool.
Field data comes from real Chrome users visiting your actual site, collected in the Chrome User Experience Report over a rolling 28-day window.
Google grades you on the field data. A perfect lab score means very little if a quarter of your real visitors on mid-range phones are having a slow time.
Two consequences worth internalising:
Your lab score will swing between tests. Different simulated conditions, different network variability. A twelve-point difference between two runs on the same page is normal and means nothing.
Field data lags by weeks. Fix something today and the 28-day rolling window won't reflect it fully for a month. Use lab data for immediate feedback while you work; judge the result on field data later. Reading the report properly.
Also note: you need enough traffic for field data to exist at all. Low-traffic pages show none, which is a data limitation rather than a verdict.
Hosting and TTFB: the ceiling
Time to First Byte is how long the server takes to start responding. Everything else happens after it, which makes it a hard ceiling on your LCP.
If your TTFB is 1.5 seconds, you have one second left to hit a 2.5-second LCP — and you'll spend it loading a single image. No amount of front-end optimisation rescues that.
What causes bad TTFB: oversold shared hosting, no server-level caching, a database bloated with revisions and transients, a distant server, or plugins running heavy queries on every request.
What to do about it:
Check it first, in PageSpeed Insights or your browser's network tab. Under 600ms is fine. Over a second, that's your project.
Consider managed WordPress hosting. This is the least popular advice in performance work because it costs money, and it's frequently the correct answer. Moving from oversold shared hosting to decent managed hosting often does more than every plugin-based optimisation combined.
Enable server-level caching if your host offers it — usually faster than any plugin equivalent.
Clean the database. Post revisions, expired transients, and orphaned metadata accumulate for years. Most caching plugins include a cleanup tool.
Images: usually the biggest single win
On most WordPress sites, images are the largest contributor to a poor LCP.
Three things, in order:
Serve WebP. Meaningfully smaller than JPEG or PNG at equivalent quality, supported everywhere current. Most caching and optimisation plugins convert automatically.
Size images to their display dimensions. The most common mistake by a distance — uploading a 4000px photograph into a container that shows it at 800px means every visitor downloads five times the data they need. It looks fine, and it quietly ruins your LCP.
Lazy-load below the fold, never above it. This is the own-goal that catches people. Your LCP element is usually the largest above-the-fold image; lazy-loading it delays exactly what the metric measures. Enable lazy loading site-wide, then explicitly exclude the hero — most plugins have that setting.
And always set width and height attributes. Without them the browser can't reserve space, so the layout jumps when the image loads. That's CLS, and it's the easiest of the three to fix.
Caching: the biggest return per hour
WordPress builds every page from scratch on every request — running PHP, querying the database, assembling HTML. Caching stores the finished result and serves that instead.
Three different jobs, often confused:
Page caching stores the complete HTML output. The big one, and what most people mean by "a caching plugin."
Object caching stores database query results in memory. Matters most on dynamic sites — membership, WooCommerce, anything where pages differ per user.
A CDN serves your static files from servers geographically near each visitor. Matters most when your audience isn't near your server.
They're complementary, not alternatives. Which to use and how they interact.
One warning: aggressive caching plugin settings — minification, combining files, deferring JavaScript — genuinely break sites. Change one setting at a time and check the site after each. The plugin that made your score jump twenty points is not helping if your contact form stopped submitting.
Scripts and plugins: where INP lives
LCP is mostly about loading. INP is mostly about JavaScript, and it's now the metric most sites struggle with.
INP measures how quickly the page responds to interactions — clicks, taps, key presses — across the whole session. Heavy JavaScript blocking the main thread is what makes a page feel laggy even after it's visually loaded.
Where the weight comes from on WordPress:
Plugins loading assets everywhere. A contact form plugin loading its scripts on every page including ones with no form. A slider plugin loading on pages with no slider.
Page builder overhead. Builders add their own CSS and JS frameworks to every page. Managing that.
Third-party scripts. Analytics, chat widgets, heatmaps, social embeds, ad scripts. Each one is someone else's JavaScript running on your main thread, and chat widgets in particular are frequent INP offenders.
What to do:
Audit what each plugin costs. Query Monitor shows you which plugins generate slow queries and load the most assets. The audit process.
Delete rather than deactivate what you don't use.
Load conditionally where possible — several optimisation plugins let you disable specific plugin assets on specific pages.
Question every third-party script. Do you genuinely use that heatmap tool, or did you install it eighteen months ago?
Fonts and render blocking
Real, and smaller than the above.
Self-host your fonts rather than loading from Google Fonts. Removes an external DNS lookup and connection, and it's now the recommended approach for privacy reasons in the EU too.
Use font-display: swap so text renders in a fallback font immediately rather than staying invisible while the webfont loads.
Subset your fonts. If you only use Latin characters, don't load Cyrillic and Greek.
Limit weights. Every weight and style is a separate file. Most sites need two or three, not nine.
Preload the critical font used in your above-the-fold content.
Render-blocking CSS and JS is the other half. Critical CSS inlining and deferring non-essential JavaScript help — most caching plugins offer both. Test carefully, because this is where things break.
What are Core Web Vitals actually worth for rankings?
An honest answer, because the industry oversells this.
They're a confirmed ranking signal, and they function as a tie-breaker between pages of similar relevance rather than something that overrides content quality. Excellent vitals won't rescue a page that doesn't deserve to rank. Poor ones won't sink genuinely superior content.
The stronger argument is commercial. Google's own published case studies document real business outcomes from vitals improvements — the web.dev case study repository has several, and those are documented results rather than agency estimates.
Which is the better frame: optimise speed because slow pages lose readers and conversions, and accept the ranking benefit as a bonus. That way you're solving a real problem rather than chasing a score.
Measuring the result honestly
Record your baseline before changing anything. Field data for LCP, INP, and CLS from PageSpeed Insights or Search Console, plus your lab score.
Change one thing at a time. Batch six changes and you'll never know which one worked — or which one broke your checkout.
Check the site actually works after every change. Forms, cart, search, mobile menu. Performance plugins break these routinely.
Wait for field data. The 28-day rolling window means real results take weeks. Don't conclude a fix failed after three days.
Watch Search Console's Core Web Vitals report, which groups URLs by pattern — telling you whether you have a template problem or a page problem. If every blog post fails, fix the template once.
Frequently asked questions
Why is my WordPress site slow?
Usually one of three things, and they're worth checking in order: server response time (TTFB) that caps everything else, oversized images that dominate load weight, and JavaScript from plugins and third-party scripts that blocks interaction. Measure before guessing — PageSpeed Insights names your LCP element directly, and on most WordPress sites it's an image nobody compressed or a server taking over a second to respond.
Does page speed affect rankings?
Yes, as a confirmed ranking signal — but it functions as a tie-breaker between pages of similar relevance rather than overriding content quality. Excellent Core Web Vitals won't make a mediocre page rank, and poor ones won't sink genuinely better content. The stronger argument for fixing speed is commercial: slow pages lose readers and conversions regardless of where they rank.
What is a good LCP?
Under 2.5 seconds, measured at the 75th percentile of real visitors over a 28-day window. Between 2.5 and 4 seconds is "needs improvement," and above 4 seconds is poor. The 75th percentile matters — you need three-quarters of real visits to hit the threshold, not your own test on a fast connection. LCP is the metric most sites fail, and the usual culprits are server response time and an unoptimised hero image.
Do plugins slow WordPress down?
Some do, considerably, but the count matters far less than the weight. Twenty well-coded plugins can outperform five bloated ones that each load scripts and stylesheets on every page whether needed or not. What matters is what each plugin loads, where it loads it, and what queries it runs. Query Monitor shows you exactly which ones are expensive rather than leaving you guessing by count.
What to do next
Run one page through PageSpeed Insights and note two numbers: your TTFB, and what it names as your LCP element.
If TTFB is over a second, that's your project and no front-end work will fix it. If your LCP element is an image, check whether it's WebP, correctly sized, and not lazy-loaded. That single check resolves a large share of failing LCP scores.
Free: The WordPress maintenance checklist.
Related guides
- How to read a PageSpeed Insights report — interpreting what you find
- Elementor site speed — page builder overhead
- WordPress plugin audit — finding the expensive ones
- Caching and CDN explained — the three jobs and which plugin
- Image SEO — the biggest single win, in detail
- Technical SEO — where speed sits among ranking factors
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]