How to Reduce Server Load and Improve Website Performance: The Complete Guide

Juni 14, 2026

How to Reduce Server Load and Improve Website Performance: The Complete Guide

A slow website costs you money. Studies consistently show that a 1-second delay in page load time reduces conversions by 7%, increases bounce rates by 11%, and cuts page views by 11%. For an e-commerce store making $10,000/day, a 1-second slowdown can mean $250,000 in lost annual revenue.

But slow websites don't just hurt revenue — they consume excessive server resources, driving up hosting costs and making infrastructure scaling harder than it needs to be. The irony is that most performance problems are self-inflicted: unnecessary database queries, uncompressed assets, missing caches, and poorly configured server software.

This guide covers every layer of the stack — from the web server and PHP runtime, through application-level caching, image optimization, CDN configuration, and database tuning — with specific, actionable configurations you can apply immediately.

Understanding Server Load: Where It Comes From
Measuring Performance: Establish Your Baseline First
Web Server Optimization (Nginx/Apache)
PHP Performance Tuning
Database Optimization (MySQL/MariaDB)
Caching: The Single Biggest Performance Lever
Content Delivery Network (CDN)
Image Optimization
CSS, JavaScript, and HTML Optimization
WordPress-Specific Performance
HTTP/2 and HTTP/3
Monitoring and Maintaining Performance
Performance Optimization Checklist
FAQ
Conclusion
Additional SEO Data

Understanding Server Load: Where It Comes From

Before optimizing, you need to understand what generates server load. Every web request goes through multiple layers:

User Browser
    ↓
DNS Resolution
    ↓
TCP Connection + TLS Handshake
    ↓
Web Server (Nginx/Apache)  ← static files served here
    ↓
PHP-FPM / Application      ← dynamic requests processed here
    ↓
Database (MySQL)           ← data fetched here
    ↓
External APIs              ← slowest, most unpredictable

The Four Main Resource Bottlenecks

CPU: Excessive PHP execution, unoptimized database queries, image processing, compression

RAM: Too many concurrent PHP processes, MySQL without buffer pool tuning, memory leaks in applications

Disk I/O: Uncached database queries, excessive logging, storing sessions on disk, slow storage

Network: Large uncompressed assets, no CDN, too many HTTP requests, missing HTTP/2

What Generates the Most Load

For a typical WordPress or PHP site:

40-60% of load: Uncached database queries
20-30% of load: PHP execution (template rendering, plugin overhead)
10-20% of load: Static file serving (images, CSS, JS) — largely eliminatable with proper caching
5-10% of load: External API calls (payment gateways, social media APIs, etc.)

This means caching is the highest-ROI optimization by a significant margin.

Measuring Performance: Establish Your Baseline First

Never optimize blindly. Measure first, optimize, then measure again to confirm improvement.

Server-Side Metrics

# Real-time server resource usage
htop                    # CPU, RAM, process list
iotop                   # Disk I/O by process
nethogs                 # Network usage by process
vmstat 1 10             # System-wide CPU, memory, I/O every 1s

# Web server metrics
# Nginx:
sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

# Count requests per second from access log
tail -n 10000 /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn | head -10

# Check active Nginx connections
nginx -s status  # or:
curl <http://localhost/nginx_status>  # requires stub_status module

# PHP-FPM pool status
# Add to Nginx: location /fpm-status { fastcgi_pass ... ; }
curl <http://localhost/fpm-status>

# MySQL query stats
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Questions';"
mysql -u root -p -e "SHOW PROCESSLIST;"
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE '%slow%';"

Client-Side / Page Speed Tools

# Command-line tools
curl -w "\n\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s <https://yourdomain.com>

# Detailed timing breakdown
curl -w @- -o /dev/null -s <https://yourdomain.com> <<'EOF'
    time_namelookup:  %{time_namelookup}s
       time_connect:  %{time_connect}s
    time_appconnect:  %{time_appconnect}s
   time_pretransfer:  %{time_pretransfer}s
      time_redirect:  %{time_redirect}s
 time_starttransfer:  %{time_starttransfer}s
                    ----------
         time_total:  %{time_total}s
EOF

# Apache Bench — load test
sudo apt install apache2-utils -y
ab -n 1000 -c 50 <https://yourdomain.com/>
# -n 1000 = 1000 total requests
# -c 50 = 50 concurrent users
# Look at: Requests per second, Time per request, Failed requests

# Siege — more realistic load test
sudo apt install siege -y
siege -c 25 -t 60S <https://yourdomain.com>
# 25 concurrent users for 60 seconds

Online tools (use before and after any optimization):

Google PageSpeed Insights — Core Web Vitals, mobile/desktop score
GTmetrix — detailed waterfall, Lighthouse
WebPageTest — advanced analysis, filmstrip view, multiple locations
Pingdom — simple, good for regular checks

Key Metrics to Track

Metric	Good	Needs Work	Poor
Time to First Byte (TTFB)	< 200ms	200-500ms	> 500ms
First Contentful Paint (FCP)	< 1.8s	1.8-3s	> 3s
Largest Contentful Paint (LCP)	< 2.5s	2.5-4s	> 4s
Total Blocking Time (TBT)	< 200ms	200-600ms	> 600ms
Cumulative Layout Shift (CLS)	< 0.1	0.1-0.25	> 0.25
Page Size	< 1MB	1-3MB	> 3MB
HTTP Requests	< 50	50-100	> 100

Web Server Optimization (Nginx/Apache)

Nginx Performance Configuration

sudo nano /etc/nginx/nginx.conf

# /etc/nginx/nginx.conf — Performance-Optimized Configuration

user www-data;

# Set to number of CPU cores
# Check: nproc --all
worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 2048;  # Per worker process
    multi_accept on;           # Accept multiple connections at once
    use epoll;                 # Linux best event model
}

