WordPress hızlandırma: önce ölçün, sonra dokunun

Hız eklentisi kurup ayarları rastgele açmak, çoğu sitede ölçülebilir bir kazanç getirmez; bazen sayfayı bozar. İşe sıralı bir teşhisle başlayın: sorun sunucu yanıtında mı, veritabanında mı, görsellerde mi, yoksa tarayıcıda çalışan betiklerde mi? Her katmanın kendi ölçüsü ve kendi çözümü var.

Önce iki rakamı ayırın

Sayfa açılış süresi tek bir sayı değildir. En az iki ayrı büyüklüğe bakın:

• TTFB — isteğin gönderilmesiyle ilk baytın gelmesi arası. Sunucu, PHP ve veritabanının toplam süresidir.
• LCP — ekrandaki en büyük görsel öğenin çizilmesi. Ön yüzün, görsellerin ve yazı tiplerinin süresidir.

Hedef: TTFB 200–500 ms, LCP 2,5 saniyenin altı. TTFB kötüyse ön yüz optimizasyonu yapmanın anlamı yoktur; ölçüyü sunucudan almadan devam etmeyin. Ölçüm için tarayıcının ağ sekmesi yeterlidir; alan verisi için arama konsolundaki Core Web Vitals raporuna bakın. Metriklerin ayrıntısı için LCP, INP ve CLS yazısına bakabilirsiniz.

Ölçümü tekrarlanabilir hale getirin

Tarayıcı sekmesi tek seferlik bakış için yeterli, ama karşılaştırma yapacaksanız her seferinde aynı koşulda ölçen bir komut gerekir:

curl -o /dev/null -s -w "ttfb:%{time_starttransfer} toplam:%{time_total}\n" https://siteniz.com/

Komutu arka arkaya beş kez çalıştırın. İlk sonuç soğuk önbellek yüzünden yüksek çıkar; kararlı hale gelen değeri not edin. Sonra adresin sonuna ?nocache=1 ekleyip tekrarlayın. İki rakam arasındaki fark, sayfa önbelleğinin gerçekte ne kadar iş yaptığını gösterir; fark yoksa önbellek ya kapalıdır ya da isabet etmiyordur.

Adım 1: PHP sürümü ve OPcache

Hâlâ PHP 7.4 üzerinde çalışan siteler görüyoruz. PHP 8.2 ve üzeri, aynı kod için tipik olarak %20–35 daha az CPU harcar; bu doğrudan TTFB'ye yansır. cPanel'de Select PHP Version ekranından sürümü yükseltmeden önce hazırlık sırası şudur: bir kopya (staging) üzerinde deneyin, eklenti uyumluluğunu kontrol edin, hata günlüğünü açık tutun, sonra canlıya alın.

Aynı ekranda opcache eklentisinin etkin olduğunu doğrulayın. OPcache derlenmiş PHP kodunu bellekte tutar; kapalıysa her istek dosyaları yeniden derler ve bu tek başına yüzlerce milisaniye eder.

Adım 2: Veritabanını ölçün

Query Monitor eklentisi, yönetici olarak gezerken hangi sorgunun kaç milisaniye sürdüğünü ve hangi eklentiden geldiğini gösterir. Sayfa başına 300'den fazla sorgu ya da tek başına 100 ms'i geçen bir sorgu görüyorsanız kaynağı bulmuşsunuzdur. Sık karşılaşılan üç sebep:

• Şişmiş wp_options tablosu. autoload = yes işaretli satırlar her istekte belleğe alınır. Toplam autoload boyutu 1 MB'ı geçiyorsa artık gereksiz olan geçici kayıtları (transient) temizleyin.
• Silinmemiş revizyonlar. Binlerce yazı revizyonu ve çöp kaydı wp_posts tablosunu büyütür.
• İndekssiz meta sorgusu. Özel alanlara göre filtreleyen sorgular wp_postmeta üzerinde tam tarama yapar. Çözüm doğru indeksi eklemektir.

Temizliğin üç komutu

WP-CLI erişiminiz varsa yukarıdaki üç sebebi de birkaç saniyede ölçüp giderebilirsiniz:

• Autoload yükünü megabayt cinsinden ölçün: wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1048576,2) FROM wp_options WHERE autoload='yes'"
• Süresi dolmuş geçici kayıtları silin: wp transient delete --expired
• Revizyonları temizleyin: wp post delete $(wp post list --post_type=revision --format=ids) --force

