WordPress Açılış Hızını Artırmanın 10 Etkili Yolu

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Sunucuda WordPress kurulu binlerce site gördüm. Bir kısmı uçar gibi açılır, bir kısmı kullanıcıyı beklemeye zorlar. Farkın büyük çoğunluğu hosting kalitesinden değil, yapılandırmadan kaynaklanıyor. Yıllar içinde öğrendiğim şu: WordPress’i hızlandırmak için illa pahalı bir sunucuya gerek yok, doğru yerde doğru ayarı yapmak yeterli.

Bu yazıda hem sunucu tarafında hem WordPress içinde yapabileceğin, gerçekten fark yaratan 10 optimizasyon adımını anlatacağım. Teorik değil, uyguladığım ve sonuç aldığım yöntemler bunlar.

1. PHP Sürümünü Güncel Tut

Hala PHP 7.4 kullanan sunucular görüyorum 2024’te. PHP 8.1 ve üzeri sürümler, önceki sürümlere kıyasla ciddi performans artışı sunuyor. Özellikle JIT (Just-In-Time) derleyicisi ile birlikte WordPress’in yoğun PHP kodu çalıştırma süreleri belirgin biçimde kısalıyor.

# Mevcut PHP sürümünü kontrol et
php -v

# Ubuntu/Debian üzerinde PHP 8.2'ye geçiş
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.2 php8.2-fpm php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring php8.2-xml php8.2-zip

# Nginx için PHP-FPM pool ayarını güncelle
sudo nano /etc/nginx/sites-available/wordpress.conf

Apache kullanıyorsan mod_php yerine php-fpm ile çalışmana şiddetle tavsiye ederim. PHP-FPM, process yönetimi açısından çok daha verimli ve her site için ayrı pool tanımlayabiliyorsun.

# PHP-FPM pool konfigürasyonu örneği
# /etc/php/8.2/fpm/pool.d/wordpress.conf

[wordpress]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-wordpress.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500

pm.max_requests = 500 değeri önemli. Her worker belirli sayıda istek sonrası yeniden başlıyor ve bu memory leak sorunlarının önüne geçiyor.

2. OPcache’i Doğru Yapılandır

OPcache, PHP’nin en değerli silahı. PHP dosyaları her istek geldiğinde tekrar parse edilmek yerine derlenmiş bytecode olarak bellekte tutulur. WordPress gibi onlarca dosyayı dahil eden bir uygulama için bu büyük kazanım.

Problem şu: Çoğu hosting OPcache’i açıyor ama varsayılan değerlerle bırakıyor. Varsayılan değerler WordPress için yeterli değil.

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

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.fast_shutdown=1

opcache.memory_consumption: OPcache için ayrılan RAM miktarı (MB). Büyük WordPress siteleri için 256 ideal.

opcache.max_accelerated_files: Cache’lenecek maksimum dosya sayısı. WordPress + eklentiler + tema ile bu sayı kolayca 5000’i geçebilir.

opcache.revalidate_freq: Dosya değişiklik kontrolü sıklığı (saniye). Production ortamında 60 veya daha yüksek değer kullanabilirsin.

OPcache durumunu kontrol etmek için bir PHP dosyası oluştur:

# OPcache durumunu kontrol et (geçici, sonra sil!)
echo "<?php var_dump(opcache_get_status()); ?>" > /var/www/html/opcache_check.php
# Tarayıcıda açıp kontrol ettikten sonra sil
rm /var/www/html/opcache_check.php

3. Redis ile Object Cache Kullan

WordPress’in database sorgu yükü gerçek bir baş ağrısı olabiliyor. Her sayfa yüklemesinde onlarca hatta yüzlerce MySQL sorgusu çalışabiliyor. Bunların büyük kısmı aynı verileri tekrar tekrar çekiyor.

Redis burada devreye giriyor. WordPress’in WP_Object_Cache mekanizmasını kalıcı hale getiriyor ve sorguları bellekten servis ediyor.

# Redis kurulumu
sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

