WordPress Performance Audits: 5-Step Checklist to Find Bottlenecks

Your site is slow. Visitors are bouncing. You know something’s wrong, but where do you start? Is it your hosting? Too many plugins? Large images? Database bloat? A systematic performance audit cuts through the guesswork. This practical checklist walks you through diagnosing the most common WordPress bottlenecks so you can prioritize fixes that deliver real speed gains.

Performance isn’t just about impatience. Google’s Core Web Vitals (CWV)—Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS)—are ranking factors. Sites that load and respond quickly rank higher. Plus, every 100ms of delay correlates with a measurable drop in conversions.

But here’s the challenge: performance issues are rarely a single culprit. It’s usually a combination of factors: suboptimal hosting, unoptimized images, too many plugins, inefficient database queries, missing caching, and unminified assets.

An audit’s job is to identify which factors are actually hurting your site so you don’t waste time fixing problems that don’t exist. (Too many site owners optimize for images when the real issue is server response time.)

Start with the big picture. Use Google’s free tools to see how your site actually performs for real users:

Google PageSpeed Insights

Visit pagespeed.web.dev and enter your homepage URL. You’ll get:

• Core Web Vitals status: LCP (how fast the main content loads), INP (how responsive the page is to clicks/input), and CLS (visual stability).
• Performance score (0–100): An aggregate measure.
• Opportunities: Actionable recommendations (reduce unused CSS, defer offscreen images, minify JavaScript, etc.).
• Diagnostics: Detailed metrics (server response time, total block time, etc.).

Interpretation: If LCP is over 4 seconds, something’s seriously wrong. If LCP is 2–4 seconds, there’s room for improvement. Under 2.5 seconds is the CWV target. INP (page responsiveness) should be under 200 milliseconds. CLS (visual shifting) should be under 0.1.

Run this on your homepage and 3–4 key inner pages (a service page, a blog post, a conversion page). Different pages often have different bottlenecks.

Google Search Console

If you own the site in Google Search Console, go to Experience → Core Web Vitals. This shows your site’s real-world performance across all visitors, not just a single test. If your Search Console CWV report shows issues, that’s real data about user experience—prioritize that.

GTmetrix (Optional, Detailed Breakdown)

GTmetrix is a deeper analysis tool. It provides waterfall charts showing exactly what resources load and when, filmstrip views of page load progression, and detailed per-resource timing. It’s especially useful for identifying which specific resources or scripts are slow.

Key metrics to note from GTmetrix:

• Page load time (total time for page to fully load)
• First Contentful Paint (FCP; when first content painted)
• Largest Contentful Paint (LCP; when largest content element loads)
• Time to First Byte (TTFB; server response time—often overlooked, often a major issue)
• Total Page Size and number of requests

Action item: Document these baseline metrics for comparison after optimizing.

Time to First Byte (TTFB)—how long the server takes to respond—is often the culprit. If TTFB is over 1 second, your server (or hosting provider) is the bottleneck, not your site code.

Diagnose TTFB: Is It Hosting or Code?

Quick test: Use KeyCDN Speed Test or GTmetrix and look at TTFB. If it’s consistently over 1 second, check these:

• Server location vs. your visitors: If your server is in Europe but most visitors are in North America, latency adds overhead. Consider a CDN (Content Delivery Network) to serve assets from locations closer to visitors.
• Shared hosting vs. dedicated/VPS: Shared hosting often has noisy neighbors (other sites on the same server consuming resources). Upgrading to a managed hosting provider or VPS can reduce TTFB significantly.
• Database performance: Slow database queries delay server response. Check your hosting provider’s tools or ask their support: Are there slow queries? Is the database indexing optimized?
• PHP version: Old PHP versions are slower. Contact your host and ensure you’re running PHP 8.1 or later.

Reality check: If you’re on shared hosting and TTFB is poor, no amount of WordPress optimization will fix it. Upgrading hosting is the ROI play. Managed WordPress hosting is optimized for performance and often costs only slightly more than shared hosting.

