WordPress Hızlandırma: Core Web Vitals Odaklı Optimizasyon Rehberi

Bir WordPress sitesini hızlandırmanın en etkili yolu, yavaşlığın WordPress’e özgü kaynaklarını sırayla ortadan kaldırmaktır: önbelleğe alınmayan PHP üretimi, gereğinden ağır eklentiler, ölçüsüz görseller ve yıllar içinde şişen veritabanı. WordPress hızlandırma bu yüzden genel hız listelerinden farklı ilerler; önce hangi metriğin kötü olduğunu bulur, sonra o metriği bozan tema, eklenti ya da ayarı hedefler.

Sunucu ve ön yüz tarafındaki genel yöntemler web sitesi hızlandırma rehberi yazısındadır; aşağıdaki adımlar yalnızca WordPress’e özgüdür ve WordPress hosting paketlerinde de kendi sunucunuzda da aynı biçimde uygulanır.

Core Web Vitals WordPress’te neden kötüleşir?

Core Web Vitals WordPress’te çoğunlukla önbelleksiz sayfa üretimi, sayfa oluşturucu ile kaydırıcı betikleri ve boyutsuz görseller yüzünden kötüleşir; hangi metriğin bozulduğunu bilmek, yanlış eklentiyle zaman kaybetmeyi önler. Mart 2024’ten bu yana etkileşim metriği FID (First Input Delay) değil INP’dir (Interaction to Next Paint). “İyi” sayılmak için ziyaretlerin en az %75’inde LCP (Largest Contentful Paint) 2,5 saniyeyi, INP 200 milisaniyeyi, CLS (Cumulative Layout Shift) 0,1’i aşmamalıdır.

Gerçek kullanıcı verisini Search Console’daki Temel Web Verileri raporu ve PageSpeed Insights’ın üst bölümü gösterir; trafiği az sitelerde bu veri oluşmayabilir, o durumda laboratuvar ölçümüyle yetinirsiniz. Ana sayfayı, bir yazıyı ve varsa bir ürün sayfasını ayrı ölçün; şablonlar farklı eklenti yükü taşır.

Sayfa önbelleği ve nesne önbelleği nasıl kurulur?

Sayfa önbelleği, sunucunuza uygun tek bir önbellek eklentisiyle ya da sunucu düzeyinde kurulur; WordPress’in her ziyaret için PHP çalıştırıp veritabanını sorgulamasını ortadan kaldırdığı için sunucu yanıt süresini (TTFB, Time To First Byte) en çok düşüren adımdır. Sunucunuza göre seçim:

• LiteSpeed sunucu: LiteSpeed Cache eklentisi; sekme sekme ayarlar LiteSpeed Cache ayarları rehberinde.
• Apache ya da Nginx: WP Super Cache, W3 Total Cache ya da ücretli WP Rocket gibi tek bir eklenti; kendi sunucunuzda Nginx FastCGI önbelleği de bir seçenektir.

Nesne önbelleği farklı bir sorunu çözer: WordPress’in yerleşik nesne önbelleği yalnızca tek istek boyunca yaşar. Redis ya da Memcached ile kalıcı hâle getirildiğinde, önbelleğe alınamayan sayfalar (yönetim paneli, üye alanı, sepet) aynı sorguları tekrar tekrar çalıştırmaz. Bunun için sunucuda Redis servisi ve PHP eklentisi gerekir; WordPress tarafında wp-content/object-cache.php dosyasını yerleştiren bir eklenti (Redis Object Cache gibi) kullanılır. Büyük sitelerde Site Sağlığı ekranı da kalıcı nesne önbelleği önerebilir. Redis’i kendiniz kurmak istiyorsanız bir VPS sunucu tam yetki sağlar; paylaşımlı pakette sağlayıcının sunduğu özelliklere bakın.

Görseller ve fontlar WordPress’te nasıl optimize edilir?

Görseller doğru boyutta yüklenip WebP ya da AVIF biçiminde sunularak, fontlar ise yalnızca gereken ağırlıklar kendi sunucunuzdan yüklenerek optimize edilir. WordPress her görselin birden çok boyutunu üretip srcset ile tarayıcıya uygun olanı seçtirir; bu sistem ancak görseller makul boyutta yüklendiğinde ve tema doğru boyutları istediğinde işe yarar. Uygulamada:

• Kaynak boyutu: WordPress 5.3’ten beri 2560 pikselden büyük görsellerin küçültülmüş bir kopyasını tam boyut olarak kullanır; yine de fotoğrafları gösterileceği genişliğe yakın boyutta yükleyin.
• Biçim: WebP yüklemesi WordPress 5.8’den, AVIF 6.5’ten beri çekirdekte desteklenir; AVIF için sunucudaki görüntü kütüphanesinin de bu biçimi tanıması gerekir.
• Lazy load: WordPress görsellere kendiliğinden loading="lazy" ekler ve 6.3’ten itibaren LCP adayı olarak tahmin ettiği görsele fetchpriority="high" verir. Kaydırıcı ve sayfa oluşturucu arka plan görselleri bu tahmine girmez; onları optimizasyon eklentinizin lazy load listesinden hariç tutun, gerekirse ön yükleme (preload) ile önceliklendirin.
• Tema değişince: Eksik küçük boyutları wp media regenerate --only-missing komutuyla yeniden üretin.
• Fontlar: Yalnızca kullandığınız ağırlıkları yükleyin ve fontu kendi sunucunuzdan sunun; blok temalarda Yazı Tipi Kütüphanesi (Font Library, WordPress 6.5) Google Fonts dosyalarını sitenize indirir. font-display: swap metnin font beklenmeden görünmesini sağlar.

