WordPress'te Performansı En Çok Bozan Eklentiler

Sayfa Oluşturucular: Asıl Maliyet Nerede Saklanır?

Elementor, WPBakery, Divi gibi sayfa oluşturucular (page builder) sitenizin görünümünü kodsuz oluşturmanıza olanak tanır. Performans bedeli ise çoğunlukla CSS ve JavaScript dosya sayısında değil, HTML çıktısının boyutunda ve veritabanı sorgu yükünde gizlenir.

Sayfa oluşturucular içeriği genellikle post_meta tablosunda serileştirilmiş veri olarak saklar. Her sayfa yüklenişinde bu veri çözümlenir, blok ağacı yeniden işlenir ve HTML üretilir. Karmaşık bir şablon, standart bir WordPress sayfasına kıyasla birkaç kat fazla veritabanı sorgusu çalıştırabilir. Query Monitor'un "Queries by Component" sekmesi bu sorguları eklentiye göre gruplar; hangi bileşenin kaç milisaniye harcadığını orada görebilirsiniz.

Bir diğer maliyet kaynağı harici betiklerdir. Bazı sayfa oluşturucular kendi animasyon ve etkileşim kütüphanelerini her sayfaya yükler; o sayfada ilgili widget kullanılmasa bile bu betikler yükleme zincirine girer. LCP'nin kritik olduğu ürün veya açılış sayfalarında bu durum fark edilir gecikme üretir.

Sayfa oluşturucu ne zaman sorun çıkarır:

• On'dan fazla bölüm içeren ve her bölümde animasyon barındıran sayfalar.
• Mobil görünümde gizli ama yine de yüklenen bileşenler; eklenti bu ayrımı CSS ile yapıyorsa JavaScript hâlâ çalışır.
• Üst üste iç içe geçmiş blok yapıları; her katman ek PHP işlemi ve sorgu demektir.

Ne zaman sorun çıkarmaz: tek şablonlu, az bileşenli, statik içerikli tanıtım sayfaları. Sayfa oluşturucu kullanıyorsunuz ama sayfa yalın tutulmuşsa maliyeti yönetilebilir kalır.

Slider Eklentileri: Görünmeyen Yük

Kaydırıcı (slider) eklentileri arasında en çok kullanılanlar, sayfada slider bulunmasa bile JavaScript ve CSS'ini her sayfaya yükleyen global enqueue yapısına sahiptir. Bu, sitenin her sayfasına gereksiz ağırlık ekler.

Slider çoğunlukla LCP adayı öğe içerir. Büyük bir banner görseli veya tanıtım metni LCP öğesi olduğunda, slider bileşeninin kendi yükleme mantığı bu öğenin ne zaman render edileceğini etkiler. Preload edilmemiş, JavaScript'e bağımlı bir banner görselinin LCP değerini nasıl artırdığını görmek için Chrome DevTools'un Performance sekmesindeki filmstrip görünümü yeterlidir. LCP öğesini nasıl tespit edeceğinize bakarak slider'ın LCP adayı olup olmadığını kolayca doğrulayabilirsiniz.

Slider her zaman kötü değildir. Anasayfada güçlü bir görsel anlatım istendiğinde ve slider görseli doğru önceliklendirildiğinde fark yönetilebilir. Sorun, eklentinin tüm sayfalara yüklendiği ve slider öğesinin LCP'yi etkileyen ilk görsel olduğu durumda ortaya çıkar.

Karar noktası nettir: slider gerçekten gerekli mi, yoksa statik bir hero görseli aynı işi görür mü? İkincisi çoğu durumda daha az bağımlılık, daha az çalışma süresi demektir.

Sosyal Medya Widget'ları: Üçüncü Taraf Gecikmeleri

Sosyal medya gömme araçları ve paylaşım düğmeleri, üçüncü taraf (third-party) isteklere bağımlıdır. Bu istekler sunucunuzun kontrolünde değildir; hedef sunucunun yanıt süresi, ziyaretçinin bağlantı kalitesi ve coğrafi konuma göre değişir.