Temizlikten sonra tekrar birikmemesi için wp-config.php dosyasına define('WP_POST_REVISIONS', 5); satırını ekleyin. Kaldırdığınız eklentilerin wp_options içinde bıraktığı kayıtlar da autoload yükünün klasik kaynağıdır; adı artık kurulu olmayan bir eklentiye ait olan satırları elle silebilirsiniz.

Adım 3: Görseller

Çoğu sitede toplam sayfa ağırlığının %60'ından fazlası görsellerdir ve kazanç en kolay buradadır. Üç kural yeter:

1. Kaynak dosyayı gösterileceği ölçüde yükleyin. 3.000 piksel genişliğindeki bir fotoğrafı 800 piksellik alanda göstermek bant genişliğinin dörtte üçünü çöpe atar.
2. WebP veya AVIF'e dönüştürün. Aynı görsel kalitesinde JPEG'e göre %25–50 daha küçük dosya elde edersiniz.
3. Ekranın altındaki görsellere loading="lazy" verin, ama kapak görselini lazy yapmayın; bu doğrudan LCP'yi geciktirir.

Adım 4: Önbellek katmanları

Üç ayrı önbellek vardır ve karıştırılırlar:

• Sayfa önbelleği: Oluşturulan HTML diske yazılır, sonraki ziyaretçiye PHP çalıştırılmadan verilir. Anonim ziyaretçi ağırlıklı sitelerde en büyük kazanç budur.
• Nesne önbelleği (Redis/Memcached): Veritabanı sorgu sonuçlarını bellekte tutar. Üyelik, sepet, panel gibi kişiselleştirilmiş sayfalarda işe yarar; paylaşımlı pakette genellikle kullanılamaz, VDS veya cloud sunucu gerektirir.
• Tarayıcı önbelleği: Statik dosyalar için uzun Cache-Control süresi. Dosya adında sürüm damgası kullanıyorsanız bir yıl vermek güvenlidir.

WooCommerce kullanıyorsanız sepet, ödeme ve hesap sayfalarını sayfa önbelleğinin dışında tutun. Aksi halde bir müşterinin sepeti başkasına görünür — bu, hız kazancıyla karşılaştırılamayacak bir hatadır.

Sunucu düzeyinde tam sayfa önbelleği hazır isteyenler için WordPress hosting paketlerimizde LiteSpeed ve LSCache kurulu gelir.

Adım 5: Ön yüzü sadeleştirin

Tarayıcı, <head> içindeki her engelleyici CSS ve JS dosyasını indirip işlemeden sayfayı çizmez. Yapılacaklar:

• Kullanılmayan eklentilerin varlıklarını yalnız ihtiyaç duyan sayfalarda yükleyin; iletişim formu betiği ana sayfada gereksizdir.
• Yazı tiplerini kendi sunucunuzdan verin ve font-display: swap kullanın. Dış kaynaktan çekilen her yazı tipi ek bir DNS çözümlemesi ve TLS el sıkışması demektir.
• Üçüncü taraf betiklerini sayın. Her canlı destek, ısı haritası ve reklam betiği ana iş parçacığını meşgul eder; INP değerini en çok bunlar bozar.

Hangi rakam iyi, hangisi elden geçirilmeli

Ölçümü mobil ve hız sınırlı ağ ayarıyla da tekrarlayın. Türkiye'de ziyaretin yarıdan fazlası telefondan geliyor ve masaüstünde iyi görünen bir sayfa, mobil işlemcide iki üç kat yavaş çalışabilir.

Neyi yapmayın

Aynı anda iki hız eklentisi kurmayın; ikisi de aynı dosyaları birleştirmeye çalışır ve sonuç bozuk sayfadır. "Tüm CSS'i satır içine al" gibi agresif seçenekleri, öncesinde ve sonrasında ölçüm almadan açmayın. Ve her değişiklikten sonra sayfayı gerçekten gezerek kontrol edin: hız puanı yükselirken menü açılmıyorsa kazanç değil kayıp vardır.

Bu sıralama ne zaman değişir

Yukarıdaki sıra, ziyaretçilerinin çoğu oturum açmamış olan siteler için doğrudur. İki durumda baştan farklı ilerleyin:

