WordPress Performance Audit Checklist for 2024

A WordPress performance audit is a systematic review of every layer of the performance stack — server configuration, database queries, PHP execution, asset delivery, and third-party integrations — to identify and prioritize the changes that will have the largest measurable impact on Core Web Vitals (LCP, INP, CLS) and Time to First Byte (TTFB). Unlike one-off optimizations applied ad hoc, a structured audit produces a prioritized backlog of improvements ranked by impact versus effort, ensuring the highest-value changes are made first. The audit process starts with baseline measurement: run Lighthouse, WebPageTest, and Google PageSpeed Insights on 5–10 representative pages (homepage, category archive, single post, WooCommerce product page, checkout) at both desktop and mobile viewports, from a geographic location matching the site’s primary audience. Capture LCP, INP, CLS, TTFB, and total blocking time as the before state. Server layer: measure TTFB with curl -o /dev/null -s -w "%{time_starttransfer} " https://example.com — anything above 600ms is a red flag; above 200ms warrants investigation. Check for full-page caching (Nginx FastCGI cache, WP Rocket, W3 Total Cache) — cached HTML responses should have X-Cache: HIT headers and TTFB under 50ms. Database layer: enable the WordPress debug bar with the Query Monitor plugin and examine query counts (above 50 per page is elevated), slow queries (above 100ms), and N+1 query patterns. PHP layer: verify that PHP OPcache is enabled (opcache.enable=1 in php.ini), that the JIT compiler is active for PHP 8+, and that the WordPress version is current (each major release includes performance improvements). Asset layer: verify all CSS/JS is minified and concatenated, unused CSS is purged (tools like PurgeCSS identify 80%+ reduction opportunities), images are in WebP format with correct dimensions, and the LCP image has a fetchpriority="high" attribute. Third-party scripts: use WebPageTest’s waterfall to identify which third-party scripts (chat widgets, analytics, social embeds) contribute to Total Blocking Time — each script blocking the main thread for >50ms is a long task. The caching comparison post and the resource hints post cover individual optimization techniques; this checklist provides the end-to-end audit framework for 2024.

Problem: Performance issues on a WordPress site are often addressed with random one-off optimisations — caching plugins installed without a baseline, images compressed but scripts ignored — resulting in effort spent where impact is smallest.

Solution: Run a structured performance audit against representative pages using Lighthouse, WebPageTest, and PageSpeed Insights before touching anything. The checklist below covers every layer — server, database, PHP, assets, and third-party integrations — and ranks items by effort versus impact so the highest-value changes are made first.

Server & Hosting Checklist:

• TTFB < 200ms for cached pages, < 600ms for uncached (measure with WebPageTest from the target region)
• Full-page caching enabled with cache headers (X-Cache: HIT on repeat requests)
• PHP 8.2+ with OPcache enabled (phpinfo() → OPcache section shows "enabled")
• PHP OPcache opcache.memory_consumption ≥ 256MB; opcache.max_accelerated_files ≥ 10000
• HTTP/2 or HTTP/3 enabled (check with curl -I --http2 https://example.com)
• Brotli or gzip compression for text assets (check Content-Encoding response header)
• CDN delivering static assets from a location near the user (check X-Served-By or CF-Ray headers)

Database & WordPress Query Checklist:

• Query Monitor plugin installed: total queries per page < 30 for typical pages
• No N+1 queries (e.g., get_post_meta() inside a loop without update_post_meta_cache)
• Slow query log enabled in MySQL (slow_query_log=1, long_query_time=1)
• Custom plugin tables have appropriate indexes (EXPLAIN plan shows no full table scans)
• Autoloaded options size < 1MB (check with SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes')
• Persistent object cache (Redis) installed and storing WordPress object cache
• WordPress cron not running on every request (DISABLE_WP_CRON = true + server cron job)

Asset Delivery Checklist:

• LCP image has fetchpriority="high" and loading="eager" (not lazy)
• All images below the fold use loading="lazy" and decoding="async"
• Images served in WebP or AVIF format with fallback (check Content-Type: image/webp)
• Images have explicit width and height attributes to prevent CLS
• No render-blocking CSS or JavaScript in <head> that is not critical
• Google Fonts loaded with display=swap and preconnect hints
• Total JavaScript payload < 150KB gzipped for initial page load
• Unused CSS removed or deferred (PurgeCSS or manual audit)

Third-Party Script Checklist:

• Total Blocking Time < 200ms (Lighthouse TBT metric)
• Chat widgets, analytics, and social embed scripts loaded with defer or dynamically
• Google Tag Manager fired after user interaction where possible (Partytown library)
• Facebook Pixel, LinkedIn Insight Tag loaded via GTM, not hardcoded in functions.php
• YouTube/Vimeo embeds replaced with facade (click-to-load thumbnail) to defer iframe load

NOTE: Run the audit in a private browser window with all browser extensions disabled — ad blockers, privacy extensions, and developer tools can interfere with timing measurements and third-party script loading. Also run the audit both with and without the WordPress admin bar visible (log out for the public-user test) — the admin bar loads additional CSS and JavaScript that is not served to anonymous visitors and can inflate measurements taken while logged in. Repeat the audit after implementing changes to verify impact; PageSpeed Insights uses real-world Chrome User Experience Report (CrUX) data that updates with a 28-day rolling window, so lab tests (Lighthouse) will show immediate improvements while CrUX-based field data takes up to 4 weeks to reflect changes.