How to Optimize Slow WordPress: A Layered Approach from OPcache to Caching, Database, and Images

When WordPress becomes slow, the most common approach is to “install a caching plugin.” This can solve some problems, but if the bottleneck isn’t there, it will still be slow after installation—and you might mistakenly think “it’s already optimized,” stopping further investigation.

The correct order is first identify which layer has the bottleneck, then optimize that specific layer. Below, we explain from bottom to top, providing actionable steps for each layer.

Establish a Baseline Before Acting

# Measure Time To First Byte (TTFB) — this metric reflects server processing time
curl -o /dev/null -s -w 'DNS=%{time_namelookup} Connect=%{time_connect} TTFB=%{time_starttransfer} Total=%{time_total}n' https://example.com/

# Check where PHP is slow (slowlog must be enabled)
tail -f /var/log/php-fpm/www-slow.log

# Check if MySQL slow query log is enabled
mysql -e "SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time';"

TTFB is the key indicator: a high TTFB indicates a slow server (backend issue), while a low TTFB with a still-slow page indicates frontend resource issues. This step alone can cut your optimization direction in half.

Layer 1: PHP OPcache (Highest Cost-Performance Ratio)

WordPress compiles a large number of PHP files with every request. OPcache caches these compiled results, offering the largest potential gain without changing any code.

; php.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1

# Verify it is enabled
php -i | grep -i opcache.enable

Layer 2: Page Caching

Cache the dynamically generated page results directly, so requests no longer need to go through PHP and the database.

Nginx Layer (fastcgi_cache, no plugin required)

# Define cache zone within http block
fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WPCACHE:100m inactive=60m;
fastcgi_cache_key  "$scheme$request_method$host$request_uri";

server {
    set $skip_cache 0;
    # Do not cache logged-in users, POST requests, or requests with query strings
    if ($request_method = POST)        { set $skip_cache 1; }
    if ($query_string != "")           { set $skip_cache 1; }
    if ($http_cookie ~* "wordpress_logged_in") { set $skip_cache 1; }

    location ~ .php$ {
        fastcgi_cache        WPCACHE;
        fastcgi_cache_valid  200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache     $skip_cache;
        add_header X-Cache   $upstream_cache_status;
        # ... other fastcgi parameters
    }
}

# Verify hit rate: Look for X-Cache: HIT
curl -I https://example.com/ | grep -i x-cache

Layer 3: Object Caching (Redis)

Page caching handles “entire pages,” while object caching handles “repeated database queries”—especially effective for WooCommerce, admin areas, and requests that cannot be fully cached as whole pages.

# Install and start Redis
yum install -y redis && systemctl enable --now redis

# PHP extension
pecl install redis && echo 'extension=redis.so' > /etc/php.d/50-redis.ini

// wp-config.php
define( 'WP_REDIS_HOST',     '127.0.0.1' );
define( 'WP_REDIS_PORT',     6379 );
define( 'WP_CACHE_KEY_SALT', 'example.com_' );

# Verify it is working
redis-cli ping        # Expect PONG
redis-cli info keyspace

Layer 4: Database

# Clean up post revisions (greater benefit for older sites)
wp post delete $(wp post list --post_type='revision' --format=ids) --force

# Clean up expired transients
wp transient delete --expired

# Optimize tables
wp db optimize

# View slow queries
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

-- Enable slow query log (long_query_time is in seconds)
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- Find queries not using indexes
EXPLAIN SELECT * FROM wp_postmeta WHERE meta_key = 'xxx';

Layer 5: Images and Frontend

# Batch convert to WebP (requires cwebp installed)
find /var/www/html/wp-content/uploads -name '*.jpg' -exec sh -c 'cwebp -q 80 "$1" -o "${1%.jpg}.webp"' _ {} ;

# Check how much space images occupy
du -sh /var/www/html/wp-content/uploads

An out-of-control uploads directory is one of the hidden causes of slowness in older sites—uploading hundreds of MB of original images directly inflates page size.

Decision Tree