Bir Twitter/X gömme veya Facebook yorum kutusu, o sosyal ağın CDN'ine bağımlı script dosyalarıyla gelir. Tarayıcı bu script'leri indirip çalıştırmadan önce ana içerik yüklemesi bekletiliyorsa, TBT (Total Blocking Time) değeri yükselir. Network panelinde "Initiator" sütunu bu zincirleri kaynağa bağlamayı kolaylaştırır.

Asıl sorun render-blocking davranışı değil, gecikme yayılımıdır. Bir paylaşım düğmesi kitaplığı kritik CSS'i engellemese bile birden fazla üçüncü taraf isteği ağ bantını parçalar ve diğer kaynakların indirilmesini yavaşlatır.

Üçüncü taraf yükleme davranışını değerlendirirken şu noktalara bakın:

• Widget her sayfada mı yükleniyor, yoksa yalnızca kullanıldığı sayfada mı? Çoğu eklenti bu ayrımı yapmaz ve global olarak yükler.
• Script "High" öncelikle mi yükleniyor? Network panelindeki Priority sütunu bunu gösterir; kritik kaynaklarla rekabet edip etmediğini buradan anlayabilirsiniz.
• Lazy load uygulanabilir mi? Görünür alandan uzakta olan gömme içerikler ertelenebilir ve kritik yoldan çıkarılabilir.

Güvenlik Eklentileri: TTFB'ye Eklenen PHP Katmanı

Güvenlik eklentileri WordPress isteğinin en erken aşamasında devreye girer. Bazıları her PHP isteği işlenmeden önce kendi imza veritabanını kontrol eder ve gelen trafiği filtreler. Bu filtreleme gerçek bir güvenlik değeri sağlar, ama TTFB değerini doğrudan etkiler.

TTFB artışı sabit değildir. Tarama frekansı yüksek tutulmuşsa ve site trafik yoğunluğu fazlaysa, her istek için harcanan milisaniye çarpılır. Buna ek olarak bazı güvenlik eklentileri kendi tablolarını veritabanında oluşturur ve her sayfaya ek sorgu ekler. Query Monitor'da kırmızıyla işaretlenen yavaş sorgular arasında güvenlik tablolarına yapılan denetim sorgularını görmek yaygın bir tablodur.

Güvenlik eklentisini devre dışı bırakmak genellikle doğru yanıt değildir. Doğru yaklaşım şu adımları kapsar:

• Hangi özelliklerin aktif olduğunu tek tek kontrol edin; çoğu kurulum tüm modülleri varsayılan açık bırakır.
• Tarama ve denetim programlarını trafik yoğunluğunun düşük olduğu saatlere kaydırın.
• Güvenlik duvarı kurallarının web sunucusu katmanında (Nginx/Apache) uygulanıp uygulanamayacağını değerlendirin; bu PHP'ye ulaşmadan filtreleme sağlar.

Güvenlik ile performans arasındaki denge kurulabilir. Kurulmadan bırakılırsa ikisi de zarar görür.

Query Monitor ile Eklenti Etkisini Ölçmek

Query Monitor, WordPress yöneticisine bir araç çubuğu ekler ve her sayfa yüklemesinde çalışan PHP süresini, veritabanı sorgularını ve bunları başlatan eklentileri listeler. Performans sorununu hissedip de nereden kaynaklandığını bilmiyorsanız buradan başlamak mantıklıdır.

"Queries by Component" görünümü her eklentinin toplam sorgu sayısını ve harcadığı süreyi gösterir. Tek bir eklentinin onlarca sorgu çalıştırdığını gördüğünüzde önce bu sorguların hangi koşulda tetiklendiğine bakın. Bazı eklentiler yalnızca belirli içerik türlerinde veya yönetici panelinde ekstra sorgu çalıştırır; bu durumda sayfa performansını etkilemeyebilir. Bazıları ise her ziyarette aynı sorguları tekrarlayan bir yapıya sahiptir; sorgu önbelleklemesi yoksa her yükleme aynı maliyeti yeniden öder.

PHP çalışma süresi de ayrı bir gösterge. Toplam TTFB'nin büyük bölümü sunucu tarafı işlemden geliyorsa ve güvenlik, form veya analitik eklentileri listede üst sıralardaysa, bu eklentilerin yapılandırmasını gözden geçirmeye değer.

Query Monitor sonuçlarını değerlendirirken dikkat edilmesi gereken noktalar:

