The Problem: Default WordPress is Slow and Resource-Hungry
WordPress with default settings is slow: each page request runs 60–120 SQL queries, loads dozens of plugins, and regenerates HTML from scratch. A typical WordPress site yields TTFB 1–3 seconds, LCP exceeds 4 seconds — visitors leave before the page loads. We face such projects daily and know how to fix it. WordPress performance optimization is not a one-time action but a systematic approach that delivers measurable results. Contact us for a performance audit.
Our methodology includes a set of measures: from configuring OPcache and Redis to converting images to WebP and optimizing SQL queries. Over the years, we have conducted more than 50 audits and guarantee reducing TTFB to 200 ms and Core Web Vitals in the green zone. Practice shows that even basic optimization pays off in 2–3 months by reducing hosting load.
According to a Pingdom study, each extra 100 ms of TTFB reduces conversion by 1%.
WordPress Performance Audit: What Slows Down Your Site
Before optimization — diagnostics. Tools:
- Query Monitor — shows all SQL queries and hooks on each page
- New Relic or Tideways — PHP profiler for production
- GTmetrix / PageSpeed Insights — external Core Web Vitals metrics
Typical causes of slow performance:
- Missing PHP OPcache
- No object cache (Redis/Memcached)
- Slow plugins with non-optimized WP_Query
-
wp_optionstable with thousands of autoload options (some exceeding 1 MB) - Huge
wp_postmetatable (hundreds of thousands of records) - No page caching
How OPcache and Redis Reduce SQL Query Count
Configuring OPcache
# /etc/php/8.3/fpm/conf.d/10-opcache.ini opcache.enable=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=10000 opcache.revalidate_freq=0 opcache.validate_timestamps=0 opcache.fast_shutdown=1 opcache.jit=tracing opcache.jit_buffer_size=64m According to PHP documentation, these settings give a 30–50% reduction in PHP execution time.
Redis for Object Cache
Install Redis via apt, activate the Redis Cache plugin. Add to wp-config.php:
define('WP_CACHE_KEY_SALT', 'yourdomain.com_'); define('WP_REDIS_HOST', '127.0.0.1'); define('WP_REDIS_PORT', 6379); define('WP_REDIS_DATABASE', 0); define('WP_REDIS_TIMEOUT', 1); define('WP_REDIS_READ_TIMEOUT', 1); Redis caches WP_Query results, options (get_option), user data. On one project with 2000 posts and 50 plugins, Redis reduced SQL queries per page from 90 to 12.
Why Nginx FastCGI Cache Is Better Than Caching Plugins
For high-traffic sites, we use Nginx FastCGI Cache — it bypasses PHP and WordPress entirely.
fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; server { location ~ \.php$ { fastcgi_cache WORDPRESS; fastcgi_cache_valid 200 301 302 60m; fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache; set $skip_cache 0; if ($http_cookie ~* "wordpress_logged_in|woocommerce_cart_hash") { set $skip_cache 1; } if ($request_method = POST) { set $skip_cache 1; } fastcgi_pass unix:/var/run/php/php8.3-fpm.sock; } } Comparison:
| Metric | Nginx FastCGI Cache | Plugin (WP Super Cache) |
|---|---|---|
| TTFB | < 10 ms | 50–200 ms |
| Server load | Minimal | Higher (PHP + WordPress) |
| Setup complexity | Requires root access | Simple |
| Dynamic content bypass | More complex | Easy |
Cached pages are served with TTFB < 10 ms. Nginx FastCGI Cache is 10–20 times faster than plugins.
Database Cleanup and Image Optimization
Database Cleanup
-- Delete old revisions (keep last 5 per post) DELETE p FROM wp_posts p LEFT JOIN ( SELECT ID FROM wp_posts WHERE post_type = 'revision' ORDER BY post_date DESC LIMIT 5 ) keep ON p.ID = keep.ID WHERE p.post_type = 'revision' AND keep.ID IS NULL; -- Delete orphaned postmeta DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL; -- Analyze autoload options SELECT option_name, LENGTH(option_value) as size FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20; -- Disable autoload for unnecessary options UPDATE wp_options SET autoload = 'no' WHERE option_name IN ('_transient_some_plugin_cache', 'some_large_option'); WebP Conversion
We integrate automatic conversion upon media upload via the ShortPixel plugin or a custom Imagick handler. This allows converting all content to the modern format without manual work, saving up to 30% of traffic.
What Other Acceleration Techniques Do We Apply?
Additionally, we set up lazy loading for images, minify CSS/JS (via Autoptimize or a Webpack build), integrate CDN (Cloudflare), and use WebP with srcset. A comprehensive approach yields maximum speed gains.
Step-by-Step Optimization Plan
- Audit: profiling with Query Monitor and New Relic.
- OPcache: enable and configure JIT.
- Redis: install, configure object cache.
- Nginx cache: configure FastCGI Cache with bypass for authenticated users.
- Database: clean revisions, orphaned meta, disable autoload for large options.
- Images: convert to WebP, set up lazy loading.
- Monitoring: check Core Web Vitals via PageSpeed Insights.
What’s Included and What Results to Expect
- Detailed performance audit with a report
- Configuration of OPcache and Redis
- Nginx FastCGI Cache (or other cache) setup
- Database cleanup and optimization
- CSS/JS minification, WebP image conversion
- Recommendations for improving LCP, CLS, INP
- Guarantee: TTFB < 200 ms and Core Web Vitals in the green zone
- Documentation and team training
Typical results:
| Metric | Before | After |
|---|---|---|
| TTFB (no cache) | 800–2000 ms | 150–400 ms |
| TTFB (with FastCGI cache) | — | 5–15 ms |
| SQL queries per page | 60–120 | 5–15 |
| LCP | 3–6 s | 1–2 s |
Timelines and Experience
Basic optimization (OPcache, Redis, DB cleanup, page cache) — 2–3 days. Full audit with profiling and slow query optimization — 5–7 days. The cost is calculated individually based on complexity.
Years of experience and 50+ successful projects confirm the effectiveness of our approach. Order an audit today and get a guaranteed result.