# Redis bellek limitini ayarla
sudo nano /etc/redis/redis.conf
# /etc/redis/redis.conf içinde bu değerleri ayarla
maxmemory 256mb
maxmemory-policy allkeys-lru
save ""
# Disk yazımını devre dışı bırak (sadece cache olarak kullanacaksak)

WordPress tarafında redis-cache eklentisi veya direkt wp-redis dropin kullanabilirsin. Ben genelde WP-CLI üzerinden kuruyorum:

# WP-CLI ile Redis Cache eklentisi kur ve etkinleştir
wp plugin install redis-cache --activate --path=/var/www/html/wordpress

# Object cache'i etkinleştir
wp redis enable --path=/var/www/html/wordpress

# Cache durumunu kontrol et
wp redis status --path=/var/www/html/wordpress

wp-config.php dosyasına şu satırları da eklemeyi unutma:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_DATABASE', 0);

Yoğun trafikli bir sitede Redis devreye girdikten sonra MySQL CPU kullanımının yarıya düştüğünü bizzat gördüm. Bu abartı değil.

4. Nginx FastCGI Cache ile Sayfa Cache’i

Plugin tabanlı sayfa cache çözümleri (WP Super Cache, W3 Total Cache) işe yarıyor ama Nginx seviyesinde yapılan cache bunların hepsinden hızlı. PHP bile çalışmadan, Nginx doğrudan cache dosyasını servis ediyor.

# /etc/nginx/nginx.conf içinde http bloğuna ekle
fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
# WordPress site konfigürasyonu
# /etc/nginx/sites-available/wordpress.conf