Siteyi hangi eklenti yavaşlatıyor?

Yavaşlatan eklentiyi tahminle değil ölçümle bulursunuz; Query Monitor eklentisi her sayfa için sorgu sayısını, yavaş ve yinelenen sorguları ve bunların hangi eklentiden geldiğini gösterir. Denetim adımları:

1. Query Monitor’ü kurun ve yavaş bir sayfayı yönetici olarak açın; yönetici çubuğunda sayfa üretim süresi, bellek ve sorgu sayısı görünür.
2. Queries by Component görünümünde en çok sorgu ve süre harcayan bileşeni not edin; HTTP API Calls bölümü, sayfa açılırken dış sunuculara istek atan eklentileri (lisans kontrolü, uzak font, sosyal sayaç) ortaya çıkarır.
3. Şüpheli eklentiyi bir test kopyasında devre dışı bırakıp aynı ölçümü tekrarlayın. Canlı sitede denemeniz gerekiyorsa Health Check & Troubleshooting eklentisinin sorun giderme modu eklentileri yalnızca sizin oturumunuzda kapatır.
4. İşlevi tema ya da başka bir eklentide zaten bulunan, uzun süredir güncellenmeyen ya da kullanılmayan eklentileri silin; devre dışı bir eklentinin dosyaları da sunucuda durur ve açık barındırabilir, ayrıntı WordPress güvenliği yazısında.

Denetim bitince Query Monitor’ü de devre dışı bırakmak, listeyi bir eklenti daha kısaltır.

Veritabanı nasıl temizlenir: revizyon, transient ve autoload

WordPress veritabanı, yükü artıran üç birikimi sınırlayıp temizleyerek hafifletilir: sınırsız yazı revizyonları, süresi dolmuş geçici veriler (transient) ve her sayfa yüklemesinde belleğe alınan autoload seçenekleri. Revizyon sayısını wp-config.php dosyasında, düzenlemeyi bitirmenizi söyleyen yorum satırından önce ekleyeceğiniz bir satırla sınırlayın:

define( 'WP_POST_REVISIONS', 5 );

Sınır, yazı bir sonraki kayıtta uygulanır; dokunulmayan yazıların eski revizyonları için temizlik eklentisi ya da WP-CLI gerekir. Süresi dolmuş transient’leri wp transient delete --expired temizler. Autoload yükünü görmek için phpMyAdmin’de şu sorguyu çalıştırın (tablo öneki wp_ değilse değiştirin):

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

Listenin başında kaldırdığınız eklentilere ait büyük satırlar varsa, yedek aldıktan sonra silebilir ya da otomatik yüklenmelerini kapatabilirsiniz. WordPress 6.6 ile autoload değerleri yes/no yerine on, off ve auto türevlerine geçtiği için sorgu iki biçimi de kapsar.

PHP sürümü ve WP-Cron neden önemlidir?

Güncel bir PHP 8.x sürümü aynı WordPress kodunu eski sürümlerden daha hızlı çalıştırır; LIONFIN’in Linux tabanlı hosting paketlerinde sürüm panelden seçilir, ancak değiştirmeden önce eklenti uyumunu kontrol edin. Adımlar PHP 8 güncelleme rehberi yazısında.

WP-Cron ise zamanlanmış görevleri gerçek bir zamanlayıcıyla değil, ziyaretçi isteğiyle tetikler. Az ziyaret alan sitede görevler gecikir; sayfa önbelleği PHP’yi atladığı için önbellekli sitelerde gecikme daha da belirginleşir. Çözüm, tetiklemeyi sayfa yüklemesinden alıp sistem cron’una vermektir. wp-config.php dosyasına ekleyin:

define( 'DISABLE_WP_CRON', true );

Ardından beş dakikada bir çalışan bir cron görevi tanımlayın (cPanel’de PHP yolu genellikle /usr/local/bin/php, Ubuntu ve Debian sunucularda /usr/bin/php):

*/5 * * * * /usr/local/bin/php /home/KULLANICI/public_html/wp-cron.php >/dev/null 2>&1

Panelde görev ekleme adımları cPanel cron job oluşturma rehberindedir. WooCommerce gibi görev kuyruğu kullanan eklentilerde aralığı bir dakikaya indirmek gerekebilir.

WordPress hızlandırma kontrol listesi: hangi sırayla?

Adımları etkisine ve riskine göre sıralamak, her değişikliğin sonucunu ayrı ayrı görmenizi sağlar; her adımdan sonra aynı üç sayfayı yeniden ölçün:

CDN’in sona kalmasının nedeni, kazancının büyük ölçüde ziyaretçiyle sunucu arasındaki mesafeye bağlı olmasıdır; ne zaman gerektiği CDN nedir yazısında. Bu WordPress hızlandırma sırasını uyguladığınız hâlde işlemci ya da eş zamanlı işlem sınırına takılıyorsanız darboğaz artık paketin kendisidir; sınırların nasıl okunacağı hosting kaynak limitleri rehberinde anlatılır.