• Üyelik, forum, eğitim portalı ya da panel ağırlıklı siteler. Her ziyaretçinin sayfası kişiselleştiği için sayfa önbelleği neredeyse hiç isabet etmez. Kazanç doğrudan nesne önbelleğinde ve sorgu optimizasyonundadır; sayfa önbelleğine harcanan zaman boşa gider.
• Ziyaretçilerin çoğu yurt dışındaysa. TTFB'nin büyük bölümü işlem değil mesafe kaynaklıdır. Bu durumda önce dağıtım ağı ve lokasyon konuşulur, PHP ayarları sonra gelir.

Her iki durumda da ölçüm yöntemi aynı kalır: değiştirmeden önce ölç, tek şeyi değiştir, sonra tekrar ölç.

Görünmeyen iki yük: autoload seçenekleri ve WP-Cron

Yukarıdaki adımları uyguladığınız hâlde yönetim paneli ve önbelleklenmeyen sayfalar ağır kalıyorsa, iki gizli yüke bakın. İkisi de eklenti listesinde görünmez ve ikisi de her istekte ödenir.

1. Autoload: her sayfada belleğe alınan seçenekler

WordPress, wp_options tablosunda "otomatik yükle" olarak işaretlenmiş her satırı her istekte belleğe okur. Silinen eklentiler çoğu zaman kendi büyük seçeneklerini geride bırakır ve bunlar yıllarca her sayfa açılışında taşınır. Toplam boyutu tek sorguyla görün (tablo önekiniz farklıysa wp_ kısmını değiştirin):

SELECT autoload, SUM(LENGTH(option_value)) AS bayt
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
GROUP BY autoload;

Sorgudaki dört değerin sebebi şudur: WordPress 6.6'dan itibaren eski yes/no yerine on, off, auto gibi değerler kullanılıyor; eski bir sitede ikisi bir arada bulunabilir. Temiz kurulum yaptığımız WordPress 7.1.3 deneme sitesinde 98 satır on ve toplam yaklaşık 4 KB autoload veri vardı. Ardından bir eklenti artığını taklit eden 900 KB'lık tek bir seçenek ekledik; toplam bir anda 928 KB'a çıktı. WordPress'in Site Sağlığı ekranı 800.000 baytı geçen autoload toplamı için uyarı verir; bu eşik çekirdek kodunda site_status_autoloaded_options_size_limit süzgecinin varsayılan değeridir.

Suçluyu bulmak için en büyük satırları listeleyin:

SELECT option_name, LENGTH(option_value) AS bayt
FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bayt DESC LIMIT 10;

Adı artık kullanmadığınız bir eklentiye aitse önce yedek alın, sonra seçeneği silin. Hâlâ kullanılan bir eklentiye aitse silmek yerine otomatik yüklemeyi kapatın; WP-CLI ile tek komuttur:

wp option set-autoload eski_eklenti_onbellek off

2. WP-Cron: ziyaretçinin ödediği zamanlanmış görevler

WordPress'in zamanlanmış görevleri gerçek bir zamanlayıcıyla değil, ziyaretçi istekleriyle tetiklenir. Yoğun sitede bu, görevlerin gereğinden sık kontrol edilmesi; az ziyaretçili sitede ise yedek ve yayın gibi görevlerin gecikmesi demektir. Bekleyen görevleri görün:

wp cron event list --fields=hook,next_run_relative

Çözüm, WP-Cron'u ziyaretçiden ayırıp sistem zamanlayıcısına bağlamaktır. wp-config.php dosyasına şu satırı ekleyin (WP-CLI ile: wp config set DISABLE_WP_CRON true --raw):

define( 'DISABLE_WP_CRON', true );

Sonra görevleri beş dakikada bir çalıştıran bir cron satırı tanımlayın. Panelli hostingde bu işi cron bölümü yapar:

*/5 * * * * cd /site/yolu && wp cron event run --due-now >/dev/null 2>&1

Bu iki ayarın etkisi en çok önbelleğin devrede olmadığı yerde görülür: yönetim paneli, sepet, ödeme sayfası ve giriş yapmış kullanıcılar. Önbellekli bir ana sayfanın hızı değişmeyebilir; bu yüzden ölçümü bu sayfalarda yapın.

Sıralamayı özetlersek

Ölç, en büyük payı bul, tek bir değişiklik yap, tekrar ölç. Bu döngüyü üç dört kez çevirdiğinizde tipik bir WordPress sitesinde TTFB yarıya, LCP üçte bire iner. Rastgele ayar açmakla geçen bir haftadan çok daha hızlı sonuç verir.

Sık sorulan sorular