server {
    listen 80;
    server_name example.com;
    root /var/www/html/wordpress;
    index index.php;

    set $skip_cache 0;

    # POST isteklerini ve query string içerenleri cache'leme
    if ($request_method = POST) { set $skip_cache 1; }
    if ($query_string != "") { set $skip_cache 1; }

    # Belirli URL'leri cache'leme
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap") {
        set $skip_cache 1;
    }

    # Giriş yapmış kullanıcılar ve yorum yaparken cache'leme
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $skip_cache 1;
    }

    location ~ .php$ {
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm-wordpress.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Cache purge işlemi için nginx-cache-purge modülü veya NGINX Helper eklentisini kullanabilirsin. Yeni içerik yayınlandığında ilgili cache otomatik temizleniyor.

5. MySQL/MariaDB Ayarlarını Optimize Et

WordPress’in kalbi veritabanında atıyor ve çoğu sysadmin bunu görmezden geliyor. Varsayılan MySQL ayarları genel kullanım için hazırlanmış, WordPress’in spesifik yük profili için optimize edilmemiş.

# /etc/mysql/mysql.conf.d/mysqld.cnf veya /etc/my.cnf

[mysqld]
# InnoDB buffer pool - sunucu RAM'inin %60-70'i
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 2

# Log boyutları
innodb_log_file_size = 256M
innodb_log_buffer_size = 64M

# Flush ayarı - SSD disklerde performansı artırır
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

# Query cache (MySQL 8'de kaldırıldı, MariaDB'de hala var)
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M

# Connection ayarları
max_connections = 150
thread_cache_size = 16
table_open_cache = 4000

Veritabanı tablosunu düzenli optimize etmeyi de ihmal etme. Aylık bir cron job ile halledebilirsin:

# /etc/cron.monthly/optimize-wordpress-db adında dosya oluştur
#!/bin/bash
mysqlcheck -u wordpress_user -pPASSWORD --optimize wordpress_db 2>/dev/null
echo "WordPress DB optimize edildi: $(date)" >> /var/log/wordpress-maintenance.log
chmod +x /etc/cron.monthly/optimize-wordpress-db

6. CDN Entegrasyonu ve Statik Dosya Sunumu

Görsel, CSS, JavaScript dosyaları sitenin büyük bölümünü oluşturuyor. Bu dosyaları origin sunucundan servise etmek yerine CDN üzerinden dağıtmak hem yükü azaltıyor hem de coğrafi yakınlık sayesinde kullanıcılara daha hızlı ulaşıyor.

Cloudflare ücretsiz plan için bile dramatik bir fark yaratıyor. Ama Cloudflare kullanıyor olsan bile Nginx tarafında doğru header ayarları şart:

# Nginx'te statik dosyalar için cache header'ları
location ~* .(jpg|jpeg|png|gif|ico|css|js|pdf|txt|woff|woff2|ttf|svg|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
    access_log off;
    log_not_found off;
}

# Gzip sıkıştırma
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

WP Offload Media veya Cloudflare R2 entegrasyonu ile medya dosyalarını tamamen origin sunucudan kaldırabilirsin. Büyük medya kütüphanesi olan sitelerde bu disk I/O yükünü ciddi ölçüde azaltıyor.

7. Gereksiz Eklentileri ve Şişirilmiş Temaları Temizle

Teknik bir konu gibi görünmüyor ama inan bana, bu madde bazen diğer dokuzunun toplamından fazla fark yaratıyor. 40-50 aktif eklenti görmüşümdür üretim sitelerinde. Her eklenti sayfa yüklemesinde kod çalıştırıyor, veritabanı sorgusu yapıyor, CSS/JS dosyası yüklüyor.

# WP-CLI ile aktif eklentileri listele
wp plugin list --status=active --path=/var/www/html/wordpress

# Devre dışı ama yüklenmiş eklentileri listele (bunları sil!)
wp plugin list --status=inactive --path=/var/www/html/wordpress

# Otomatik güncellemeleri bekleyen eklentileri kontrol et
wp plugin list --update=available --path=/var/www/html/wordpress

Sayfa yükleme süresinde hangi eklentinin ne kadar yer kapladığını görmek için Query Monitor eklentisi altın değerinde. Geliştirme ortamında mutlaka kullan.

Tema tarafında da benzer bir temizlik şart:

# Yüklü temaları listele
wp theme list --path=/var/www/html/wordpress

# Kullanılmayan temaları kaldır (Twenty* temaları genelde gereksiz kalıyor)
wp theme delete twentytwenty twentytwentyone --path=/var/www/html/wordpress

8. Görsel Optimizasyonu Otomatize Et

Görseller web sayfalarının toplam boyutunun büyük kısmını oluşturuyor. WordPress’e yüklenen her görselin otomatik olarak optimize edilmesi gerekiyor. Bunu sunucu tarafında çözersen eklentiye gerek kalmıyor.

# ImageMagick ve WebP desteği için gerekli paketleri kur
sudo apt install imagemagick webp

# Mevcut görselleri toplu WebP'ye çevir
find /var/www/html/wordpress/wp-content/uploads -name "*.jpg" -o -name "*.png" | 
while read img; do
    cwebp -q 80 "$img" -o "${img%.*}.webp" 2>/dev/null
done

Nginx tarafında tarayıcı WebP destekliyorsa otomatik olarak WebP servis et:

# Nginx'te WebP serve konfigürasyonu
map $http_accept $webp_suffix {
    default "";
    "~*webp" ".webp";
}

location ~* ^(/wp-content/.+).(png|jpg)$ {
    set $base $1;
    set $ext $2;
    try_files $base.$ext$webp_suffix $base.$ext =404;
    add_header Vary "Accept";
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Bu yapılandırmayla WebP destekleyen tarayıcılara (Chrome, Firefox, Edge) otomatik olarak WebP servis ediyorsun, desteklemeyenlere orijinal format gidiyor. Eklentiye gerek yok, Nginx hallediyor.

9. Heartbeat API’yi Kontrol Altına Al

WordPress’in Heartbeat API’si, admin panelinde her 15-60 saniyede bir AJAX isteği göndererek sunucuyla senkronizasyon sağlıyor. Çok kullanıcılı sitelerde bu istek bombardımanı sunucu yükünü gereksiz yere artırıyor.

# wp-config.php'ye ekle veya functions.php'ye ekle
# Heartbeat'i sadece post editor'da çalıştır, admin dashboard'da durdur

Bunu WP-CLI ile de yönetebilirsin:

# Heartbeat ayarlarını kontrol et
wp eval 'echo wp_json_encode(wp_get_schedules());' --path=/var/www/html/wordpress

# Heartbeat'i disable eden mu-plugin oluştur
cat > /var/www/html/wordpress/wp-content/mu-plugins/disable-heartbeat.php << 'EOF'
<?php
/**
 * Heartbeat API kontrolü
 */
add_action('init', function() {
    // Admin ekranında heartbeat'i yavaşlat
    if (is_admin()) {
        wp_deregister_script('heartbeat');
        // Sadece post editörde aktif et
        global $pagenow;
        if ('post.php' === $pagenow || 'post-new.php' === $pagenow) {
            wp_enqueue_script('heartbeat');
            add_filter('heartbeat_settings', function($settings) {
                $settings['interval'] = 60; // 60 saniyeye çıkar
                return $settings;
            });
        }
    }
}, 1);
EOF

mu-plugins klasöründeki dosyalar her zaman yükleniyor ve eklenti yönetici panelinden devre dışı bırakılamıyor. Kritik optimizasyonları buraya koymak iyi bir pratik.

10. WordPress Veritabanı Revision ve Autosal Temizliği

WordPress her içerik kaydettiğinde revision kaydediyor. Büyük sitelerde bu binlerce gereksiz veritabanı kaydına dönüşüyor. Autosal verileri de benzer şekilde biriikiyor.

# Mevcut revision sayısını öğren
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';" --path=/var/www/html/wordpress

# Tüm revision'ları temizle
wp post delete $(wp post list --post_type='revision' --format=ids --path=/var/www/html/wordpress) --force --path=/var/www/html/wordpress

# Autosal draft'ları temizle
wp db query "DELETE FROM wp_posts WHERE post_status = 'auto-draft';" --path=/var/www/html/wordpress

# Orphaned post meta'yı temizle
wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;" --path=/var/www/html/wordpress

Revision sayısını sınırlamak için wp-config.php‘ye şu satırı ekle:

# wp-config.php
define('WP_POST_REVISIONS', 3);
define('AUTOSAVE_INTERVAL', 120); // Saniye cinsinden, varsayılan 60

Bu değişikliği yaptıktan sonra her yazı için maksimum 3 revision tutulacak. Geriye dönük temizlik için de düzenli bir cron job kurmak mantıklı:

# /etc/cron.weekly/clean-wordpress-db
#!/bin/bash
WP_PATH="/var/www/html/wordpress"

# Eski revision'ları temizle
wp post delete $(wp post list --post_type='revision' --format=ids --path=$WP_PATH 2>/dev/null) --force --path=$WP_PATH 2>/dev/null

# Transient'ları temizle
wp transient delete --expired --path=$WP_PATH 2>/dev/null

# DB optimize et
wp db optimize --path=$WP_PATH 2>/dev/null

echo "Haftalık WordPress temizliği tamamlandı: $(date)" >> /var/log/wordpress-maintenance.log
chmod +x /etc/cron.weekly/clean-wordpress-db

Sonuç

Bu 10 adımın hepsini uygulamanı beklemiyorum, ama birkaç tanesini bile hayata geçirsen farkı hissedeceksin. Öncelik sırası konusunda şunu söyleyeyim: PHP-FPM + OPcache + Redis üçlüsü her şeyden önce gelir. Bu üçü yerine oturduğunda diğerleri ek iyileştirme sağlar.

Bir performans iyileştirmesi yaparken mutlaka önce ölçüm yap, sonra uygula, sonra tekrar ölç. Hangi adımın ne kadar fark yarattığını bilmeden yapılan optimizasyonlar kör uçuşa benziyor. wp --debug, Query Monitor eklentisi ve ab (Apache Benchmark) iyi başlangıç noktaları.

Son olarak şunu da ekleyeyim: Hosting altyapısı iyi değilse hiçbir optimizasyon seni kurtarmaz. Paylaşımlı hostingde bu adımların büyük kısmına erişimin olmayacak. Ciddi WordPress işi için en azından VPS seviyesi bir altyapı şart.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir