WordPress site yavaş açılıyor: eklenti mi, tema mı, sunucu mu.

WordPress site yavaş açılıyorsa neden çoğu zaman şu kaynaklardan birindedir: sunucunun sayfayı üretme süresi, temanın ve eklentilerin her sayfaya eklediği dosyalar ya da gereğinden büyük görseller. Hangisinin sizin sitenizde süreyi uzattığı, her seferinde tek bir şeyi değiştirip aynı ölçümü tekrarlayarak bulunur.

WordPress’in kendisi yavaş bir yazılım değildir; yavaşlık onun etrafında kurulan her şeyin toplamından çıkar. WordPress’in kendi performans belgesi hızı etkileyen kalemleri tek tek sayar: barındırma ortamı ve donanımı, PHP ve veritabanı yazılımlarının sürümü, tema ve eklenti seçimi, görsellerin boyutu ve sayısı, veritabanının verimliliği, sunucunun yükü ve ziyaretçiye uzaklığı. Aynı temayla kurulmuş iki site bu kalemlerin farklı birleşimleriyle bambaşka hızlarda açılabilir.

Bu yüzden bu yazıda «şu eklenti sayfaya şu kadar süre ekler» türünden sayılar yok. Aynı eklenti iki sitede farklı maliyet çıkarır ve genel geçer bir sayı sizi yanlış yere götürür. Onun yerine, nedenin sizin sitenizde nerede olduğunu kendi başınıza ayırmanın yolunu anlatıyoruz. Ölçüp düzeltmeyi bize bırakmak isterseniz site hızı optimizasyonu sayfası süreci anlatıyor; WordPress’e özgü olmayan genel nedenlerin listesi ise siteniz neden yavaş açılıyor yazısında.

Sorun sunucuda mı, tarayıcıda mı?

İlk ayrım budur ve iki ayrı dünyayı birbirinden ayırır. WordPress her ziyaret için sayfayı PHP ile veritabanından üretir; bu iş sunucuda olur ve süresi ilk bayt süresi (TTFB) olarak ölçülür. Sayfa üretilip gönderildikten sonra tarayıcı temanın ve eklentilerin çağırdığı stil, betik, görsel ve yazı tipi dosyalarını indirir; bu da tarayıcı tarafıdır. Önbellek eklentisi birinci tarafı hızlandırır, ikinci taraftaki yükü azaltmaz.

Nasıl anlaşılır: Chrome’da F12 ile geliştirici araçlarını açın, Ağ (Network) sekmesinde «Disable cache» (önbelleği kapat) kutusunu işaretleyip sayfayı yenileyin. Listenin ilk satırı sayfanın kendisidir; üstüne tıklayıp Timing (zamanlama) bölümündeki «Waiting for server response» süresine bakın. web.dev çoğu site için 0,8 saniye ya da altını hedef gösterir. Bu süre birkaç yenilemede sürekli uzunsa önce sunucuya bakılır; kısa olduğu hâlde sayfa geç görünüyorsa sorun tarayıcıya giden yüktedir. Konunun teknik tarafı: TTFB ve sunucu yanıtı.

Bir uyarı: WordPress’e yönetici olarak giriş yapmışken yaptığınız ölçüm, ziyaretçinin gördüğünü göstermeyebilir. Birçok önbellek kurulumu oturum açmış kullanıcıya sayfayı her seferinde yeniden üretir ve yönetici çubuğu gibi ek dosyalar yükler. Ölçümü gizli pencerede, oturum kapalıyken yapın.

Sunucu yavaşsa neye bakılır?

Sunucu tarafında üç soru sırayla sorulur. Birincisi barındırma: kalabalık bir paylaşımlı sunucuda sitenizin payına düşen işlemci ve bellek, trafiğin yoğun olduğu saatlerde yetmeyebilir. İkincisi yazılım sürümleri: WordPress belgesi PHP, veritabanı ve web sunucusu yazılımlarının güncel tutulmasını performans kalemi olarak sayar. Üçüncüsü sayfa önbelleği: her ziyarette aynı sayfayı veritabanından yeniden üretmek yerine hazır bir kopyasını göndermek.

