WordPress Performance Optimization Checklist

Sub-second WordPress is achievable on a budget host with the right disciplines. Most slow WordPress sites are slow not because the platform is heavy but because the layers above it — themes, plugins, third-party scripts, media handling — accrete weight without anyone watching. This is the working checklist: measurement first, then the wins ranked by impact-to-effort.

Measure before you optimize

Three measurement layers, all worth running:

• PageSpeed Insights / Lighthouse— the lab measurement most people start with. Gives you Core Web Vitals scores and specific recommendations. Lab data is consistent but doesn't reflect real users.
• CrUX / GSC Core Web Vitals report— field data from real Chrome users. Slower to update (28-day rolling window) but it's what Google actually ranks against.
• RUM (real user monitoring) via web-vitals.js, Cloudflare RUM, or Sentry. Gives you per-session telemetry with attribution to specific deploys.

For the deeper Core Web Vitals architecture and what each metric measures, see Core Web Vitals 2026: The Technical SEO Blueprint. This article is the WordPress-specific implementation work.

Hosting — the foundation

You can't outrun bad hosting. Cheap shared hosting on oversold servers caps how good your TTFB can be. The hosting tiers worth knowing:

• Budget shared hosting ($5-15/mo) — fine for low-traffic brochure sites; TTFB will be 600-1200ms on cache misses
• Managed WordPress hosts (Kinsta, WP Engine, Pressable, $30-100+/mo) — built-in object caching, full-page cache, server-level optimizations; TTFB 100-300ms
• VPS or dedicated ($30-200/mo) — full control, requires sysadmin work, can be very fast or very slow depending on configuration
• Edge-served headless(Vercel, Cloudflare Pages, Netlify) — different architecture, fastest possible but doesn't fit all WordPress workflows

For most clients, managed WordPress hosting is the right starting point — the per-month cost is recovered immediately in the time you don't spend tuning Nginx.

Caching — the highest-leverage layer

Three caching layers work together. Get all three right.

• Page cache — full HTML responses cached at the server or edge, served without invoking PHP for anonymous traffic. The biggest single win.
• Object cache(Redis, Memcached) — caches the database queries WordPress runs internally. Cuts down on the "30+ DB queries per page" default.
• Browser cache— long max-age headers on static assets so returning visitors don't re-download.

On managed hosts, page cache and object cache are usually built in — verify they're actually running. On a generic VPS or shared, install one of the WP-aware caches: WP Rocket (paid, easy), W3 Total Cache (free, complex), Cache Enabler (free, lightweight), or LiteSpeed Cache if you're on a LiteSpeed server.

The image pipeline

Images are the largest performance lever on most WordPress sites. The discipline:

• Serve next-gen formats. WebP for general, AVIF for the leading-edge browsers. Most major optimization plugins (ShortPixel, Imagify, EWWW, Smush) handle conversion.
• Responsive sizes. WordPress generates multiple sizes by default; serve the right one with srcset. Don't ship a 2400px image to a phone displaying 400px.
• Compress. 80-85% JPEG/WebP quality is indistinguishable from 100% in most cases and 30-40% smaller. AVIF lets you push compression further.
• Lazy load below-the-fold. loading="lazy" works in every modern browser. Apply to all non-LCP images. See Lazy Loading Images the Right Way for the full pattern.
• Reserve dimensions. Always set width and height on <img> elements (or aspect-ratio via CSS). Layout shift from late-loading images is a major CLS source.

For LCP images specifically — the hero, the above-fold images — preload them and skip lazy loading:

<link rel="preload" as="image"
      href="/wp-content/uploads/2026/04/hero.webp"
      imagesrcset="/wp-content/uploads/2026/04/hero-mobile.webp 768w,
                   /wp-content/uploads/2026/04/hero.webp 1920w"
      imagesizes="100vw">

Database hygiene

WordPress databases bloat over time. Common bloat sources:

• Post revisions — limit to 5-10 with define( 'WP_POST_REVISIONS', 10 ) in wp-config; clean up old ones
• Auto-drafts — accumulate forever, clean quarterly
• Spam comments — empty the spam folder; it sits in the database otherwise
• Transients— expired transients sometimes don't self-clean depending on how plugins set them
• Orphaned meta from uninstalled plugins — their postmetaentries persist if the plugin didn't clean up on uninstall

