Most WordPress “speed optimization” advice is either too technical to implement, or it sends you down rabbit holes that barely move the needle.

This checklist is different. It’s built around the few changes that reliably create the biggest real-world improvement—the kind you can feel (and your users can feel), not just a higher lab score.

What “fast” means in 2026 (don’t chase the wrong target)

A fast WordPress site is one that consistently delivers good Core Web Vitals for real users. Google specifically recommends aiming for:

• LCP (Largest Contentful Paint) ≤ 2.5s
• INP (Interaction to Next Paint) ≤ 200ms
• CLS (Cumulative Layout Shift) ≤ 0.1

And importantly, these are evaluated at the 75th percentile (meaning: not your best users on fiber internet, but typical users).

Field data vs lab data (why your score can “look good” but your site still feels slow)

• Field data = how real users experience your site over time (what matters most for CWV).
• Lab data = a simulated test run (great for debugging and repeatability).

Google’s Core Web Vitals report in Search Console uses real-world (field) data and groups URLs by similar patterns—so it’s great for finding systemic issues across templates (home, posts, product pages).
PageSpeed Insights combines Lighthouse lab audits with CrUX field insights when available.

The 80/20 approach (do this in order)

Before the checklist, here’s the “fastest path to wins”:

1. Pick 3 pages that matter most
   • Homepage
   • Your top traffic blog post
   • Your key money page (service, landing page, product category)
2. Measure once (don’t obsess)
   • Search Console → Core Web Vitals report (site-wide trends)
   • PageSpeed Insights → those 3 pages (to identify likely root causes)
3. Fix the biggest bucket first
   • If LCP is bad → fix server + caching + hero media
   • If INP is bad → fix JS/plugin bloat + third-party scripts
   • If CLS is bad → reserve space + fix layout shifts

Now the checklist.

The WordPress Speed Checklist (80/20)

1) Get full-page caching working (this is the biggest lever for most sites)

If your pages aren’t cached, WordPress rebuilds them repeatedly (PHP + database + plugins) and your server pays that cost for every visit.

Do this:

• Ensure page caching is enabled for logged-out visitors
• Confirm the cache is actually HIT-ing (not constantly “MISS”)
• Exclude pages that must stay dynamic (cart/checkout/account for WooCommerce)

If you’re on a managed host, prefer the host’s built-in caching layer (it’s usually more efficient and less conflict-prone).

2) Reduce TTFB by fixing the “server + WordPress stack” basics

A slow Time to First Byte is often the hidden reason your LCP never gets good.

80/20 checks:

• Use modern PHP versions and a healthy hosting stack (your host should keep you aligned with WordPress requirements).
• Avoid “death by plugins” (especially heavy page builders + multiple optimization plugins that fight each other)
• If your admin is slow, your frontend is often suffering too (database + PHP workload)

Reality check: if your hosting environment is underpowered or poorly tuned, you can compress images all day and still stay slow.

If you want a direct diagnosis of what’s actually limiting you (hosting stack, caching, theme, plugins, third-party scripts), request a hosting audit.

3) Fix your LCP element (usually: the hero image or headline block)

LCP is “when the main content appears.” Google recommends aiming for LCP within 2.5 seconds for good UX.

Web.dev’s guidance is clear: optimizing LCP is holistic—don’t just “optimize images,” also look at server response, render-blocking resources, and how the page is built.

80/20 actions (choose what matches your LCP element):

• If LCP is an image:
  • Compress properly (don’t upload 5000px images to display at 1200px)
  • Serve modern formats where possible
  • Avoid sliders and background videos on the hero
• If LCP is text:
  • Reduce render-blocking CSS/JS (next steps below)
  • Optimize fonts (next steps below)

4) Stop render-blocking “builder bloat” (CSS + JS)

A big reason WordPress pages feel slow is that they ship too much CSS/JS before anything meaningful can paint.

80/20 actions:

• Remove plugins that add sitewide CSS/JS for a feature used on one page
• Avoid stacking multiple “optimization” plugins (they often duplicate features)
• Defer non-critical JS (especially marketing tags, chat widgets, heatmaps)