WordPress is Slow
├─ Measure TTFB with curl
│  ├─ High TTFB (>1s) → Backend bottleneck, investigate further
│  │  ├─ OPcache not enabled       → Enable it (highest ROI)
│  │  ├─ No page cache             → Use fastcgi_cache or a caching plugin
│  │  ├─ Many dynamic requests/store/admin → Add Redis object cache
│  │  ├─ Slow queries in slowlog   → Optimize queries + add indexes
│  │  └─ Not enough php-fpm processes → Increase pm.max_children (watch memory)
│  └─ Low TTFB but slow page → Frontend bottleneck
│     ├─ Large/uncompressed images → WebP + compression
│     ├─ Too many requests         → Minify/combine + CDN
│     └─ External scripts blocking → Async load third-party JS

Scenario Walkthrough: Homepage takes over 3 seconds, config changes yield little result

Symptom: A content-based site’s homepage takes over 3 seconds to load, and backend operations are noticeably sluggish.
Previous adjustments to web service parameters and database connections had little effect.

1. Measure layered latency first, don’t rely on intuition → Use request timing to split DNS resolution, connection, TTFB, and total time.
   Found that TTFB accounted for most of the time, indicating the bottleneck was in server-side generation, not network or frontend.
2. Check if PHP bytecode caching is enabled → It was not enabled, meaning scripts were recompiled with every request.
   This is the highest ROI, lowest effort layer, so fix it first.
3. Enable and verify it actually works → Don’t just change settings; check hit rates in cache statistics to confirm requests are hitting the cache.
4. Add a full-page cache layer → Cache output for anonymous visitors,
   while explicitly excluding personalized paths like login states or shopping carts.
5. Handle accumulated database overhead → Clean up historical revisions and redundant data, and add indexes for slow queries.
6. Remeasure and solidify → Remeasure with the same set of requests to confirm significant TTFB reduction; document key configurations and priorities.

# Layered timing: Locate the bottleneck layer first
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}n' https://example.com/

# Check if OPcache is enabled and its hit rate
php -i | grep -iE 'opcache.enable|opcache.memory_consumption|opcache.validate_timestamps'

# Clean up historical accumulation in data (backup first)
wp post delete $(wp post list --post_type='revision' --format=ids) --allow-root
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_%'" --allow-root

Root Cause: Lack of bytecode caching caused PHP to recompile with every request; lack of full-page caching meant all anonymous traffic penetrated to the backend. Previous parameter adjustments targeted the wrong layers, hence minimal results.

Two Key Takeaways:

• Measure layered latency before optimizing; don’t tweak parameters based on gut feeling.
  Slow TTFB is a backend issue; fast TTFB but slow total time is a frontend resource issue—the approaches differ completely.
• Prioritize bytecode caching and full-page caching.
  They have low impact, direct benefits, and don’t affect business logic; finish these before considering costly changes like switching themes or plugins.

Cost vs. Benefit Comparison of Five-Layer Optimization

This table answers a practical question: What to do first when time is limited? The answer is OPcache—it has the smallest change, most direct benefit,
and doesn’t affect frontend logic. You can immediately verify effectiveness with php -i | grep opcache and hit rates.

Conversely, switching themes or plugins should be the last resort. Blaming slowness on “heavy themes” is a common misjudgment:
the same theme often performs equally well after enabling OPcache and page caching. Finish the free layers first, then consider switching.

8 Common Pitfalls

1. Acting without checking TTFB: Backend and frontend bottlenecks require different treatments; a 5-second test saves hours.
2. Forgetting to enable OPcache: Most common and easiest to fix, yet often yields the biggest gains.
3. Assuming caching plugins work: Must verify hits using response headers.
4. Caching logged-in users: If rules don’t exclude wordpress_logged_in, both backend and frontend will malfunction.
5. Exposing Redis port to public internet: Exposing 6379 is a severe security risk; listen only on localhost.
6. Blindly increasing php-fpm process count: Process count × per-process memory exceeding available RAM triggers OOM, resulting in 502 errors.
7. Never cleaning up revisions: On old sites, revisions can dominate wp_posts, slowing all queries.
8. Optimizing without measuring: Changing settings without comparing data means you won’t know if it worked.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and competitors, provided here for reference only, not fictional tickets from our site):

10***09 2024-03-18 5.0 Convenient and stable | Clean interface | Comprehensive after-sales support (User did not fill in comment content)