• Sorgu sayısı değil, sorgu süresi daha belirleyicidir. Yüz hızlı sorgu, beş yavaş sorgudan daha az zarar verebilir.
• N+1 sorgu örüntüsünü arayın: liste sayfalarında her öğe için ayrı bir sorgu çalışıyorsa bu tipik bir N+1 durumudur.
• Sayfa yükleme süresini yüzde olarak değil, milisaniye olarak okuyun. "Toplam sürenin yüzde kırkı" söylemi kaynak sıralaması için yararlıdır ama mutlak büyüklük olmadan yanıltıcı olabilir.

Tanılama sürecinin daha geniş çerçevesini görmek istiyorsanız, performans sorununu düzeltirken önce neye bakılacağına dair yazı TTFB ile render sorunlarını birbirinden ayırmak için iyi bir başlangıç noktası sunar.

Network Panelinde Eklenti İzini Bulmak

Chrome DevTools'un Network paneli sunucu tarafını değil tarayıcı tarafını gösterir. Buradan görülen gecikme, eklentilerin JavaScript ve CSS dosyalarından, başlattıkları harici isteklerden ve bu isteklerin render zincirine nasıl girdiğinden kaynaklanır.

Filtre çubuğuna eklentinin klasör adını yazdığınızda, örneğin /plugins/eklenti-adi/, yalnızca o eklentinin kaynaklarını filtreleyebilirsiniz. Kaç dosya yüklüyor, toplam boyut ne kadar, ilk byte hangi süreye denk geliyor; bunlar Network panelinde doğrudan ölçülebilir büyüklükler. Waterfall görünümünde bir kaynağın diğer kaynakların önünde mi yoksa arkasında mı yüklendiğini görmek, render-blocking bağımlılıkları tespit etmenin en hızlı yoludur.

TTFB düşük ama FCP yüksekse sorun sunucuda değil render zincirindedir. Render zincirinin nasıl analiz edileceğini anlayan biri için Network panelindeki waterfall okunabilir hale gelir; hangi eklenti dosyasının ilk boyamayı geciktirdiği görünür olur.

Üçüncü taraf isteklerin bir kısmı kaçınılmazdır: analitik, A/B test araçları, canlı sohbet. Bunları izlemek için "Priority" sütununu açık tutun. "High" öncelikli üçüncü taraf kaynaklar kendi kritik kaynaklarınızla rekabet ediyor demektir ve bu durumda erteleme veya lazy load alternatifleri değerlendirilmelidir.

Eklenti Yığınını Değerlendirmek: İkili Ayrımla Test

En güvenilir tanılama yöntemi ikili ayrımla (binary split) yapılan devre dışı bırakma testidir. Tüm eklentileri kapatın, TTFB ve LCP değerini ölçün, ardından eklentileri gruplar halinde açarak her adımda tekrar ölçün. Değerin sıçradığı grup sorumlu adaydır; o grubu yarıya bölüp aynı işlemi tekrarlayın.

Bu test birkaç koşulda yanıltıcı sonuç verebilir:

• Cache eklentisi aktifse bazı farklar maskelenir. Her ölçüm öncesinde önbelleği temizlemek zorunludur.
• Test ortamı canlı ortamdan farklı bir sunucu yapılandırması kullanıyorsa PHP süre değerleri karşılaştırılamaz.
• Bazı eklentiler yalnızca oturum açmış kullanıcılarda veya yönetici panelinde ek yük üretir; genel ziyaretçi deneyimini etkilemeyebilir.

Cache eklentisinin kendisi de zaman zaman sorunun bir parçasıdır. Yanlış yapılandırılmış bir cache katmanı, önbellek bypass durumlarında her isteği sıfırdan işletebilir. LiteSpeed Cache'in gerçek etki alanını inceleyen yazı, cache eklentilerinin performans tanılamasını nasıl karmaşıklaştırabileceğini somutlaştırıyor.

Devre dışı bırakma testini tamamladıktan sonra sorunlu eklenti için üç seçenek vardır: yapılandırmayı sadeleştirmek, alternatif bir eklentiyle değiştirmek veya o işlevi tamamen kaldırmak. Bu kararı verirken eklentinin ürettiği değer ile performans maliyetini karşılaştırmak gerekir; her eklenti için bu denge farklı çıkar.