WordPress’in kendi belgesi önbelleği en az zahmetle en büyük kazancı veren adım olarak anar ve bu sunucu tarafı için doğrudur. Ama önbellek eklentisi kurulduktan sonra sayfa hâlâ yavaşsa sorun büyük olasılıkla artık sunucuda değildir; bir sonraki bölüme geçin.

Hangi eklenti yavaşlatıyor, nasıl anlaşılır?

WordPress belgesi de aynı yolu önerir: eklentileri seçerek devre dışı bırakıp performansı ölçmek. Yöntemin güvenilir olması birkaç kurala bağlıdır:

• Canlı sitede değil, sitenin bir kopyasında (hazırlık ortamında) çalışın; eklenti kapatmak formları ve ödeme akışlarını bozabilir.
• Önce taban ölçümü alın: aynı sayfa, aynı araç, aynı cihaz profili; en az beş koşum ve ortanca değer. Tek koşum iki eklenti arasındaki farkı gürültüden ayıramaz.
• Eklentileri birer birer kapatın ve her kapatmadan sonra aynı ölçümü tekrarlayın.
• Her satıra kapatılan eklentiyi, ilk bayt süresini, toplam aktarılan veriyi ve istek sayısını yazın.
• Farkı büyük olanları not edin, sonra hepsini geri açın. Kararı tablo verir, sezgi değil.

Tarayıcı tarafında daha hızlı bir kestirme var. WordPress’te eklenti dosyaları «/wp-content/plugins/eklenti-adi/» klasöründen, tema dosyaları «/wp-content/themes/tema-adi/» klasöründen gelir. Ağ sekmesinin süzgeç kutusuna «plugins» yazdığınızda yalnız eklentilerin indirdiği dosyalar kalır ve her satırın adresinde hangi eklentiye ait olduğu okunur. Böylece iletişim formu eklentisinin betiğinin formun olmadığı sayfalarda da inip inmediğini ya da bir galeri eklentisinin bütün siteye stil dosyası yükleyip yüklemediğini tek bakışta görürsünüz. Geliştirici araçlarındaki Coverage (kapsam) paneli de inen kodun ne kadarının o sayfada hiç kullanılmadığını gösterir.

Eklenti sayısı mı önemli, ne yaptıkları mı?

WordPress belgesi hem eklenti sayısının hem de eklentilerin kendi performansının hıza büyük etkisi olduğunu yazar ve gereksiz eklentileri kaldırmayı önemli bir iyileştirme olarak sayar. Pratikte asıl soru sayıdan çok davranıştır: sunucuda her istekte ağır bir iş yapan tek bir eklenti, yalnız yönetim panelinde çalışan birkaç eklentiden daha pahalı olabilir. Her eklenti için üç soru sorun: ziyaretçinin gördüğü sayfaya dosya ekliyor mu, bunu her sayfada mı yapıyor ve yaptığı iş temada ya da tarayıcının kendisinde zaten var mı?

Tema mı ağır?

Çok amaçlı temalar ve sayfa oluşturucular her türlü siteye uysun diye kurulur; sizin kullanmadığınız slaytlar, animasyonlar ve bileşenler için de stil ve betik gönderebilirler. Temanın payını ayırmanın yolu yine tek değişkenli ölçümdür: sitenin kopyasında eklentiler sabitken temayı WordPress’in varsayılan temalarından birine geçirip aynı sayfayı aynı koşullarda ölçün. Aradaki fark, temanın bedelinin kabaca bir göstergesidir. Ağ sekmesinde «themes» süzgeci ve Coverage panelindeki kullanılmayan stil oranı aynı soruya ikinci bir açıdan cevap verir.

Görseller ve gömülü içerik ne kadar pay alıyor?

