WordPress ve Performans Optimizasyonu
WordPress Performans Optimizasyonu Nereden Başlanır?
WordPress'i hızlandırmak için en çok yapılan hata şudur: neyin yavaşlattığını bilmeden optimizasyona başlamak. Hızlı kazanım vaat eden bir cache eklentisi kurulur, görseller sıkıştırılır, belki bir CDN eklenir. Sonuç bazen iyileşir, bazen hiç değişmez. Değişmeyen durumlarda zaman harcanmış, sorun hâlâ aynı yerde durmaktadır.
WordPress'in yavaşlaması tek bir nedenden kaynaklanmaz. Sorun sunucuda olabilir, temada, bir eklentide, veritabanında ya da görsellerde. Her katmanın katkısı farklıdır ve her katman farklı araçlarla teşhis edilir. Doğru başlangıç noktası, rastgele bir optimizasyon adımı değil, darboğazın nerede olduğunu ortaya çıkaran bir ölçüm aşamasıdır.
Bu yaklaşım daha uzun görünebilir, ama sizi gerçek soruna en kısa yoldan götürür. Temelden başlayarak her katmanı sırayla değerlendirmek hem çabayı azaltır hem de sonucun nereden geldiğini anlamanızı sağlar.
Başlamadan önce ölçüm
Optimizasyona başlamadan önce mevcut durumu sayısal olarak kaydetmek gerekir. Lighthouse ile hem mobil hem masaüstü skorları alınmalı, TTFB, LCP ve TBT değerleri not edilmelidir. Bu sayılar olmadan yapılan değişikliklerin etkisini ölçmek mümkün değildir. "Daha hızlı hissettiriyor" yerine "TTFB 420ms'den 180ms'ye düştü" gibi bir gözlem, gerçek bir iyileşme olduğunu kanıtlar.
Ölçümü bir kez değil, önce-sonra karşılaştırması yapacak şekilde sistematik tutmak gerekir. Her optimizasyon adımı ayrı test edilirse hangi değişikliğin ne kadar katkı yaptığı görünür olur. Tek seferde birden fazla değişiklik yapıldığında hangi faktörün etkili olduğu bilinemez; bu da geliştirme sürecini körleştirir.
Sunucu katmanı: her şeyin temeli
Sunucu yetersizse diğer hiçbir optimizasyon tam potansiyeline ulaşamaz. Paylaşımlı hosting üzerinde çalışan bir WordPress sitesi, kaynakların diğer sitelerle paylaşıldığı bir ortamda yaşar. CPU veya bellek baskısı olduğunda PHP süreçleri kuyruk oluşturur, yanıt süreleri uzar. Bu durumda cache eklentisi bile yardımcı olmaz; cache miss anında PHP başlaması gerektiğinde sunucu meşgulse gecikme kaçınılmazdır.
TTFB değeri sunucu sağlığının temel göstergesidir. Cache'lenmiş bir sayfanın TTFB'si genellikle 100–200ms arasında olmalıdır. Bu değer 500ms'nin üzerindeyse ve sayfa önbelleklenmişse sorun doğrudan sunucudadır. Hosting planını yükseltmek ya da VPS'e geçmek bu noktada diğer tüm optimizasyonlardan daha etkili olabilir. PHP sürümü de bu başlık altında değerlendirilir: PHP 8.x, PHP 7.4'e kıyasla genellikle %10–30 daha hızlı çalışır. Hosting panelinden PHP sürümünü kontrol etmek ilk adımlardan biri olmalıdır.
Tema seçimi ve yüklenme maliyeti
WordPress temalarının performans üzerindeki etkisi çoğunlukla küçümsenir. Görsel açıdan benzer iki tema, sayfa yükleme süreleri açısından dramatik biçimde farklı davranabilir. Kalabalık bir sayfa oluşturucuya (page builder) dayanan temalar, her sayfa yüklemesinde onlarca CSS ve JavaScript dosyası yükler. Bunların büyük bölümü o sayfada hiç kullanılmaz.
Temayla ilgili performans sorununu tespit etmek için geçici olarak Twenty Twenty-Four veya benzeri hafif bir tema etkinleştirilip Lighthouse testi tekrarlanabilir. Skor önemli ölçüde artıyorsa darboğazın büyük bölümü temadan kaynaklanıyor demektir. Bu test, tema değişikliğine karar vermek için yeterli değildir, ama sorunun nerede yoğunlaştığını gösterir. Render blocking kaynaklara yol açan tema varlıkları LCP ve FCP metriklerini doğrudan etkiler.
Eklenti audit: biri bile fark yaratabilir
WordPress eklentilerinin kümülatif etkisi başlıca performans sorunlarından biridir. Her eklenti kendi JavaScript, CSS ve PHP kodunu sayfaya katar. 30–40 aktif eklentili bir site, her sayfa yüklemesinde onlarca harici istek açabilir. Bunların bir kısmı render blocking'dir, bir kısmı main thread'i bloklar.
Eklenti audit'in ilk adımı, aktif eklentilerin listesini çıkarmak ve gerçekten kullanılanları belirlemektir. Devre dışı bırakılan ama silinmeyen eklentiler performansı etkilemez; ancak aktif ama nadiren kullanılan eklentiler her sayfa yüklemesinde yük taşır. Sonraki adım ise hangi eklentinin ne kadar yük kattığını ölçmektir. Bunu yapmak için eklentiler tek tek devre dışı bırakılıp Lighthouse testi tekrarlanabilir — ancak bu yöntem zaman alır. Daha verimli bir yaklaşım için Query Monitor eklentisi ve Health Check & Troubleshooting eklentisi faydalıdır.
Query Monitor ile veritabanı ve PHP analizi
Query Monitor, WordPress için en değerli teşhis araçlarından biridir. Sayfa başına yapılan veritabanı sorgu sayısını, her sorgunun süresini, hangi eklenti veya temanın sorguyu tetiklediğini ve PHP hata günlüklerini doğrudan yönetici arayüzünde gösterir. Kurulum ücretsizdir ve üretim ortamında yalnızca giriş yapmış yöneticilere görünür.
Özellikle dikkat edilmesi gereken iki gösterge vardır: toplam sorgu sayısı ve toplam sorgu süresi. Basit bir blog yazısı sayfası için 30–50 sorgu makul sayılabilir; 200'ün üzerinde sorgu varsa tema veya bir eklenti aşırı veritabanı kullanımı yapıyor demektir. Toplam sorgu süresi 300ms'yi geçiyorsa veritabanı optimizasyonu veya object cache devreye alınmalıdır. Query Monitor aynı zamanda yavaş sorguları da listeler; bu sorgular doğrudan optimize edilebilir veya önbelleğe alınabilir.
admin-ajax.php yükü
WordPress'te admin-ajax.php dosyası, ön yüz isteklerini de karşılamak için kullanılır. Bazı eklentiler form işlemleri, anlık bildirimler veya özel AJAX çağrıları için bu dosyaya aşırı yük bindirer. Her admin-ajax.php isteği tam WordPress bootstrap'ı çalıştırır — tüm eklentiler ve tema yüklenir. Sayfada onlarca böyle istek varsa bu tek başına ciddi bir yavaşlama kaynağı olabilir.
Tarayıcı geliştirici araçlarında Network sekmesi filtrelenerek admin-ajax.php'ye giden istekler görüntülenebilir. Bu isteklerin sayısı, süreleri ve hangi action parametresiyle çağrıldıkları incelenmelidir. Gereksiz ya da aşırı sıklıkta çağrılan AJAX aksiyonları tespit edildikten sonra ilgili eklentinin ayarları gözden geçirilir ya da REST API tabanlı alternatifler değerlendirilir.
Veritabanı tablo şişmesi ve otomatik taslaklar
WordPress veritabanı, uzun süre temizlenmediğinde gereksiz verilerle dolar. Otomatik taslaklar (post_status = auto-draft), revizyon geçmişi, silinmiş yorum ve gönderi kalıntıları, süresi dolmuş transient kayıtlar wp_posts ve wp_options tablolarını şişirir. Binlerce revizyon veya yüzlerce süresi dolmuş transient, sorgu sürelerini gözle görülür biçimde uzatır.
wp_options tablosundaki autoload değeri "yes" olan kayıtlar özellikle dikkat gerektirir. Her WordPress yüklemesinde bu kayıtlar bellekte tutulur. Büyük boyutlu autoload verileri bellek tüketimini artırır ve ilk yükleme süresini uzatır. WP-Optimize veya benzeri bir araçla düzenli veritabanı temizliği bu yükü azaltır; ancak temizlik işlemi üretim veritabanında yapılmadan önce yedek almak şarttır.
Görsel boyutu ve format optimizasyonu
Görseller WordPress sitelerinin en büyük yük kalemlerinden birini oluşturur. Orijinal fotoğraf boyutunda yüklenen bir görsel, sayfada küçük bir thumbnail olarak görünse de tam boyutuyla indirilir. Bu hem bant genişliği hem de yükleme süresi israfıdır. WordPress kendi medya boyutlandırmasını yapar, ancak orijinal dosya gereksiz büyükse bu boyutlandırma da büyük kaynaklardan çalışır.
WebP formatına geçiş birçok senaryoda JPEG'e kıyasla %25–35 boyut azaltımı sağlar. WordPress 5.8'den itibaren WebP desteği temel olarak mevcuttur; ancak dönüştürme işlemi için ek bir araç gerekir. Lazy loading viewport dışındaki görsellerin başlangıç yükünü erteleyerek LCP'yi doğrudan etkiler. Bu özellik modern WordPress sürümlerinde loading="lazy" ile otomatik uygulanır, ama hero görselin yanlışlıkla lazy olarak işaretlenmesi LCP'yi ciddi biçimde yavaşlatır.
JavaScript ve CSS yükleme sırası
WordPress, her eklenti ve temanın kendi varlıklarını sıraya eklemesine izin verir. Kötü önceliklendirilmiş bir JavaScript dosyası sayfanın render edilmesini engelleyebilir. Render blocking script'ler LCP ve FCP üzerinde doğrudan negatif etki yaratır. wp_enqueue_script ile kuyruğa alınan script'ler $in_footer parametresiyle footer'a taşınabilir; bu değişiklik başlı başına önemli bir iyileşme sağlayabilir.
JavaScript yükünü azaltmak için kullanılmayan script'lerin devre dışı bırakılması gerekir. Bazı eklentiler tüm sayfalarda script yükler; oysa yalnızca belirli sayfalarda çalışmaları gerekir. Asset CleanUp veya Perfmatters gibi araçlar, hangi sayfada hangi eklentinin script'ini devre dışı bırakacağınızı sayfa bazında yönetmenizi sağlar. Bu yaklaşım özellikle blog yazısı sayfalarında contact form, slider veya e-ticaret script'lerini devre dışı bırakmak için değerlidir.
Önbellekleme: doğru sıra ve doğru katman
Önbellekleme, performans optimizasyonunun son katmanıdır, ilk değil. Sunucu yeterli değilse, veritabanı şişmişse ve eklenti yükü ağırsa önbellekleme bu sorunları gizler ama çözmez. Cache hit oranı yüksek olduğu sürece sorun görünmez; ancak cache miss'lerde performans düşüşü katlanarak büyür.
Önbellekleme kurulduktan sonra doğru çalışıp çalışmadığını doğrulamak gerekir. HTTP yanıt başlıklarında cache hit durumunu kontrol etmek, giriş yapmış kullanıcılar için doğru bypass yapılandırmasının aktif olduğunu teyit etmek ve WooCommerce gibi dinamik yapılarda sepet ve ödeme sayfalarının önbelleklenmediğini kontrol etmek bu doğrulamanın parçasıdır. Yanlış yapılandırılmış önbellekleme, bir kullanıcının sepetini başka bir kullanıcıya gösterebilir — bu hem performans hem güvenlik sorunudur.
Hangi sıradan başlamamak gerekir?
Görselleri sıkıştırmak veya bir cache eklentisi kurmak cazip başlangıç noktaları gibi görünür. Görünür ve ölçülebilir iyileşme sağlayabildiklerinde değerlidirler. Ancak sorun sunucu kapasitesindeyse ya da her sayfa yüklenmesinde 400 veritabanı sorgusu yapılıyorsa, görselleri optimize etmek bu sorunu etkilemez.
Aynı şekilde premium bir tema veya eklenti satın almak da sıklıkla başvurulan bir adımdır. Pahalı bir sayfa oluşturucu teması, ucuz ve hafif bir temadan daha yavaş olabilir. Ücret bir kalite göstergesi değildir; performans göstergesi sayıların kendisidir. Ölçüm önce, karar sonra gelir. Bu sıra tersine çevrildiğinde hem para hem zaman harcanır, performans ise yerinde sayar.
WordPress performans optimizasyonunda başlangıç noktası her zaman ölçümdür. TTFB, Lighthouse skorları ve Query Monitor verileri bir arada değerlendirildiğinde darboğazın hangi katmanda olduğu netleşir. Bu netlik olmadan yapılan optimizasyon tahmine dayalı çalışmadır; zaman zaman işe yarar, ancak sistematik ve sürdürülebilir bir iyileşme sağlamaz.
Sunucu kapasitesi yeterliyse, PHP güncel sürümdeyse, veritabanı temizse ve eklenti yükü makul düzeydeyse o zaman görsel optimizasyonu, JavaScript ertelemesi ve önbellekleme çok daha etkili sonuç üretir. Temeli sağlam kurmak, üstüne eklenen her optimizasyonun maksimum kazanım sağlamasına zemin hazırlar.
Kesin bir "herkes için en iyi sıra" yoktur çünkü her sitenin darboğazı farklıdır. Ama evrensel olan şey şudur: ölçmeden başlamak, doğru soruyu sormadan cevap aramak demektir. Verilerle başlayan bir optimizasyon süreci hem daha kısa sürer hem de etkisini sayısal olarak kanıtlayabilir.