WordPress Performance: Complete Speed Audit Guide
WordPress powers 40% of the web, but it's often slow by default. Learn how to audit your WordPress site and fix the most common performance bottlenecks.
WordPress is the most popular CMS in the world, and it’s often one of the slowest. Default installations, bloated themes, and too many plugins create sites that score 20–40 in Lighthouse. But a well-optimized WordPress site can score 80–95.
Here’s how to diagnose and fix performance on WordPress.
Step 1: Run a Baseline Speed Test
Start by running your WordPress site through debugutils.dev to get a complete diagnostic baseline:
- Lighthouse Performance score
- LCP, CLS, INP scores
- CrUX field data (real user metrics)
- Request waterfall (shows every loaded resource)
- Prioritized recommendations
Test your homepage, a typical blog post, and a WooCommerce product page if applicable — each may have different bottlenecks.
The Main WordPress Performance Problems
1. No Page Caching
By default, every WordPress request executes PHP, queries the database, and generates HTML. This results in TTFB of 500ms–3000ms. With a page cache, TTFB drops to 10–100ms.
Fix: Install LiteSpeed Cache (if on LiteSpeed server), WP Rocket (paid, excellent), or W3 Total Cache (free, complex). Enable full-page caching immediately. For a deeper look at caching and TTFB, see How to Improve TTFB with Caching.
2. Too Many Plugins
Every plugin adds PHP execution time, database queries, and often front-end assets (CSS and JavaScript). A site with 40 plugins is significantly slower than one with 10.
Fix: Audit your plugins. Go through each one and ask: is this actively necessary? Are there alternatives built into a single plugin? Common bloat: separate SEO plugins, separate caching plugins, separate backup plugins, multiple analytics plugins.
3. Unoptimized Images
Media libraries full of 3MB JPEG uploads. WordPress generates several sizes automatically but doesn’t convert to WebP by default.
Fix:
- Install ShortPixel or Imagify to convert existing and new uploads to WebP and compress them (see our image optimization guide for more)
- Install Regenerate Thumbnails after changing image settings
- Add lazy loading (WordPress does this by default since 5.5, but verify it’s not disabled)
4. Render-Blocking Scripts and Styles
Plugins load their own CSS and JS files unconditionally — even on pages where the plugin isn’t used. A contact form plugin loading on every page when only the contact page needs it.
Fix: Use Asset CleanUp or your caching plugin’s asset optimization features to defer JavaScript, combine/minify CSS, and disable assets per-page.
5. Slow Hosting
Shared hosting with PHP 7.4 and no object caching will always be slow. Moving to a modern host is often the highest-impact change.
Good WordPress hosting options:
- Kinsta — Managed WordPress on Google Cloud, excellent performance
- Cloudways — Managed cloud hosting (DigitalOcean, AWS, etc.)
- WP Engine — Managed WordPress, built-in caching, reliable
- Hostinger — Budget option that’s better than most other cheap hosts
6. No Object Cache
Even with page caching, dynamically generated pages (WooCommerce cart, logged-in users) still hit the database. An object cache (Redis or Memcached) stores database query results in memory.
Fix: Enable Redis via your host’s control panel, then install the Redis Object Cache plugin.
Quick Performance Wins
These changes take under 30 minutes and have immediate impact:
- Install and configure a caching plugin (LiteSpeed Cache or WP Rocket)
- Enable GZIP/Brotli compression at the server level
- Install an image optimizer (ShortPixel or Imagify)
- Add Cloudflare as a CDN (free tier is sufficient)
- Enable lazy loading on images
- Defer non-critical JavaScript in your caching plugin settings
Measuring Improvement
After making changes, run another test on debugutils.dev and compare the waterfall and scores. With proper caching and image optimization, most WordPress sites can improve their Performance score by 20–40 points.
The request waterfall is particularly useful — look for the HTML document TTFB (should be under 200ms with caching), image sizes (should be WebP, reasonably sized), and script/style counts (fewer is better).