If your WordPress site feels “a bit slow,” you’re not alone. The median mobile webpage is ~2.3 MB and the median desktop page ~2.65 MB, and JavaScript has become one of the biggest contributors to modern bloat.

But page speed isn’t just a vanity metric. Even 0.1 seconds of improvement can move real business outcomes. In Google/Deloitte’s “Milliseconds Make Millions” study (37 brands, multiple verticals), a 0.1s improvement correlated with conversion and engagement lifts (e.g., +8% conversions for retail, +10% for travel on average).

This guide is built to be a true checklist you can work through, starting with the highest-impact fixes, then moving into deeper optimizations. It’s WordPress-specific, but the principles apply universally.

What “fast” means in 2026 (hint: it’s not a single number)

Google’s performance conversation today is heavily shaped by Core Web Vitals (CWV), which are field metrics based on real users. The three core metrics (and common targets) are: 

• LCP (Largest Contentful Paint): loading experience

✅ Good: ≤ 2.5s

• INP (Interaction to Next Paint): responsiveness

✅ Good: ≤ 200ms

• CLS (Cumulative Layout Shift): visual stability

✅ Good: ≤ 0.1

Also important: INP replaced FID as a Core Web Vital (officially March 12, 2024). If your mental model still revolves around “FID,” update it; most modern fixes target long tasks, main-thread blocking, and heavy client-side rendering. 

Field data vs. lab data (you need both)

• Field data (real users): What Google actually sees at scale.
• Lab data (synthetic tests): Great for debugging and comparing changes.

PageSpeed Insights (PSI) blends both and reports field metrics at the 75th percentile; it’s intentionally “tough,” because it’s meant to reflect frustrating experiences, not best-case scenarios. 

The WordPress Page Speed Checklist (prioritized)

Before you start: protect yourself from breaking the site

• Work on a staging site (or at least take a full backup)
• Track changes in a simple log (“changed X → score improved/worsened”)
• Test key flows after each step (forms, checkout, search, login)

Phase 1: Measure, don’t guess (30–60 minutes)

1) Establish a baseline (so you know what moved the needle)

• Run PageSpeed Insights on: homepage, a blog post, a key landing page, and (if applicable) product/checkout pages
• Note: LCP element, main-thread blocking, render-blocking resources, CLS sources
• Check Google Search Console → Core Web Vitals report (groups of URLs)

Pro tip: Don’t obsess over a perfect “Performance score.” Track:

• CWV pass/fail (field)
• LCP/INP/CLS numbers
• Total requests + total transfer size (helps explain “why”)

2) Identify your actual bottleneck category

Most WordPress performance issues fall into one (or more) buckets:

• Server/hosting bottlenecks: slow TTFB, no caching, overloaded PHP workers
• Front-end bloat: too much JS/CSS/fonts, heavy sliders/builders
• Media weight: unoptimized hero images, too many large images
• Third-party scripts: chat widgets, multiple trackers, ad scripts
• Database + dynamic queries: WooCommerce, membership sites, complex filtering

Once you know the bucket, the fixes become far more straightforward.

Phase 2: The highest-impact fixes (these usually matter most)

3) Turn on full-page caching (often the biggest single win)

For most WordPress sites, caching is the fastest path to meaningful speed improvements. WordPress’s own developer documentation calls caching “the fastest way to improve performance” and notes it can improve performance several hundred times over for fairly static pages. 

Checklist

• Enable full-page caching (plugin, host-level cache, or reverse proxy cache)
• Ensure cache varies correctly for logged-in users, carts, and personalized content
• Set sane cache TTLs and purge rules (purge on post update, etc.)

Common mistake: “I have a cache plugin installed” ≠ caching is actually working. Verify by checking response headers or using cache-test tools.

4) Fix slow hosting fundamentals (TTFB is the hidden killer)

Even with a perfect front-end, a slow server will keep you stuck.

Checklist

• Use modern PHP and keep it updated (WordPress core recommends current supported PHP versions; hosts typically provide toggles)
• Make sure OPcache is enabled (host-side)
• Confirm HTTP/2 (or HTTP/3) is enabled at the CDN/host level
• Enable compression (Brotli or gzip) and keep-alive (host-side)

If your TTFB is consistently high, you’re often looking at:

• no page cache
• underpowered hosting
• too many uncached dynamic queries
• overloaded database

5) Use a CDN (and understand what it’s actually doing)

A CDN can reduce latency and offload static assets (images, CSS, JS, fonts). It’s especially helpful if you have visitors from multiple geographies.

Checklist

• Serve images/CSS/JS from a CDN
• Enable HTTP/2/3 + modern TLS at the edge
• Consider edge caching (full-page cache at the CDN) for mostly-static sites

Phase 3: WordPress-specific optimizations that move CWV

6) Optimize images (LCP almost always points here)

Your goal

Make the Largest Contentful Paint element (often the hero image or featured image) load fast.

WordPress supports modern formats out of the box:

• WebP support from WordPress 5.8+
• AVIF support from WordPress 6.5+ (and AVIF can be up to 50% smaller than JPEG in many cases)

Checklist

• Convert key images (especially above-the-fold) to WebP/AVIF
• Resize images to the actual displayed size (no 4000px uploads for 1200px display)
• Use responsive images (srcset) properly (WordPress helps with this automatically when images are correctly uploaded/used)
• Preload the LCP image if needed (especially on image-heavy hero sections)
• Avoid background images for the LCP element when possible (harder to optimize)

Don’t blindly lazy-load the hero image