http {
    # ============================================================
    # BASIC SETTINGS
    # ============================================================
    sendfile on;
    tcp_nopush on;           # Send headers in one packet
    tcp_nodelay on;          # Don't buffer small packets
    keepalive_timeout 65;
    keepalive_requests 100;
    types_hash_max_size 2048;
    server_tokens off;       # Hide Nginx version (security)

    # File descriptor cache
    open_file_cache max=10000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # ============================================================
    # MIME TYPES
    # ============================================================
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # ============================================================
    # LOGGING (tune for production)
    # ============================================================
    # Buffered logging — writes in batches instead of per-request
    access_log /var/log/nginx/access.log combined buffer=512k flush=1m;
    error_log /var/log/nginx/error.log warn;

    # ============================================================
    # GZIP COMPRESSION
    # ============================================================
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;      # 1-9, 6 is good balance
    gzip_min_length 1000;   # Don't compress tiny files
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml
        application/xml+rss
        application/atom+xml
        image/svg+xml
        font/woff
        font/woff2;
    # Note: Never gzip images (JPEG, PNG, WebP) — already compressed

    # ============================================================
    # BROTLI (better than gzip, requires nginx-module-brotli)
    # ============================================================
    # brotli on;
    # brotli_comp_level 6;
    # brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

    # ============================================================
    # FASTCGI CACHE (for PHP sites)
    # ============================================================
    fastcgi_cache_path /var/cache/nginx
        levels=1:2
        keys_zone=SITE_CACHE:100m
        inactive=60m
        max_size=2g;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    fastcgi_cache_use_stale error timeout invalid_header http_500;
    fastcgi_cache_lock on;
    fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

    # ============================================================
    # RATE LIMITING
    # ============================================================
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
    limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m;

    # ============================================================
    # INCLUDE SITE CONFIGS
    # ============================================================
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Nginx Site Configuration with Caching

# /etc/nginx/sites-available/yourdomain.com

# FastCGI cache bypass rules
map $http_cookie $skip_cache {
    default 0;
    ~*"wordpress_logged_in" 1;
    ~*"comment_author" 1;
    ~*"woocommerce_items_in_cart" 1;  # WooCommerce
}

map $request_method $skip_cache_post {
    default 0;
    POST 1;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;

    root /var/www/yourdomain.com/public_html;
    index index.php index.html;

    # ============================================================
    # FASTCGI CACHE
    # ============================================================
    set $skip_reason "";

    # Skip cache for logged-in users, cart, admin, POST requests
    if ($skip_cache = 1) { set $skip_reason "cookie"; }
    if ($skip_cache_post = 1) { set $skip_reason "post"; }
    if ($request_uri ~* "/wp-admin/|/wp-login.php|/cart/|/checkout/|/my-account/") {
        set $skip_reason "admin";
    }

    fastcgi_cache SITE_CACHE;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_reason;
    fastcgi_no_cache $skip_reason;

    # Add cache status header (for debugging)
    add_header X-Cache-Status $upstream_cache_status;

    # ============================================================
    # STATIC FILE CACHING
    # ============================================================
    location ~* \.(?:css|js)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public, immutable";
    }

    location ~* \.(?:jpg|jpeg|gif|png|ico|webp|avif|svg|woff|woff2|ttf|eot)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public, immutable";
    }

    location ~* \.(?:pdf|zip|gz|tar)$ {
        expires 7d;
        add_header Cache-Control "public";
    }

    # ============================================================
    # WORDPRESS PERMALINKS
    # ============================================================
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # ============================================================
    # PHP-FPM
    # ============================================================
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;

        # FastCGI caching
        fastcgi_cache SITE_CACHE;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_reason;
        fastcgi_no_cache $skip_reason;

        # Timeouts
        fastcgi_connect_timeout 60;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
    }

    # ============================================================
    # SECURITY — DENY ACCESS TO SENSITIVE FILES
    # ============================================================
    location ~* /(wp-config\.php|\.env|\.git|\.htaccess) {
        deny all;
        return 404;
    }

    location = /xmlrpc.php {
        deny all;
        return 404;
    }

    # Apply rate limiting to login page
    location = /wp-login.php {
        limit_req zone=login burst=5 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_no_cache 1;  # Never cache login page
    }

    # ============================================================
    # BROWSER SECURITY HEADERS
    # ============================================================
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    # add_header Content-Security-Policy "default-src 'self'; ..." always;

    # HSTS (only after you're sure HTTPS is working correctly)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://yourdomain.com$request_uri;
}

# Create cache directory
sudo mkdir -p /var/cache/nginx
sudo chown www-data:www-data /var/cache/nginx

# Test and reload
sudo nginx -t
sudo systemctl reload nginx

# Clear FastCGI cache
sudo rm -rf /var/cache/nginx/*

Apache Performance Configuration

sudo nano /etc/apache2/apache2.conf

# Key Apache performance settings:

# Use mpm_event (not prefork) for better concurrency
# sudo a2dismod php8.2  # Only if using php-fpm
# sudo a2enmod proxy_fcgi
# sudo a2enconf php8.2-fpm
# sudo a2enmod mpm_event
# sudo a2dismod mpm_prefork

# /etc/apache2/conf-available/performance.conf

# KeepAlive
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

# Compression
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
    AddOutputFilterByType DEFLATE text/javascript application/javascript application/json
    AddOutputFilterByType DEFLATE application/xml image/svg+xml
</IfModule>

# Browser caching
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType text/html "access plus 1 hour"
</IfModule>

# Disable directory listing and server signature
Options -Indexes
ServerSignature Off
ServerTokens Prod

PHP Performance Tuning

PHP-FPM Pool Configuration

PHP-FPM (FastCGI Process Manager) controls how PHP processes are spawned and managed. This is often the biggest performance lever for PHP applications.

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

; /etc/php/8.2/fpm/pool.d/www.conf

[www]
user = www-data
group = www-data

; Unix socket (faster than TCP for local connections)
listen = /var/run/php/php8.2-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; ============================================================
; PROCESS MANAGER
; ============================================================

; pm = dynamic: processes scale between min and max based on load
; pm = static: fixed number of processes (predictable memory usage)
; pm = ondemand: spawn on demand, terminate when idle (low RAM, slow burst)
;
; RECOMMENDATION:
; Low RAM (512MB-1GB):   pm = ondemand
; Medium RAM (2-4GB):   pm = dynamic
; High RAM (8GB+):      pm = static
pm = dynamic

; Maximum number of child processes
; Rule of thumb: (Total RAM - OS overhead - MySQL RAM) / PHP process RAM
; A typical WordPress PHP process uses 20-50MB
; For 2GB VPS with MySQL: (2048 - 256 - 512) / 30 ≈ 42 max children
pm.max_children = 40

; Start with this many processes
pm.start_servers = 5

; Minimum idle processes
pm.min_spare_servers = 3

; Maximum idle processes
pm.max_spare_servers = 10

; Restart processes after this many requests (prevents memory leaks)
pm.max_requests = 500

; ============================================================
; PROCESS HEALTH
; ============================================================

; Status page (add to Nginx: location /fpm-status { fastcgi_pass ... ; })
pm.status_path = /fpm-status

; Ping page for monitoring
ping.path = /ping
ping.response = pong

; Slow log — log PHP scripts taking longer than this
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s

; Request terminate timeout (kill stuck PHP processes)
request_terminate_timeout = 60s

; ============================================================
; SECURITY
; ============================================================

; Limit each PHP process to 512MB
php_admin_value[memory_limit] = 512M

; Prevent directory traversal
php_admin_value[open_basedir] = /var/www/yourdomain.com/:/tmp/

; Disable dangerous functions
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen

# Calculate recommended pm.max_children
# Check current PHP process RAM usage:
ps -ylC php-fpm8.2 --sort:rss | awk 'NR>1{sum+=$8; count++} END {print "Average RSS:", sum/count/1024, "MB"}'

# Check total available RAM
free -m

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm

# Check status
curl <http://localhost/fpm-status>

PHP OPcache Configuration

OPcache precompiles PHP files to bytecode and stores them in memory. It's the single fastest PHP optimization — typically 3-5x speed improvement.

sudo nano /etc/php/8.2/fpm/conf.d/10-opcache.ini

; /etc/php/8.2/fpm/conf.d/10-opcache.ini

opcache.enable=1

; Memory for storing compiled PHP files
; Increase if you see "opcache.memory_consumption is full" warnings
opcache.memory_consumption=256

; Memory for string interning
opcache.interned_strings_buffer=16

; Maximum number of PHP files that can be cached
; Use: find /var/www -name "*.php" | wc -l
opcache.max_accelerated_files=20000

; Validate file timestamps every N seconds (0 = never, fastest but requires manual cache clear)
; Use 0 on production (deploy scripts clear cache), 2 on staging
opcache.revalidate_freq=0

; Don't validate file timestamps if you trust your deployment process
; (Deploy scripts should call opcache_reset() or restart php-fpm)
opcache.validate_timestamps=0

; Enable file existence check cache
opcache.enable_file_override=1

; Huge pages (Linux kernel optimization)
opcache.huge_code_pages=1

; JIT compilation (PHP 8.x — significant speedup for CPU-bound code)
opcache.jit=1255
opcache.jit_buffer_size=128M
; JIT modes:
; 0 = disabled
; 1 = tracing JIT (fastest for most apps)
; 1255 = function JIT with optimizations

# Reload PHP-FPM after config changes
sudo systemctl reload php8.2-fpm

# Verify OPcache status
php -r "var_export(opcache_get_status()['opcache_enabled']);"
# Should output: true

# Clear OPcache (after deployment)
php -r "opcache_reset();"
# Or restart PHP-FPM:
sudo systemctl reload php8.2-fpm

PHP Configuration for Performance

sudo nano /etc/php/8.2/fpm/php.ini

; Key performance settings in php.ini

; Timezone (avoid unnecessary system calls)
date.timezone = Asia/Jakarta

; Disable error display on production
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log

; Session handling
; Use Redis for sessions if available (much faster than files)
; session.save_handler = redis
; session.save_path = "tcp://127.0.0.1:6379"
session.save_handler = files
session.save_path = /tmp
session.gc_maxlifetime = 1440

; Realpath cache — cache filesystem stat() calls
realpath_cache_size = 4096k
realpath_cache_ttl = 600

; File uploads
upload_max_filesize = 64M
post_max_size = 64M

; Script limits
memory_limit = 256M
max_execution_time = 60
max_input_time = 60

; Disable functions not needed
expose_php = Off

Database Optimization (MySQL/MariaDB)

Database performance is usually the single biggest bottleneck. Poor queries can make even the best server hardware feel slow.

MySQL Configuration Tuning

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]

# ============================================================
# INNODB BUFFER POOL (most important setting)
# ============================================================
# This is the RAM MySQL uses to cache data and indexes
# Set to 50-70% of total RAM if MySQL is the primary service
# For a 4GB VPS: 2-2.5GB
# For a 2GB VPS: 768MB-1GB
innodb_buffer_pool_size = 1G

# For larger buffer pools, use multiple instances (1 per GB)
innodb_buffer_pool_instances = 2

# ============================================================
# INNODB LOG FILES
# ============================================================
# Larger log files = better write performance, slower crash recovery
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M

# ============================================================
# INNODB I/O
# ============================================================
# O_DIRECT = bypass OS buffer cache, avoids double caching
innodb_flush_method = O_DIRECT

# How often to flush data to disk:
# 1 = safest (flush after every commit) — use for financial data
# 2 = good balance (flush every second)
innodb_flush_log_at_trx_commit = 2

# I/O capacity (IOPS your storage can handle)
# SSD: 2000-10000, NVMe: 10000-100000
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

# Read/write threads
innodb_read_io_threads = 4
innodb_write_io_threads = 4

# ============================================================
# CONNECTIONS
# ============================================================
# Maximum concurrent connections
max_connections = 200

# Thread cache (reuse threads instead of creating new ones)
thread_cache_size = 16

# Connection timeout
wait_timeout = 300
interactive_timeout = 300

# ============================================================
# QUERY CACHE (DISABLED in MySQL 8.0 — removed in 8.0.20)
# ============================================================
# Do NOT set query_cache_type or query_cache_size in MySQL 8.0
# Use application-level caching (Redis/Memcached) instead

# ============================================================
# SLOW QUERY LOG
# ============================================================
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1         # Log queries taking more than 1 second
log_queries_not_using_indexes = 1  # Log queries without indexes
min_examined_row_limit = 100        # Only log if > 100 rows examined

# ============================================================
# BINARY LOG (for replication/point-in-time recovery)
# ============================================================
# Disable if you don't need replication (saves I/O)
# skip-log-bin = 1

# ============================================================
# TEMPORARY TABLES
# ============================================================
tmp_table_size = 256M
max_heap_table_size = 256M
# If temp tables exceed this, they spill to disk (slow)

# ============================================================
# SORT BUFFER
# ============================================================
sort_buffer_size = 4M
join_buffer_size = 4M
read_buffer_size = 2M
read_rnd_buffer_size = 8M

# ============================================================
# TABLE CACHE
# ============================================================
table_open_cache = 4000
table_definition_cache = 2000

[mysqld_safe]
log-error = /var/log/mysql/error.log
pid-file = /var/run/mysqld/mysqld.pid

# Apply changes
sudo systemctl restart mysql

# Verify key settings
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
mysql -u root -p -e "SHOW VARIABLES LIKE 'slow_query_log';"

# Check buffer pool hit rate (should be > 99%)
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"
# Formula: 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) = hit rate

Query Optimization

-- Analyze slow queries from the slow query log
-- Install pt-query-digest (Percona Toolkit)
sudo apt install percona-toolkit -y
pt-query-digest /var/log/mysql/slow.log | head -100

-- View currently running queries
SHOW PROCESSLIST;
-- or:
SELECT * FROM information_schema.PROCESSLIST WHERE time > 5;

-- Kill a specific query
KILL QUERY 1234;  -- replace with Process ID

-- Explain a query (see how MySQL executes it)
EXPLAIN SELECT * FROM wp_posts WHERE post_status = 'publish' ORDER BY post_date DESC LIMIT 10;
-- Look for: type=ALL (full table scan, bad), rows (scanned rows, lower = better)
-- Good: type=range/ref/eq_ref/const, Using index

-- Check table indexes
SHOW INDEX FROM wp_posts;

-- Add missing index
ALTER TABLE wp_posts ADD INDEX idx_post_status_date (post_status, post_date);

-- Analyze table statistics (helps query planner)
ANALYZE TABLE wp_posts;
OPTIMIZE TABLE wp_posts;  -- Reclaim space, defragment (caution on large tables)

-- Check table sizes
SELECT 
    table_name,
    ROUND(data_length/1024/1024, 2) AS data_MB,
    ROUND(index_length/1024/1024, 2) AS index_MB,
    ROUND((data_length + index_length)/1024/1024, 2) AS total_MB
FROM information_schema.TABLES 
WHERE table_schema = 'mysite_db'
ORDER BY total_MB DESC;

Database Connection Pooling with PgBouncer (for high-traffic sites)

For sites with many concurrent users, database connection overhead becomes significant. ProxySQL can pool MySQL connections:

# Install ProxySQL
wget <https://github.com/sysown/proxysql/releases/download/v2.5.5/proxysql_2.5.5-ubuntu22_amd64.deb>
sudo dpkg -i proxysql_2.5.5-ubuntu22_amd64.deb
sudo systemctl enable proxysql
sudo systemctl start proxysql

# Configure in /etc/proxysql.cnf
# Set max_connections, connection_pool settings
# Applications connect to ProxySQL (port 6033) instead of MySQL directly

Caching: The Single Biggest Performance Lever

Caching eliminates redundant work. A cached page served from memory is 100-1000x faster than a dynamically generated one.

Caching Layers (from fastest to slowest)

Layer 1: Browser Cache       — Instant (0ms), no server hit
Layer 2: CDN Cache           — ~10-50ms, serves from edge
Layer 3: Web Server Cache    — ~1-5ms (Nginx FastCGI cache)
Layer 4: Application Cache   — ~5-20ms (Redis/Memcached)
Layer 5: Database Query Cache — ~20-200ms (Redis)
Layer 6: Database            — ~50-500ms (uncached queries)
Layer 7: External APIs       — ~100ms-5s (slowest, always cache)

Redis Installation and Configuration

Redis is an in-memory data store used for caching, sessions, and queues.

# Install Redis
sudo apt install redis-server -y

# Configure Redis
sudo nano /etc/redis/redis.conf

# /etc/redis/redis.conf — Production Configuration

# Listen on loopback only (never expose Redis to the internet)
bind 127.0.0.1 ::1

# Set a password
requirepass YourStrongRedisPassword123!

# Memory limit
maxmemory 512mb

# Eviction policy when memory is full:
# allkeys-lru: evict least recently used keys (best for cache)
# volatile-lru: evict LRU keys with TTL set
# noeviction: return errors when full (bad for cache, ok for queues)
maxmemory-policy allkeys-lru

# Persist to disk (disable for pure cache workload — faster)
# save ""
# appendonly no

# Or keep periodic snapshots:
save 900 1      # Save after 900s if at least 1 key changed
save 300 10     # Save after 300s if at least 10 keys changed
save 60 10000   # Save after 60s if at least 10000 keys changed

# Log level
loglevel notice
logfile /var/log/redis/redis-server.log

# Start and enable Redis
sudo systemctl enable redis
sudo systemctl start redis

# Test connection
redis-cli -a YourStrongRedisPassword123! ping
# Output: PONG

# Monitor Redis in real time
redis-cli -a password monitor

# Check memory usage
redis-cli -a password info memory

# Check hit/miss ratio
redis-cli -a password info stats | grep -E 'keyspace_hits|keyspace_misses'
# Hit rate = hits / (hits + misses). Good: > 90%

PHP Sessions in Redis

sudo nano /etc/php/8.2/fpm/php.ini

# Change:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=YourStrongRedisPassword123!"

# Restart PHP-FPM
sudo systemctl reload php8.2-fpm

Object Caching Pattern (PHP)

<?php
// Generic Redis object cache pattern

class Cache {
    private static $redis = null;
    
    public static function connect() {
        if (self::$redis === null) {
            self::$redis = new Redis();
            self::$redis->connect('127.0.0.1', 6379);
            self::$redis->auth('YourStrongRedisPassword123!');
        }
        return self::$redis;
    }
    
    public static function get($key) {
        $data = self::connect()->get('cache:' . $key);
        return $data ? unserialize($data) : null;
    }
    
    public static function set($key, $value, $ttl = 3600) {
        self::connect()->setex('cache:' . $key, $ttl, serialize($value));
    }
    
    public static function delete($key) {
        self::connect()->del('cache:' . $key);
    }
}

// Usage:
$cacheKey = 'homepage_posts';
$posts = Cache::get($cacheKey);

if ($posts === null) {
    // Cache miss — fetch from database
    $posts = $db->query("SELECT * FROM posts WHERE status = 'publish' ORDER BY date DESC LIMIT 10");
    Cache::set($cacheKey, $posts, 3600);  // Cache for 1 hour
}

// Use $posts ...

Full-Page Caching Strategy

<?php
// Full-page cache with Redis
// Place this at the very top of index.php or bootstrap file

$shouldCache = (
    $_SERVER['REQUEST_METHOD'] === 'GET' &&
    !isset($_SESSION['user_id']) &&      // Don't cache logged-in users
    empty($_COOKIE['cart_items'])         // Don't cache cart pages
);

if ($shouldCache) {
    $cacheKey = 'page:' . md5($_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
    $cached = Cache::get($cacheKey);
    
    if ($cached !== null) {
        echo $cached;
        exit;  // Serve cached page, skip all application processing
    }
    
    // Start output buffering to capture the response
    ob_start();
}

// ... normal application processing ...

if ($shouldCache) {
    $output = ob_get_contents();
    Cache::set($cacheKey, $output, 600);  // Cache for 10 minutes
    ob_end_flush();
}

Content Delivery Network (CDN)

A CDN distributes your static assets (images, CSS, JS) across global edge servers, serving them from locations geographically close to your users. This alone can cut page load times by 50-80% for international audiences.

Cloudflare (Free Tier — Highly Recommended)

Cloudflare is the easiest CDN to set up and provides significant benefits even on the free tier:

# Setup: Change your domain's nameservers to Cloudflare
# No software to install on your server
# Cloudflare acts as a reverse proxy between users and your server

# Cloudflare free tier provides:
# - Global CDN (200+ edge locations)
# - DDoS protection
# - HTTPS
# - Caching rules
# - Minification of HTML/CSS/JS
# - Bot protection

Recommended Cloudflare settings:

SSL/TLS → Full (Strict) — prevents mixed content issues
Speed → Optimization → Auto Minify: ✓ HTML, CSS, JavaScript
Speed → Optimization → Brotli: On
Caching → Caching Level: Standard
Caching → Browser Cache TTL: 1 year (let Cloudflare handle invalidation)
Rules → Page Rules:
  - *yourdomain.com/wp-admin/* → Cache Level: Bypass
  - *yourdomain.com/wp-login.php → Cache Level: Bypass
  - *.yourdomain.com/feed/* → Cache Level: Bypass

Cache Invalidation with Cloudflare API

# Purge Cloudflare cache programmatically (useful in deploy scripts)

CF_ZONE_ID="your_zone_id"
CF_API_TOKEN="your_api_token"

# Purge entire cache
curl -X POST "<https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache>" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

# Purge specific URLs
curl -X POST "<https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache>" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["<https://yourdomain.com/style.css","https://yourdomain.com/app.js>"]}'

Self-Hosted CDN with Varnish Cache

For sites that can't use Cloudflare or need more control:

# Install Varnish
sudo apt install varnish -y

# Configure Varnish to sit in front of Nginx
# Varnish listens on port 80, Nginx on port 8080

# /etc/varnish/default.vcl

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";  # Nginx listens on 8080
    .connect_timeout = 5s;
    .first_byte_timeout = 30s;
    .between_bytes_timeout = 10s;
}

sub vcl_recv {
    # Don't cache POST requests
    if (req.method == "POST") {
        return (pass);
    }
    
    # Don't cache logged-in WordPress users
    if (req.http.Cookie ~ "wordpress_logged_in") {
        return (pass);
    }
    
    # Remove cookies from static files so Varnish can cache them
    if (req.url ~ "\.(css|js|png|jpg|jpeg|gif|ico|woff|woff2|svg)") {
        unset req.http.Cookie;
    }
}

sub vcl_backend_response {
    # Cache static files for 1 year
    if (bereq.url ~ "\.(css|js|png|jpg|jpeg|gif|ico|woff|woff2|svg)$") {
        set beresp.ttl = 365d;
        unset beresp.http.Set-Cookie;
    }
    
    # Cache HTML pages for 5 minutes
    if (beresp.http.content-type ~ "text/html") {
        set beresp.ttl = 5m;
    }
}

Image Optimization

Images are the largest component of most web pages. Proper optimization typically reduces page weight by 40-70%.

Convert to WebP/AVIF

# Install cwebp
sudo apt install webp -y

# Convert a single image
cwebp -q 80 image.jpg -o image.webp

# Batch convert all JPEG/PNG to WebP
find /var/www/yourdomain.com -type f \( -name '*.jpg' -o -name '*.jpeg' -o -name '*.png' \) \
  -exec sh -c 'cwebp -q 85 "$1" -o "${1%.*}.webp"' _ {} \;

# Compare sizes
ls -lh image.jpg image.webp

# Install imagemagick for AVIF (even better compression than WebP)
sudo apt install imagemagick libheif-dev -y

# Convert to AVIF
convert image.jpg -quality 80 image.avif

# Batch convert to AVIF
find /var/www/yourdomain.com -name '*.jpg' -exec sh -c 'convert "$1" -quality 85 "${1%.*}.avif"' _ {} \;

Nginx: Serve WebP Automatically

# /etc/nginx/conf.d/webp.conf

map $http_accept $webp_suffix {
    default "";
    "~*webp" ".webp";
}

# In your server block:
location ~* ^(.+)\.(jpg|jpeg|png)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Image Optimization Tools

# Install optimization tools
sudo apt install jpegoptim optipng pngquant gifsicle -y

# Optimize JPEG files (in-place, 85% quality)
find /var/www/yourdomain.com -name '*.jpg' -o -name '*.jpeg' | \
  xargs jpegoptim --strip-all --max=85

# Optimize PNG files (lossless)
find /var/www/yourdomain.com -name '*.png' | \
  xargs optipng -o7 -strip all

# Lossy PNG compression (usually better results)
find /var/www/yourdomain.com -name '*.png' -exec \
  pngquant --quality=70-85 --skip-if-larger --output {} {} \;

# Optimize GIF
find /var/www/yourdomain.com -name '*.gif' | \
  xargs gifsicle --optimize=3 -b

# Check SVG optimization
sudo apt install nodejs npm -y
sudo npm install -g svgo
svgo --folder /var/www/yourdomain.com --recursive

Responsive Images in HTML

<!-- Use srcset for responsive images -->
<img 
  src="hero-800.jpg" 
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  alt="Hero image"
  loading="lazy"
  decoding="async"
  width="1200" 
  height="600"
/>

<!-- Use picture element for WebP with JPEG fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600" loading="lazy">
</picture>

<!-- Critical images: preload to avoid LCP penalty -->
<link rel="preload" as="image" href="hero.webp" type="image/webp">

Lazy Loading

<!-- Native lazy loading (supported in all modern browsers) -->
<img src="image.jpg" alt="..." loading="lazy">
<iframe src="video.html" loading="lazy"></iframe>

<!-- Don't lazy-load above-the-fold images -->
<img src="hero.jpg" alt="..." loading="eager">  <!-- or no loading attribute -->

CSS, JavaScript, and HTML Optimization

Minification and Bundling

# Install build tools
sudo apt install nodejs npm -y
npm install -g cssnano terser html-minifier-terser

# Minify CSS
cssno styles.css > styles.min.css
# Or: npx cssnano styles.css styles.min.css

# Minify JavaScript
terser app.js --compress --mangle --output app.min.js

# Minify HTML
html-minifier-terser \
  --collapse-whitespace \
  --remove-comments \
  --remove-optional-tags \
  --remove-redundant-attributes \
  --remove-script-type-attributes \
  --minify-js true \
  --minify-css true \
  -o index.min.html index.html

# Bundle multiple JS files into one (reduces HTTP requests)
# Using a bundler like Webpack or esbuild:
npx esbuild src/app.js --bundle --minify --outfile=dist/app.min.js

Critical CSS

Inlining critical CSS (styles for above-the-fold content) eliminates render-blocking:

# Install critical CSS extractor
npm install -g critical

critical index.html \
  --base /var/www/yourdomain.com/public_html \
  --inline \
  --width 1300 \
  --height 900 \
  > index_critical.html

# This inlines CSS needed for above-the-fold content
# Non-critical CSS is loaded asynchronously

<!-- Manual critical CSS pattern -->
<head>
  <!-- Critical CSS inlined in <style> tag -->
  <style>
    /* Only styles needed for above-the-fold content */
    body { margin: 0; font-family: sans-serif; }
    header { background: #333; color: white; padding: 1rem; }
    .hero { height: 500px; background: url('hero.webp') center/cover; }
  </style>

  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>

Resource Hints

<head>
  <!-- Preconnect to external domains (reduces connection overhead) -->
  <link rel="preconnect" href="<https://fonts.googleapis.com>">
  <link rel="preconnect" href="<https://cdn.yourdomain.com>" crossorigin>
  <link rel="preconnect" href="<https://www.googletagmanager.com>">

  <!-- DNS-prefetch (lighter than preconnect) -->
  <link rel="dns-prefetch" href="<https://analytics.google.com>">

  <!-- Preload critical resources -->
  <link rel="preload" href="/fonts/body-font.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/css/critical.css" as="style">
  <link rel="preload" href="/hero.webp" as="image" type="image/webp">

  <!-- Prefetch pages the user is likely to visit next -->
  <link rel="prefetch" href="/blog/">
</head>

<!-- Defer non-critical JavaScript -->
<script src="analytics.js" defer></script>
<script src="app.js" type="module"></script>  <!-- ES modules auto-defer -->

<!-- Async for truly independent scripts -->
<script src="ads.js" async></script>

HTTP Cache Headers

# In Nginx — set correct cache headers for all resource types

# Immutable assets (versioned/hashed filenames like style.abc123.css)
location ~* \.(css|js|woff|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    # immutable = browser won't revalidate until TTL expires
}

# Images
location ~* \.(jpg|jpeg|png|gif|ico|webp|avif|svg)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# HTML — short cache or no cache
location ~* \.html$ {
    expires 1h;
    add_header Cache-Control "public, max-age=3600, must-revalidate";
}

# Dynamic PHP — no browser cache
location ~ \.php$ {
    add_header Cache-Control "no-store, no-cache, must-revalidate";
    # ... fastcgi config ...
}

WordPress-Specific Performance

WordPress has unique performance considerations due to its plugin architecture.

WordPress Object Cache with Redis

# Install WP-CLI
curl -O <https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar>
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# Install Redis Object Cache plugin
wp plugin install redis-cache --activate --path=/var/www/yourdomain.com/public_html

# Add to wp-config.php:
echo "define('WP_REDIS_HOST', '127.0.0.1');" >> /var/www/yourdomain.com/public_html/wp-config.php
echo "define('WP_REDIS_PORT', 6379);" >> /var/www/yourdomain.com/public_html/wp-config.php
echo "define('WP_REDIS_PASSWORD', 'YourStrongRedisPassword123!');" >> /var/www/yourdomain.com/public_html/wp-config.php
echo "define('WP_REDIS_DATABASE', 0);" >> /var/www/yourdomain.com/public_html/wp-config.php
echo "define('WP_REDIS_TIMEOUT', 1);" >> /var/www/yourdomain.com/public_html/wp-config.php
echo "define('WP_REDIS_READ_TIMEOUT', 1);" >> /var/www/yourdomain.com/public_html/wp-config.php

# Enable the cache
wp redis enable --path=/var/www/yourdomain.com/public_html

# Check status
wp redis status --path=/var/www/yourdomain.com/public_html

WordPress Configuration for Performance

<?php
// wp-config.php — Performance settings

// Reduce the number of post revisions stored
define('WP_POST_REVISIONS', 5);

// Disable auto-save every 60 seconds (or increase interval)
define('AUTOSAVE_INTERVAL', 300);

// Move wp-content to a different location (optional)
// define('WP_CONTENT_DIR', dirname(__FILE__) . '/content');
// define('WP_CONTENT_URL', '<https://yourdomain.com/content>');

// Increase memory limit
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// Disable file editor in admin (security + performance)
define('DISALLOW_FILE_EDIT', true);

// Disable automatic updates if you manage them manually
// define('AUTOMATIC_UPDATER_DISABLED', true);

// Disable CONCATENATE_SCRIPTS (use a proper bundler instead)
define('CONCATENATE_SCRIPTS', false);

// Table prefix (change from default 'wp_' for minor security benefit)
$table_prefix = 'wp_';

WordPress Database Cleanup

WordPress databases accumulate cruft that slows queries:

-- Run these periodically to clean up the WordPress database

-- Remove post revisions older than 30 days
DELETE FROM wp_posts 
WHERE post_type = 'revision' 
AND post_modified < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Remove auto-draft posts older than 7 days
DELETE FROM wp_posts 
WHERE post_status = 'auto-draft' 
AND post_modified < DATE_SUB(NOW(), INTERVAL 7 DAY);

-- Remove orphaned post meta
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

-- Remove orphaned term relationships
DELETE tr FROM wp_term_relationships tr
INNER JOIN wp_posts p ON p.ID = tr.object_id
WHERE p.post_type NOT IN ('post', 'page', 'your_custom_post_type');

-- Remove expired transients
DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_name NOT LIKE '_transient_timeout_%'
AND REPLACE(option_name, '_transient_', '_transient_timeout_') NOT IN (
    SELECT option_name FROM (
        SELECT option_name FROM wp_options 
        WHERE option_name LIKE '_transient_timeout_%'
    ) AS t
);

-- Clean up spam and trash comments
DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = 'trash';
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_ID FROM wp_comments);