Rule of thumb: every plugin should justify itself with either revenue or mission-critical value.

5) Optimize images the practical way (not the obsessive way)

Images are still the #1 payload issue on most WordPress sites.

80/20 image checklist:

• Convert oversized images to the correct display size
• Use compression that actually reduces kilobytes meaningfully
• Lazy-load below-the-fold images (keep above-the-fold hero/loading priority clean)
• Avoid loading 10 decorative icons as separate large image files

If you only fix one image thing: fix the hero image.

6) Fonts: fewer files, faster paint, fewer layout shifts

Fonts can quietly ruin LCP and CLS.

80/20 actions:

• Use 1–2 font families max
• Limit font weights (regular + bold is often enough)
• Ensure font loading doesn’t cause layout jumps (CLS risk)
• Consider system fonts if performance is a priority (especially for content-heavy sites)

7) Fix INP by reducing main-thread work (JS + interactions)

INP measures responsiveness. Google recommends INP < 200ms.

INP is most often hurt by:

• too much JavaScript,
• long tasks blocking the main thread,
• heavy UI interactions (sliders, mega menus, filters, popups),
• third-party scripts.

80/20 actions:

• Remove or delay third-party scripts (chat, popups, A/B testing, heatmaps)
• Replace heavy animation/slider plugins with simpler blocks
• Reduce DOM complexity (page builders can explode the DOM)

If your site is “fast on load” but feels laggy on scroll/click, this is usually the bucket.

8) Third-party scripts: treat them like a budget, not a shopping list

This is where many WordPress sites self-sabotage. You can have great hosting and a clean theme—and still lose performance because of ad pixels, chat widgets, and trackers.

80/20 approach:

• Keep only what you truly use (and can prove is valuable)
• Load non-essential scripts after interaction or after the main content loads
• Prefer one consolidated analytics approach rather than multiple overlapping tools

9) Kill CLS by reserving space for anything that loads late

CLS should be < 0.1.
CLS is usually caused by “surprise” layout changes:

80/20 fixes:

• Set explicit dimensions for images and videos
• Reserve space for banners, cookie notices, and popups
• Avoid inserting large elements above existing content after page load
• Be careful with late-loading web fonts (can cause reflow)

10) Clean up WordPress overhead that quietly slows you down

This is not the first place I’d start, but it’s a meaningful second wave once caching + payload are addressed.

80/20 checks:

• Disable features/plugins you no longer use
• Reduce huge libraries (icon packs, slider bundles, unused page builder modules)
• Limit post revisions if your database grows aggressively
• Watch “autoloaded options” bloat (a common WordPress slowdown source)

11) Stop “optimization conflicts” (one of the most common WordPress issues)

A surprisingly common reason speed work fails: multiple tools fighting each other.

Avoid stacking:

• caching plugin + host caching + CDN caching (without clarity)
• multiple image optimization plugins
• multiple minify/defer systems

Pick a single “source of truth” for:

• caching,
• image optimization,
• asset handling.

This is where managed hosting often simplifies life—because it replaces several plugins with platform-level solutions.

12) Lock in results with a simple monitoring habit

Speed isn’t a one-time project. A new plugin, a new banner, or a new tracking script can undo your wins.

Simple routine:

• Once a month:
  • Check Search Console CWV report (look for new “poor” URL groups)
  • Re-test your 3 key pages in PSI (spot regressions quickly)

Quick “If this, then that” troubleshooting guide

If LCP is failing…

Start here:

• Confirm page caching works
• Reduce TTFB (hosting + PHP workload)
• Fix the hero image / LCP element
• Reduce render-blocking assets

Web.dev explicitly recommends looking at LCP holistically—TTFB and render-blocking resources often dominate.

If INP is failing…

Start here:

• Remove/delay third-party scripts
• Reduce JS-heavy plugins and UI widgets
• Simplify page builder layouts and DOM size

If CLS is failing…

Start here:

• Reserve space for late-loading elements
• Set media dimensions
• Fix popups/banners that shove content