WordPress added native lazy-loading by default (via loading=”lazy”) starting WordPress 5.5.
That’s great for below-the-fold media, but if your hero/LCP image is lazy-loaded, you can accidentally delay the most important element.

Checklist

• Ensure the hero/LCP image loads eagerly (not lazily)
• Lazy-load images below the fold (keep it for content galleries, long posts, etc.)

7) Reduce JavaScript bloat (INP and LCP both benefit)

Modern pages often ship a lot of JS. The Web Almanac reports that in 2024 the median page requested 24 JS files on desktop and 22 on mobile, and JS has overtaken images as the most requested file type.

Checklist

• Remove plugins that inject sitewide scripts you don’t need
• Delay or conditionally load scripts by page type (e.g., load checkout scripts only on checkout)
• Defer non-critical JS (defer) and avoid render-blocking scripts
• Replace heavy sliders/animations with lighter alternatives
• Keep DOM size reasonable (large DOMs increase rendering work and can hurt INP) 

Third-party scripts: the silent performance tax

Chat widgets, heatmaps, A/B testing scripts, ad scripts, and multiple analytics tags can destroy performance, especially mobile.

Checklist

• Audit all third-party scripts (Tag Manager makes it easy to accumulate junk)
• Remove duplicates (two analytics libraries doing the same thing)
• Load non-essential scripts after interaction or after the page is stable

8) Optimize CSS delivery (render-blocking is common)

CSS often blocks rendering. Your goal is: minimal critical CSS early, the rest later.

Checklist

• Remove unused CSS (common with page builders + multipurpose themes)
• Minify CSS (small win, but easy)
• Load non-critical CSS asynchronously (when practical)
• Avoid gigantic icon/font libraries if you only use a few icons

9) Fix fonts (fast sites don’t “accidentally” load 6 font files)

Fonts can be surprisingly expensive. The Web Almanac shows fonts are a meaningful chunk of median page weight. 

Checklist

• Use fewer font families/weights (most sites can live with 2–3 weights total)
• Prefer modern formats (WOFF2)
• Self-host fonts where practical (reduces third-party dependency)
• Use font-display: swap to avoid invisible text
• Preload the most important font files (carefully—preloading everything is counterproductive)

10) Prevent layout shift (CLS wins are often “death by a thousand cuts”)

CLS usually comes from:

• images/iframes without width/height
• ads inserting late
• popups/banners pushing content
• web fonts swapping sizes

Checklist

• Ensure images/embeds have dimensions reserved
• Avoid injecting banners at the top after load (or reserve space)
• Be careful with cookie banners (overlay is often better than push-down)
• If fonts cause shift, adjust fallback fonts or preload key fonts

Phase 4: Backend + database (especially for dynamic sites)

11) Add persistent object caching (huge for WooCommerce/membership sites)

Full-page cache is king for static pages, but dynamic sites still hit the database heavily. WordPress Site Health even includes a test to recommend persistent object cache when missing. 

Checklist

• Enable Redis/Memcached object caching (host + plugin)
• Confirm it’s persistent (not just non-persistent in-memory per request)
• Re-test admin and logged-in flows (object cache helps here too)

12) Clean and optimize the database (small-to-medium gains)

Database cleanup won’t fix a fundamentally slow theme or huge JS payload, but it helps keep things healthy.

Checklist

• Remove unused plugins/themes (they can leave tables/options behind)
• Clean post revisions, expired transients, spam trash
• Optimize tables where appropriate (host tools or WP maintenance plugins)
• Reduce autoloaded options bloat (advanced, but powerful on old sites)

Phase 5: Validation and ongoing monitoring (the part most people skip)

13) Re-test properly (and understand “passing”)

PageSpeed Insights passes CWV when the 75th percentile of LCP, INP, and CLS are all “Good” (assuming sufficient data). 

Checklist

• Re-run PSI on the same templates/pages
• Compare LCP element and blocking resources before/after
• Check Search Console CWV trends over time (field data needs time to reflect improvements)

14) Set a performance budget (so the site stays fast)

Performance is not a one-time project; new plugins, tags, and “just one more widget” will slowly kill it.

Checklist

• Set simple guardrails:
  • Max JS size per page
  • Max image weight for hero
  • Max number of third-party scripts
• Review performance monthly (especially after redesigns/campaign pages)

Quick “Print This” WordPress Page Speed Checklist

Measurement

• PSI baseline on key templates + note LCP element
• Search Console CWV report reviewed
• Identify bottleneck category (server / front-end / media / third-party / DB)

Biggest wins first

• Full-page caching enabled and verified
• Hosting tuned (modern PHP, OPcache, HTTP/2/3, compression)
• CDN enabled for static assets

CWV-focused front-end

• LCP image optimized (AVIF/WebP, correct sizing, not lazy-loaded)
• Unused/duplicate plugins removed (especially script-heavy)
• JS deferred/delayed where safe; reduce DOM complexity
• CSS trimmed and delivered efficiently
• Fonts reduced, WOFF2, swap behavior, preload critical fonts
• CLS sources fixed (reserved space, stable headers/banners)

Dynamic sites

• Persistent object cache enabled
• Database cleaned; autoload bloat controlled

Verify and protect

• Re-test PSI and compare key metrics
• Add performance budgets + monthly review

Final note: don’t chase perfection, chase user experience (and revenue)

Google’s page experience guidance is explicit that there isn’t one single “page experience signal,” and CWV is part of a broader set of signals. So the practical win is: get CWV into “Good” for your key templates, keep the site stable, and prevent “performance regressions” as your marketing stack grows.