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 to $15/mo): fine for low-traffic brochure sites. TTFB will be 600 to 1,200ms on cache misses.
• Managed WordPress hosts (Kinsta, WP Engine, Pressable, $30 to $100+/mo): built-in object caching, full-page cache, server-level optimizations. TTFB 100 to 300ms.
• VPS or dedicated ($30 to $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. 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: where the biggest wins live

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 to 85% JPEG/WebP quality is indistinguishable from 100% in most cases and 30 to 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 to 10 with define( 'WP_POST_REVISIONS', 10 ) in wp-config, and 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. The 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 to 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, then 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 single biggest payoff per hour spent) see Lazy Loading Images the Right Way.