-- Optimize tables after cleanup
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments, wp_commentmeta;

# Via WP-CLI
wp transient delete --all --path=/var/www/yourdomain.com/public_html
wp post delete $(wp post list --post_status=auto-draft --format=ids) --force
wp db optimize --path=/var/www/yourdomain.com/public_html

Recommended WordPress Performance Plugins

Plugin	Purpose	Free?
WP Rocket	All-in-one caching, best results	Paid (~$59/yr)
LiteSpeed Cache	Full-page cache (LiteSpeed server)	Free
W3 Total Cache	Comprehensive caching	Free/Pro
Autoptimize	CSS/JS/HTML minification, defer	Free
Redis Object Cache	WordPress object cache driver	Free
Smush / ShortPixel	Image compression	Free/Pro
Asset CleanUp	Remove unused CSS/JS per page	Free
Query Monitor	Debug slow queries and hooks	Free (dev tool)

HTTP/2 and HTTP/3

Enable HTTP/2 in Nginx

# In Nginx, add http2 to the listen directive
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    # ...
}

# Verify HTTP/2 is working
curl -I --http2 <https://yourdomain.com> 2>&1 | grep -i 'HTTP/2\|h2'
# Should show: HTTP/2 200

# Or use:
npx is-http2 yourdomain.com