WordPress’te görseller çoğu zaman fotoğraf makinesinden ya da tasarım programından çıktığı boyutta yüklenir. Ağ sekmesinde Img (görsel) süzgecini seçip Size (boyut) sütununa göre sıralayın; sayfanın en ağır dosyası genellikle bir görseldir ve çoğu zaman sayfanın ana içeriği sayılan LCP öğesidir. Gömülü video ve harita gibi başka sunuculardan gelen içerik de ayrı bir kalemdir; Domain (alan adı) sütununu açtığınızda kendi alan adınız dışından gelen her satırı görürsünüz.

Hızlandırma eklentisi kurmak yeterli mi?

Hızlandırma eklentileri dosyaları birleştirir, betikleri erteler, görselleri küçültür. Bazı sitelerde gerçek kazanç sağlar; ama bir yükü ortadan kaldırmaz, çoğu zaman sırasını değiştirir. Ertelenen bir betik sayfanın ilk açılışını hızlandırırken ilk tıklamayı geciktirebilir; birleştirilen dosyalar düzen kaymasına ya da bozuk bir menüye yol açabilir. Kural basit: her ayar değişikliğinden sonra aynı ölçümü tekrarlayın ve yalnız ölçümün iyileştiğini gösterdiği ayarı bırakın.

Bu yöntemi kendi sitemizde nasıl uyguladık?

Bu site WordPress’le değil kendi üreticimizle kurulu, ama yavaşlığı ayırma yöntemi aynı. Bir turun ardından ana sayfanın toplam engelleme süresi birden arttı. İlk şüpheli o turda eklenen JavaScript’ti; ölçüm başka bir yeri gösterdi. Stil kurallarını aileler hâlinde, her seferinde tek bir aileyi çıkararak denedik ve her denemede engelleme süresinin ortancasını okuduk. Bütün :has() seçicileri çıkarıldığında süre 369 milisaniyeden 104 milisaniyeye iniyordu; yalnız sayfanın köküne bağlı olanlar çıkarıldığında 115 milisaniyeye. Yük tek bir aileye toplanmıştı ve o kurallar ana sayfada hiçbir şeyi boyamıyordu. Düzeltmeden sonra süre 97–108 milisaniyeye indi. Ayrıntısı bir :has() seçicisinin engelleme süresine etkisi yazısında.

Eklentilere en çok benzeyen deneyimimiz ise kütüphaneler oldu. Kaydırmayı yöneten iki kütüphaneyi kaldırmadan önce kendimize şunu sorduk: bu işi tarayıcının kendisi yapabiliyor mu? Yapabiliyordu; kütüphaneler gidince sıkıştırılmış JavaScript 51,1 kilobayttan 33,5 kilobayta indi. WordPress’te karşılığı, bir eklentiyi kaldırmadan önce yaptığı işin temada ya da tarayıcıda zaten var olup olmadığını sormaktır.

Bir değişkeni değiştir, aynı ölçümü tekrarla; kararı tablo versin.

Hızlandırmak mı, yeniden kurmak mı?

Ölçüm tablosu bu soruya da cevap verir. Yük birkaç eklentide ve birkaç büyük görselde toplanıyorsa mevcut siteye müdahale yeterlidir ve genellikle daha ucuzdur. Tema ya da sayfa oluşturucu sitenin her sayfasına ağır bir taban yük ekliyorsa ve bu yük temayı değiştirmeden kalkmıyorsa, yeniden kurmak uzun vadede daha ucuz olabilir. İçeriğin ne sıklıkla ve kim tarafından değiştiği de bu kararın parçasıdır; iki yapının farkını statik site mi, içerik yönetim sistemi mi yazısında anlattık.

Hangi yol seçilirse seçilsin, kazanılan hız korunmazsa geri gider: her yeni eklenti, her yeni kampanya görseli yükü biraz artırır. Sitenin aşamayacağı sınırları yazmak ve her güncellemeden sonra ölçmek bu yüzden işin parçasıdır; nasıl kurulacağı performans bütçesi rehberinde. Ölçümün kendisinin neden her seferinde farklı sonuç verdiğini merak ediyorsanız: site hızı nasıl ölçülür.