Check for a Caching Layer

Ask your hosting provider: Do they offer server-level caching (like Redis or Memcached)? Is PHP opcaching enabled? These reduce TTFB drastically. If not, ask them to enable it or consider switching hosts.

Too many plugins, or poorly coded ones, tank performance. Use these diagnostics:

Plugin Audit

Go to Plugins in your WordPress admin. For each active plugin, ask:

• Is it used? If you haven’t touched it in a year and don’t know what it does, deactivate it. Test your site after deactivating to ensure nothing breaks. If nothing breaks, delete it. Dead plugins are just performance drag.
• Does it load on every page? Some plugins load their entire codebase on every pageview, even if the functionality is only needed on admin pages or a single page template. Question unnecessary loading.
• Does it connect to external APIs? If a plugin makes requests to external services (e.g., a backup plugin contacting a cloud service), those network calls add latency. Check if these are necessary on every page or just on admin actions.

Performance testing: If you suspect a plugin is slow, disable it, run GTmetrix again, and compare metrics. You can also use tools like WP Rocket’s plugin conflict detector (they have a free version) to identify problematic plugins quickly.

Pro tip: Reduce your plugin count ruthlessly. Each plugin increases complexity, increases attack surface, and increases the chance of loading slow code. Aim for 10–15 active plugins max; fewer is better.

Theme & WP Bakery Audit

If you use WP Bakery—our preferred page builder—for page building, lightweight design is critical. Audit your pages:

• Unnecessary shortcodes: WP Bakery shortcodes are parsed on every pageview. Bloated pages (lots of nested columns, multiple animations, complex layouts) take longer to render. Simplify where possible.
• Custom CSS/JavaScript: If you’re using inline styles in WP Bakery element CSS parameters or custom JavaScript in page footers, these aren’t optimized. Move them to your theme’s custom CSS file or enqueue them properly via WordPress functions so they’re minified and cached.
• Theme bloat: Is your theme loading features you don’t use (e.g., multiple font libraries, unused animations)? Contact your theme developer or consider switching to a lighter theme if bloat is severe.

Count Your HTTP Requests

Each resource your page loads (images, stylesheets, scripts, fonts) creates an HTTP request. GTmetrix shows your total requests and total page size. A good baseline:

• Under 50 requests: Good
• 50–100 requests: Acceptable, but optimize
• Over 100 requests: Too many; aggressive optimization needed

High request counts often come from: unminified CSS/JS, multiple font libraries, third-party tracking scripts, or embedding multiple videos/media files. Look at your GTmetrix waterfall chart and identify the biggest contributors. Address the top 5–10.

Images typically account for 50–70% of page weight. Unoptimized images are often a major performance bottleneck.

Image Audit

In GTmetrix’s waterfall chart, look for large image files (anything over 500KB is too big). For each large image, note:

• Format: Is it JPEG, PNG, or WebP? (WebP is ~25% smaller than JPEG for same quality.)
• Dimensions: Is the image larger than displayed on screen? (If you display a 1200px image in a 600px container, you’re wasting bandwidth.)
• Is it lazy-loaded? Images below the fold should only load when needed.

Optimization quick wins:

• Compress images using tools like TinyJPG or Squoosh before uploading; modern compression can reduce file size 30–40% with no quality loss.
• Use WebP format: WordPress now supports WebP natively (if your host’s PHP supports it). Tools like Imagify automatically convert and serve WebP to browsers that support it.
• Ensure images are sized to their display dimensions: If an image displays at 600px wide, upload at 1200px (2x for retina displays), not 4000px.
• Lazy-load images below the fold: Modern WordPress/browsers support native lazy loading (`loading=”lazy”`). Use plugins like WP Rocket or enable in your theme settings if available.

Third-Party Resources

Google Fonts, tracking pixels, ad scripts, and chat widgets all load via HTTP and add requests/latency. Audit what you’re loading:

• Google Fonts: How many font families/weights are you loading? Each adds a round trip. Limit to 2–3 font families. Consider system fonts instead (faster, no network request).
• Analytics/Tracking: GA4 scripts are asynchronous (non-blocking), so they don’t hurt much, but review if you need them all.
• Ads/Third-party widgets: These often block page rendering. Load them asynchronously if possible.

WordPress is database-intensive. Every pageview requires multiple database queries (posts, comments, options, user data, etc.).

Check for Slow Queries

If you have access to your hosting’s control panel (cPanel, Plesk, etc.), check MySQL slow query logs. Most hosting providers can tell you if database performance is an issue. If you don’t have access, ask your host: “Are there slow queries on my site? Can you enable the slow log?”

Common causes of slow queries:

• Unoptimized plugins: Plugins that run complex queries without proper indexing. (This ties back to plugin audit—bad plugins often write bad queries.)
• Bloated wp_postmeta or wp_options tables: Over time, these tables accumulate bloat. Use Advanced Database Cleaner to remove orphaned metadata safely.
• Too many revisions: WordPress saves post revisions by default. Limiting revisions reduces database size. Add to wp-config.php: define('WP_POST_REVISIONS', 3);

Implement Caching

Caching is crucial. Three types:

• Browser caching: Tells browsers to cache static assets (CSS, JS, images) locally for a period, reducing repeat requests.
• Server-level caching (Redis/Memcached): Your hosting provider’s responsibility; ask if it’s enabled.
• WordPress page caching: Plugins like WP Rocket or Autoptimize cache generated HTML, so WordPress doesn’t regenerate it per request.

For managed WordPress hosts: Caching is often built-in. Confirm with your host.

For self-hosted:**** Install a caching plugin. WP Rocket is commercial but worth it; WP Super Cache is a solid free alternative.

Pro tip: After implementing caching, clear the cache and re-run GTmetrix. You’ll likely see significant improvements in metrics because repeated page loads (with cached content) are faster.

Hypothetical audit findings:

• PageSpeed Insights: LCP = 4.2s, INP = 150ms, CLS = 0.08. Performance score: 45.
• GTmetrix: TTFB = 1.8s, Page load = 6.2s, 120 requests, 4.8MB total size.
• High TTFB suggests server issue. Image count is high (92 images). 5 unused plugins found.

Prioritized action plan:

• Priority 1 (Quick win): Deactivate 5 unused plugins. Expected improvement: Lower request count, reduce PHP processing.
• Priority 2 (Medium effort): Compress and optimize all images; switch to WebP. Expected: 30–40% reduction in image file size.
• Priority 3 (Dependency): Contact hosting; confirm caching is enabled and server TTFB is as good as possible. If TTFB doesn’t improve, consider upgrading hosting.
• Priority 4 (Ongoing): Implement lazy-loading for below-fold images; minify CSS/JS.

Re-test after each major change. Run GTmetrix again to confirm improvements. Document the before/after metrics.

• Performance audits identify the specific bottlenecks on your site so you prioritize high-impact fixes.
• Start with PageSpeed Insights and GTmetrix to measure Core Web Vitals and understand where slowness originates.
• Check server response time (TTFB) first; if it’s high, hosting upgrade is often the best ROI.
• Audit plugins ruthlessly; deactivate and delete unused ones. Reduce bloat.
• Images are typically 50–70% of page weight; compress, optimize format (WebP), and lazy-load aggressively.
• Implement caching (page cache + browser cache) to serve content faster on repeat visits.
• Re-test after each optimization to confirm impact and focus resources on what moves the needle.

Performance optimization isn’t a one-time task—it’s ongoing maintenance. Check back quarterly as you add new content and plugins. If you’d like a deep-dive audit and optimization plan tailored to your site, we can help. Our maintenance and hosting services include ongoing performance monitoring and optimization.

Get Your Performance Audit

• Google – Web Vitals
• Google PageSpeed Insights
• Google Search Console – Core Web Vitals Report
• GTmetrix – Performance Analysis
• WordPress Performance Team – Best Practices
• TinyJPG – Image Compression
• Google Squoosh – Image Optimizer