HTTP/2 benefits vs HTTP/1.1:

Multiplexing: multiple requests over one connection (eliminates head-of-line blocking)
Header compression (HPACK): reduces overhead for repeat requests
Server push: server can send assets before client requests them
Binary protocol: more efficient than HTTP/1.1 text protocol

Enable HTTP/3 (QUIC)

HTTP/3 uses QUIC (UDP-based), which is especially beneficial on mobile and high-latency connections:

# HTTP/3 requires a newer Nginx build with QUIC support
# Available in Nginx 1.25.0+ (mainline)

# Check version:
nginx -v
# If < 1.25.0, upgrade from Nginx mainline repository:
curl <https://nginx.org/keys/nginx_signing.key> | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] <http://nginx.org/packages/mainline/ubuntu> $(lsb_release -cs) nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update && sudo apt install nginx -y

# Nginx HTTP/3 configuration
server {
    listen 443 ssl http2;
    listen 443 quic reuseport;  # HTTP/3
    listen [::]:443 ssl http2;
    listen [::]:443 quic reuseport;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Tell clients to use HTTP/3 next time
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # ...
}

# Verify HTTP/3
curl --http3 -I <https://yourdomain.com>
# Check: HTTP/3 200

Monitoring and Maintaining Performance

Real-Time Monitoring

