WordPress Performance Audit: Diagnosis and Optimization Plan
A client launched an e-commerce site on WordPress with the Avada theme and 50+ plugins. Google PageSpeed shows TTFB of 1.2 seconds and LCP of 6 seconds. Users complain about slow loading, conversion dropped by 20%. We conducted a WordPress performance audit and found: wp_options autoload is overloaded (3 MB of data), MySQL lacks indexes on the postmeta table, and OPcache is disabled. We fixed it in 2 days — load time dropped to 1.5 seconds, conversion recovered. Only measurement gives the right vector for optimization.
A WordPress performance audit is a comprehensive diagnosis of both server-side and client-side parts. We check PHP configuration (OPcache, memory limit), MySQL (indexes, slow queries), caching (page cache, object cache), frontend (CSS/JS bundles, images), and web server configuration (HTTP/2, brotli). Without such an audit, optimization at random can worsen the situation by adding new problems. Based on the results, we create a plan with priorities and precise instructions.
Why Optimization Without an Audit Is Ineffective
Many try to speed up a site blindly: enable plugins, compress images, switch hosting. Without accurate data, it's shooting in the dark. An audit reveals exactly what slows down: the server, database, plugins, or frontend. We started with a project that loaded in 8 seconds. After the audit, we found wp_options autoload overloaded, MySQL without indexes, and OPcache disabled. We fixed it in 2 days — load time dropped to 1.5 seconds. Only measurement gives the right vector.
What Tools We Use
External (simulate the user):
- Google PageSpeed Insights — Core Web Vitals assessment, recommendations
- GTmetrix — waterfall chart, filmstrip, test regions
- WebPageTest — detailed HAR, video capture, testing from different locations
- Lighthouse CLI — run from command line for automation
Internal (server side):
- Query Monitor — plugin for SQL queries, hooks, PHP time
- New Relic APM — PHP profiler
- Blackfire — detailed function profiling
Note: For reproducible results, use Lighthouse CLI with the --headless flag. Redis cache is 5 times more efficient than file-based cache.
How We Measure Metrics
Measure baseline metrics before optimization:
# Lighthouse CLI npx lighthouse https://yourdomain.com \ --output json \ --output-path ./audit-before.json \ --chrome-flags="--headless" # TTFB via curl curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \ https://yourdomain.com Analyze server time with Query Monitor: install the plugin, open any page, check Total query time (target < 50 ms), Number of queries (target < 30), slow queries (> 5 ms each), duplicate queries.
Analyze PHP and MySQL: enable slow log for PHP-FPM and slow query log for MySQL.
# Enable PHP-FPM slow log ; /etc/php/8.3/fpm/pool.d/www.conf slowlog = /var/log/php-fpm-slow.log request_slowlog_timeout = 2s -- Enable slow query log SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 0.5; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; -- Analyze with mysqldumpslow mysqldumpslow -s t -t 10 /var/log/mysql/slow.log What Is TTFB and How to Improve It
TTFB is time to first byte. If it is > 200 ms, the server or DB is slow. Main causes: no OPcache, no page cache, slow hosting. We enable OPcache, set up Redis, implement FastCGI cache — TTFB drops to 50–100 ms.
Typical Problems and Their Impact
| Problem | Impact | Fix |
|---|---|---|
| No OPcache | -40% PHP time | Enable in php.ini |
| No Redis/Memcached | -50-70% DB queries | Install object cache |
| No page cache | TTFB 500ms+ | WP Rocket / FastCGI cache |
| Unoptimized images | +2-5 MB per page | WebP + resize |
| Render-blocking JS | LCP +1-3 s | defer/async |
| Autoload options > 1 MB | +200ms per request | Clean wp_options |
| Slow plugin | +300ms | Replace or optimize |
| No CDN | +500ms for remote users | Cloudflare / BunnyCDN |
| HTTP/1.1 instead of HTTP/2 | Multiple RTT | Enable in Nginx |
| No gzip/brotli | +200-500 KB traffic | Enable in Nginx |
Core Web Vitals: Target Values
According to Google Search Central, these metrics are key for ranking. LCP (Largest Contentful Paint) should be under 2.5 seconds. LCP is a critical speed metric.
| Metric | Good | Needs Work | Poor |
|---|---|---|---|
| LCP | < 2.5 s | 2.5–4 s | > 4 s |
| INP | < 200 ms | 200–500 ms | > 500 ms |
| CLS | < 0.1 | 0.1–0.25 | > 0.25 |
| TTFB | < 200 ms | 200–800 ms | > 800 ms |
Step-by-Step Audit Plan
- Gather metrics using Lighthouse CLI, PageSpeed Insights, and WebPageTest.
- Analyze server side with Query Monitor, slow logs, and PHP profiler.
- Identify bottlenecks: slow queries, cache configuration, heavy plugins.
- Create a report with priorities and concrete instructions for each issue.
- Test fixes and re-measure to confirm improvements.
What's Included in the Report
- Measured metrics before optimization
- List of issues with priorities (critical, important, improvements)
- Specific recommendations for each issue (with code or settings)
- Projected result after fixes (expected load time reduction)
- Documentation of results, access (if needed), maintenance recommendations
Common Mistakes in Self-Optimization
- Installing too many caching plugins that conflict.
- Using images without WebP and without responsive sizes.
- Ignoring slow query log and missing database indexes.
- Disabling OPcache under high load.
- Choosing hosting based on price rather than resources.
Timeline and Pricing
A WordPress performance audit with a report and recommendations takes 1–2 days. Pricing is calculated individually based on complexity and scope. After optimization, clients save up to 30% on hosting and support. Get a consultation or order an audit — we will help improve your site's performance.