WP-Optimize, Advanced Database Cleaner, or a one-time WP-CLI run can clean these. Add proper indexes if your usage patterns warrant — slow query log via the database server tells you what needs indexing.

Plugin and theme audit

Every active plugin is loaded, every page load. The audit:

• Use Query Monitor to see which plugins are spending the most time. Top offenders may be replaceable with lighter alternatives.
• Deactivate plugins you're not actively using and remove their files — deactivated plugins still consume disk space and can be reactivated by an attacker. See WordPress security best practices.
• Themes: page builders (Elementor, Divi, Beaver) add real weight. They're fine for sites that benefit from no-code editing, but for sites where speed matters more than edit-anywhere, a developer-built block theme or classic theme will be 30-50% faster out of the box.

Third-party scripts — the silent INP killer

The single biggest performance regression source on well-built WordPress sites is third-party scripts the marketing team adds via GTM. Every tag is a download, parse, execute, and memory cost.

Audit pass:

• List every external script firing on the page
• For each: do we know why it's here? If not, remove.
• Defer non-essential scripts to load rather than parser-blocking
• Move heavy session-replay tools (Hotjar, FullStory) to async with delayed load
• Combine related tags into GTM where possible — one container instead of five

On checkout pages especially, third-party script bloat is the dominant INP cause. See WooCommerce checkout optimization for the checkout-specific discipline.

CSS and JS delivery

• Inline critical CSS for above-the-fold content; load the rest asynchronously. Plugins like Autoptimize or RocketLazyLoadCriticalCSS handle this.
• Defer non-critical JavaScript. Most theme JavaScript can be deferred without breaking interactivity.
• Self-host fonts and analytics where possible. Self-hosted fonts skip a DNS lookup; self-hosted GA4 (via Cloudflare Worker proxy) avoids the third-party round trip.
• Preconnect to known third-party origins. <link rel="preconnect"> warms up DNS + TLS for fonts, analytics, ad servers.

HTTP/2, HTTP/3, and Brotli

Server-level wins your host should already have:

• HTTP/2 or HTTP/3 (multiplexing reduces handshake cost)
• Brotli compression (better than gzip; supported by every modern browser)
• OCSP stapling on TLS
• 0-RTT for repeat HTTPS connections

On managed hosts, all of these are usually default. On VPS, verify with curl -I --http2 -v.

The full checklist

• - [ ] Hosting tier matches site traffic and revenue
• - [ ] Page cache active and verified (curl with no cookies returns cached HTML)
• - [ ] Object cache (Redis/Memcached) configured and reporting hits
• - [ ] Browser cache headers set with sensible max-age (1 year for hashed assets, shorter for HTML)
• - [ ] WebP/AVIF conversion automatic for new uploads
• - [ ] All images have width + height attributes; aspect-ratio reserved in CSS
• - [ ] LCP image preloaded with imagesrcset
• - [ ] Below-fold images use loading="lazy"
• - [ ] Post revisions limited via WP_POST_REVISIONS
• - [ ] Database cleaned (revisions, auto-drafts, spam, transients) within last 90 days
• - [ ] Active plugin list audited within last 90 days; unused plugins removed
• - [ ] Query Monitor profiled in dev to identify slow plugins
• - [ ] Third-party scripts audited; non-essential removed or deferred
• - [ ] Critical CSS inlined; non-critical async
• - [ ] Non-critical JS deferred
• - [ ] Fonts self-hosted or preloaded with font-display: swap
• - [ ] Preconnect to known third-party origins
• - [ ] HTTP/2 or HTTP/3 enabled at server
• - [ ] Brotli compression enabled
• - [ ] CrUX field data reviewed within last 28 days
• - [ ] RUM tooling collecting real-user web-vitals data

Worked through, this checklist gets most WordPress sites under 1.5s LCP, INP under 200ms, and CLS near zero. The compounding payoff: search rankings tick up, conversions tick up, support tickets about "site is slow" tick down. For sites where this matters, our SEO and content strategy service includes performance work as a first-class deliverable. For lazy loading specifically — the highest-leverage single technique — see Lazy Loading Images the Right Way.