# Install Netdata (comprehensive real-time monitoring)
curl <https://my-netdata.io/kickstart.sh> > /tmp/netdata.sh
sudo bash /tmp/netdata.sh --non-interactive

# Access: <http://your-vps-ip:19999>
# Default monitors: CPU, RAM, disk, network, Nginx, MySQL, PHP-FPM, Redis
# No configuration needed for basic setup

# Install Prometheus + Grafana for advanced monitoring
# Prometheus scrapes metrics, Grafana visualizes them
sudo apt install prometheus -y

# Nginx Prometheus exporter
sudo apt install prometheus-nginx-exporter -y

# MySQL Prometheus exporter
wget <https://github.com/prometheus/mysqld_exporter/releases/download/v0.15.0/mysqld_exporter-0.15.0.linux-amd64.tar.gz>
tar xvf mysqld_exporter-*.tar.gz
sudo mv mysqld_exporter-*/mysqld_exporter /usr/local/bin/

Log Analysis

# Top requested pages
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Top 404 errors
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Slowest pages (if $request_time is logged)
awk '{print $NF, $7}' /var/log/nginx/access.log | sort -rn | head -20

# Requests per hour (traffic pattern)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | sort | uniq -c

# Bandwidth by response code
awk '{sum[$9] += $10} END {for (code in sum) print code, sum[code]/1024/1024 " MB"}' /var/log/nginx/access.log

# GoAccess — beautiful web-based log analysis
sudo apt install goaccess -y
goaccess /var/log/nginx/access.log --log-format=COMBINED -o /var/www/yourdomain.com/public_html/report.html
# View: <https://yourdomain.com/report.html>

Automated Performance Alerts

# /usr/local/bin/server-health-check.sh
#!/bin/bash

ADMIN_EMAIL="admin@yourdomain.com"
HOSTNAME=$(hostname)

# Check CPU load (alert if > 80%)
CPU_USAGE=$(top -bn1 | grep 'Cpu(s)' | awk '{print $2}' | cut -d. -f1)
if [ $CPU_USAGE -gt 80 ]; then
    echo "HIGH CPU: $CPU_USAGE%" | mail -s "[$HOSTNAME] CPU Alert" $ADMIN_EMAIL
fi

# Check RAM usage (alert if > 90%)
RAM_USAGE=$(free | awk '/Mem:/{printf "%.0f", $3/$2*100}')
if [ $RAM_USAGE -gt 90 ]; then
    echo "HIGH RAM: $RAM_USAGE%" | mail -s "[$HOSTNAME] RAM Alert" $ADMIN_EMAIL
fi

# Check disk usage (alert if > 80%)
DISK_USAGE=$(df / | awk 'NR==2{print $5}' | cut -d% -f1)
if [ $DISK_USAGE -gt 80 ]; then
    echo "HIGH DISK: $DISK_USAGE%" | mail -s "[$HOSTNAME] Disk Alert" $ADMIN_EMAIL
fi

