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.

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ç.

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.