# Check Nginx is running
if ! systemctl is-active --quiet nginx; then
    echo "Nginx is DOWN!" | mail -s "[$HOSTNAME] NGINX DOWN" $ADMIN_EMAIL
    systemctl start nginx  # Try to restart
fi

# Check MySQL is running
if ! systemctl is-active --quiet mysql; then
    echo "MySQL is DOWN!" | mail -s "[$HOSTNAME] MYSQL DOWN" $ADMIN_EMAIL
    systemctl start mysql
fi

# Schedule: crontab -e
# */5 * * * * /usr/local/bin/server-health-check.sh

Performance Optimization Checklist

Web Server:

[ ] Nginx worker_processes set to CPU core count
[ ] Gzip compression enabled for all text content
[ ] Brotli compression enabled (if available)
[ ] open_file_cache configured
[ ] Buffered logging enabled
[ ] Server tokens disabled

PHP:

[ ] OPcache enabled with optimal settings
[ ] JIT compilation enabled (PHP 8.x)
[ ] PHP-FPM pool tuned (pm.max_children based on RAM)
[ ] Slow log enabled
[ ] Sessions stored in Redis
[ ] Realpath cache configured

MySQL/MariaDB:

[ ] innodb_buffer_pool_size set to 50-70% RAM
[ ] Slow query log enabled
[ ] Slow queries identified and indexed
[ ] Regular ANALYZE TABLE and OPTIMIZE TABLE scheduled
[ ] tmp_table_size appropriate

Caching:

[ ] Redis installed and configured
[ ] Application object caching implemented
[ ] Full-page caching (Nginx FastCGI cache or Varnish)
[ ] Browser cache headers set correctly
[ ] WordPress object cache enabled (if applicable)

Images:

[ ] All images converted to WebP or AVIF
[ ] JPEG/PNG files optimized (jpegoptim/optipng)
[ ] Lazy loading implemented
[ ] Responsive images with srcset
[ ] Critical above-fold images preloaded
[ ] Largest Contentful Paint image identified and prioritized

CSS/JS:

[ ] CSS and JS minified
[ ] CSS and JS bundled (fewer requests)
[ ] Critical CSS inlined
[ ] Non-critical CSS loaded asynchronously
[ ] JavaScript deferred or async

CDN:

[ ] CDN configured (Cloudflare or similar)
[ ] Static assets served from CDN
[ ] CDN cache rules configured

HTTP:

[ ] HTTP/2 enabled
[ ] HTTP/3 enabled (if supported)
[ ] SSL/TLS optimized (TLS 1.3, HSTS)

Monitoring:

[ ] Baseline measurements taken (PageSpeed, GTmetrix)
[ ] Server monitoring configured (Netdata/Prometheus)
[ ] Uptime monitoring configured
[ ] Alert notifications configured
[ ] Regular performance reviews scheduled

FAQ

1. What's the most impactful single change I can make?

For most WordPress/PHP sites: enable full-page caching. Install WP Rocket (paid) or configure Nginx FastCGI cache. This alone can reduce TTFB from 1-2 seconds to under 50 milliseconds — a 20-40x improvement — and dramatically cut server CPU load. If your server is struggling under load, caching is almost always the answer before buying more hardware.

2. How do I know if I need more server RAM or better optimization?

# Check if PHP-FPM is at max_children limit:
curl <http://localhost/fpm-status>
# If "active processes" regularly equals "max children", you're at the limit
# Either increase max_children (need more RAM) or add caching (better approach)

# Check MySQL buffer pool hit rate:
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"
# If reads/read_requests ratio > 5%, your buffer pool is too small
# Either increase innodb_buffer_pool_size or add query result caching

# Check overall RAM usage:
free -m
# If swap is being used regularly, you need more RAM
# If RAM is mostly free but site is slow, it's not a RAM problem

3. My site is fast on desktop but slow on mobile. What's different?

Mobile has three unique constraints:

Slower CPUs: Heavy JavaScript is more impactful. Reduce Total Blocking Time (TBT).
Network speed: Even with 4G, latency is higher than fixed broadband. Reduce HTTP requests and use a CDN.
Data costs: Users care more about page weight on mobile. Compress images aggressively.

Fix priority: reduce JavaScript, enable CDN, convert images to WebP, implement lazy loading.

4. How do I handle traffic spikes without scaling the server?

# The answer is always: more caching
# A properly cached site can handle 10-100x more traffic on the same server

# Tier 1: Full-page cache (Nginx/Varnish) — handles 99% of anonymous traffic
# Tier 2: Cloudflare CDN — handles traffic before it hits your server at all
# Tier 3: Redis object cache — reduces database load for dynamic pages
# Tier 4: Rate limiting — protect against abuse and bots

# For a major traffic event (product launch, press coverage):
# 1. Pre-warm the cache 30 minutes before
# 2. Enable Cloudflare's "Under Attack Mode" if needed
# 3. Monitor in real-time with htop and tail -f access.log

5. PHP OPcache shows memory is full. What do I do?

# Check OPcache status:
php -r "var_export(opcache_get_status()['memory_usage']);"

# If 'used_memory' is close to opcache.memory_consumption,
# increase the memory:
# opcache.memory_consumption=512

# Also check opcache_get_status()['opcache_statistics']['oom_restarts']
# If this is > 0, you've had out-of-memory restarts

# Count your PHP files:
find /var/www -name '*.php' | wc -l
# If > opcache.max_accelerated_files, increase that setting too

6. How often should I run OPTIMIZE TABLE on MySQL?

For tables that see many DELETEs and UPDATEs (like WordPress options and transients): monthly. For mostly-INSERT tables (logs, analytics): quarterly or when you observe performance degradation. Use pt-online-schema-change from Percona Toolkit instead of OPTIMIZE TABLE on large tables — it doesn't lock the table:

pt-online-schema-change --alter="ENGINE=InnoDB" D=mysite_db,t=wp_options

7. My cache hit rate is low. What's wrong?

# Check Redis hit rate:
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'
# hit_rate = hits / (hits + misses)

# Common causes of low hit rate:
# 1. TTL is too short
# 2. Cache keys include user-specific data (logged-in users bypass cache)
# 3. Cache is being flushed too aggressively
# 4. Cache is too small (items evicted before they're reused)
# 5. Too many unique URLs (pagination, search params creating unique keys)

# For issue 5, normalize cache keys:
# Sort query params before hashing: ?b=2&a=1 and ?a=1&b=2 → same cache key

8. Does caching break dynamic content (user carts, login state)?

Yes — if not configured correctly. The solution is selective caching:

Cache only anonymous requests (no session cookies)
Skip cache for cart pages, checkout, account pages
Use Edge Side Includes (ESI) or separate API calls for user-specific components
Fragment caching: cache the bulk of the page, fetch only dynamic parts via AJAX

Conclusion

Website performance is not a one-time project — it's an ongoing discipline. The patterns that generate the most server load are predictable, and the solutions are well-established:

The highest-ROI optimizations (in order):

Full-page caching — Nginx FastCGI cache or Varnish. This alone can handle 10x traffic on the same hardware.
Database query caching — Redis object cache. Eliminates the most expensive operations.
PHP OPcache — 3-5x PHP execution speedup with a simple config change.
Image optimization — Convert to WebP, compress, lazy-load. Typically 40-70% page weight reduction.
CDN — Serve static assets from the edge. 50-80% latency improvement for global audiences.
PHP-FPM tuning — Match process count to available RAM. Prevents resource exhaustion under load.
MySQL tuning — InnoDB buffer pool, slow query analysis. Eliminates database bottlenecks.

The compounding effect of these optimizations is significant: a site that takes 3 seconds to load with default configuration can consistently load in under 500 milliseconds with proper caching, image optimization, and a CDN — using identical server hardware.

Measure first. Optimize systematically. Measure again. The tools are all free and the improvements are real.

Call to Action

What's the biggest performance challenge on your site right now — slow database queries, too many server processes, or something else? Share your metrics in the comments and let's troubleshoot it together.

Related guides in this series:

📌 How to Migrate Your Website from Shared Hosting to VPS — the starting point before optimization
📌 How to Use SSH Securely to Manage Your VPS Remotely — access and manage your server
📌 How to Set Up UFW Firewall on Ubuntu — security alongside performance

Additional SEO Data

Primary Keyword: how to reduce server load, improve website performance, website speed optimization

LSI Keywords: server performance optimization, PHP-FPM tuning, MySQL performance tuning, Redis caching, Nginx optimization, web server optimization, WordPress speed optimization

Semantic Keywords: TTFB optimization, Core Web Vitals, page speed, LCP improvement, CDN setup, image optimization, PHP OPcache, database query caching

Long Tail Keywords: how to reduce server load WordPress, Nginx FastCGI cache setup, PHP-FPM max_children calculation, MySQL innodb buffer pool size configuration, Redis object cache WordPress, image WebP conversion server

Question Keywords: Why is my server CPU always high? How do I speed up my WordPress site on VPS? What causes high server load? How do I check if my site is slow?

Entity Keywords: Nginx, Apache, PHP-FPM, OPcache, Redis, MySQL, MariaDB, Cloudflare, Varnish, WP Rocket, WebP, AVIF, GTmetrix, PageSpeed Insights, Netdata, Prometheus, Grafana

Meta Title: How to Reduce Server Load and Improve Website Performance (Complete Guide 2026)

Meta Description: Complete guide to reducing server load and boosting website performance — Nginx caching, PHP OPcache, MySQL tuning, Redis, image optimization, CDN, and monitoring.

Slug: how-to-reduce-server-load-improve-website-performance

Blogger Tags: Performance, Nginx, PHP, MySQL, Redis, Caching, WordPress, CDN, Web Optimization, Server Administration

Category: Performance, Server Administration, Web Optimization, Linux

Alt Image: Web server performance optimization architecture diagram showing caching layers

Caption Image: Multi-layer caching architecture — from browser cache through CDN, Nginx FastCGI cache, Redis, to MySQL — reducing server load at every level

{
  "@context": "<https://schema.org>",
  "@type": "Article",
  "headline": "How to Reduce Server Load and Improve Website Performance: The Complete Guide",
  "description": "Complete guide to reducing server load and improving website performance — Nginx optimization, PHP OPcache, MySQL tuning, Redis caching, image optimization, CDN setup, and monitoring.",
  "author": {
    "@type": "Person",
    "name": "CloudAdminHub"
  },
  "publisher": {
    "@type": "Organization",
    "name": "CloudAdminHub"
  },
  "datePublished": "2026-06-15",
  "dateModified": "2026-06-15",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "<https://cloudadminhub.blogspot.com/2026/06/how-to-reduce-server-load-improve-website-performance.html>"
  }
}

{
  "@context": "<https://schema.org>",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the single most impactful change to reduce server load?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "For most WordPress and PHP sites, enabling full-page caching is the highest-impact change. Configuring Nginx FastCGI cache or installing WP Rocket can reduce TTFB from 1-2 seconds to under 50 milliseconds and handle 10x more traffic on the same server hardware."
      }
    },
    {
      "@type": "Question",
      "name": "How do I speed up my WordPress site on a VPS?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The most effective stack: (1) Enable Redis object caching, (2) Configure Nginx FastCGI full-page cache, (3) Enable PHP OPcache with JIT, (4) Tune PHP-FPM max_children for your available RAM, (5) Optimize MySQL InnoDB buffer pool size, (6) Convert images to WebP, (7) Use Cloudflare CDN. These changes together typically improve load times by 5-10x."
      }
    },
    {
      "@type": "Question",
      "name": "How do I calculate the correct PHP-FPM max_children value?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Formula: (Available RAM - OS overhead - MySQL RAM) / Average PHP process RAM. Check average PHP process RAM with: ps -ylC php-fpm8.2 --sort:rss | awk 'NR>1{sum+=$8; count++} END {print sum/count/1024, \"MB\"}'. For a 2GB VPS with MySQL: (2048 - 256 - 512) / 30MB ≈ 42 max_children."
      }
    }
  ]
}

OG Title: How to Reduce Server Load and Improve Website Performance (2026)

OG Description: Complete server performance guide — Nginx caching, PHP OPcache, MySQL tuning, Redis, image optimization, CDN, and monitoring for high-performance websites.

twitter:card = summary_large_image
twitter:title = Reduce Server Load & Boost Website Performance: Complete Guide
twitter:description = Nginx optimization, PHP-FPM tuning, MySQL config, Redis caching, WebP images, CDN setup, and real-time monitoring — everything for a fast server.

Recommended External Links:

How to Reduce Server Load and Improve Website Performance: The Complete Guide

Table of Contents

Understanding Server Load: Where It Comes From

The Four Main Resource Bottlenecks

What Generates the Most Load

Measuring Performance: Establish Your Baseline First

Server-Side Metrics

Client-Side / Page Speed Tools

Key Metrics to Track

Web Server Optimization (Nginx/Apache)

Nginx Performance Configuration

Nginx Site Configuration with Caching

Apache Performance Configuration

PHP Performance Tuning

PHP-FPM Pool Configuration

PHP OPcache Configuration

PHP Configuration for Performance

Database Optimization (MySQL/MariaDB)

MySQL Configuration Tuning

Query Optimization

Database Connection Pooling with PgBouncer (for high-traffic sites)

Caching: The Single Biggest Performance Lever

Caching Layers (from fastest to slowest)

Redis Installation and Configuration

PHP Sessions in Redis

Object Caching Pattern (PHP)

Full-Page Caching Strategy

Content Delivery Network (CDN)

Cloudflare (Free Tier — Highly Recommended)

Cache Invalidation with Cloudflare API

Self-Hosted CDN with Varnish Cache

Image Optimization

Convert to WebP/AVIF

Nginx: Serve WebP Automatically

Image Optimization Tools

Responsive Images in HTML

Lazy Loading

CSS, JavaScript, and HTML Optimization

Minification and Bundling

Critical CSS

Resource Hints

HTTP Cache Headers

WordPress-Specific Performance

WordPress Object Cache with Redis

WordPress Configuration for Performance

WordPress Database Cleanup

Recommended WordPress Performance Plugins

HTTP/2 and HTTP/3

Enable HTTP/2 in Nginx

Enable HTTP/3 (QUIC)

Monitoring and Maintaining Performance

Real-Time Monitoring

Log Analysis

Automated Performance Alerts

Performance Optimization Checklist

FAQ

Conclusion

Call to Action

Additional SEO Data

Komentar

Posting Komentar

Postingan Populer

How to Manage a Linux VPS for Beginners: A Complete Server Administration Guide (2026)

Understanding DevOps: Definition, Tools, and Benefits for Modern Infrastructure