Tema ve eklenti seçiminin hıza etkisi, bir sitenin performansını belirleyen kararların içinde geri alması en zor olanıdır. Sunucunu yükseltebilirsin, önbellek kurabilirsin, görsellerini sıkıştırabilirsin — bunların hepsi bir günlük iştir. Ama iki yıldır içerik ürettiğin bir temayı değiştirmek, tüm sayfa düzenlerini yeniden kurmak demektir ve çoğu kişi bu yüzden yavaş bir temanın üzerine ömür boyu yama atmayı seçer.
Bu yazıda tema ve eklentilerin siteyi tam olarak hangi mekanizmayla yavaşlattığını, "az eklenti kullan" tavsiyesinin neden yetersiz olduğunu, satın almadan önce bir temayı nasıl test edeceğini ve mevcut sitende hangi eklentinin ne kadar süre yediğini nasıl ölçeceğini anlatacağım. Sonunda da eklentiyi kaldırmadan hafifletmenin yollarını ve en sık düşülen tuzakları bulacaksın.
Bir Tema Siteyi Nasıl Yavaşlatır#
Tema, siteni üç ayrı katmanda yavaşlatabilir ve bunların hangisi olduğunu bilmeden düzeltme yapamazsın. Birinci katman sunucu tarafıdır: tema her sayfa yüklemesinde veritabanına ne kadar sorgu atıyor, ne kadar PHP çalıştırıyor. Kötü yazılmış temalar döngü içinde sorgu açar, ayarlarını her seferinde yeniden okur ve ilgisiz sayfalarda bile ağır işler yapar. Bu katmanın belirtisi yüksek TTFB'dir.
İkinci katman varlık yüküdür: temanın yüklediği CSS ve JavaScript dosyalarının sayısı ve boyutu. Çok amaçlı (multipurpose) temalar burada kötü şöhretlidir; her ihtimale karşı slider kütüphanesi, ikon seti, animasyon motoru, galeri büyüteci ve birkaç yazı tipi ailesini her sayfaya yükler. Sen bunların hiçbirini kullanmıyor olsan bile ziyaretçin hepsini indirir.
Üçüncü katman çizim maliyetidir: temanın ürettiği HTML'in derinliği ve karmaşıklığı. Beş kat iç içe sarmalayıcı ile kurulmuş bir düzen, tarayıcının düzen (layout) hesaplamasını ağırlaştırır ve bu maliyet özellikle mobil işlemcilerde hissedilir. Bir sayfada binlerce DOM düğümü varsa, hiçbir önbellek bu maliyeti ortadan kaldıramaz; çünkü iş sunucuda değil kullanıcının cihazında yapılır.
| Belirti | Muhtemel katman | Nereye bakılır |
|---|---|---|
| TTFB yüksek, sayfa küçük | Sunucu tarafı | Sorgu sayısı, PHP süresi |
| TTFB düşük, yükleme uzun | Varlık yükü | İstek sayısı, toplam boyut |
| Yükleme bitti ama sayfa donuk | Çizim maliyeti | DOM düğüm sayısı, JS çalışma süresi |
| Mobilde masaüstünden çok kötü | Çizim + JS | Ana iş parçacığı bloklama |
Bu ayrımı ilk adımda yapmak, haftalarca yanlış yerde çalışmanı önler. Ölçüm yöntemini site hızı ve SEO ilişkisi yazısındaki metrik eşikleriyle birlikte kullanırsan tabloyu tamamlamış olursun.
Eklenti Sayısı mı Eklenti Kalitesi mi#
"20 eklentiden fazlasını kullanma" tavsiyesini sık duyarsın ve bu tavsiye yanlıştır. Sayı tek başına hiçbir şey söylemez. Yalnızca bir yönetici ayarını değiştiren, ön uçta hiçbir kod çalıştırmayan on eklenti, sitene neredeyse hiçbir maliyet getirmez. Buna karşılık tek bir kötü yazılmış eklenti, her sayfa yüklemesinde 200 sorgu atarak siteyi tek başına dize getirebilir.
Doğru soru şudur: bu eklenti ön uçta ne yapıyor? Cevaba göre eklentileri kabaca üç sınıfa ayırabilirsin. Birinci sınıf, yalnızca yönetim panelinde çalışanlardır (yedekleme, kullanıcı yönetimi, içe aktarma araçları); bunların ziyaretçiye maliyeti sıfıra yakındır. İkinci sınıf, ön uçta çalışan ama kendi varlık dosyası yüklemeyenlerdir (SEO eklentileri, yönlendirme yöneticileri); maliyetleri düşüktür. Üçüncü sınıf ise her sayfaya kendi CSS ve JavaScript'ini ekleyenlerdir (slider, form, galeri, sosyal paylaşım, canlı destek); asıl yük buradadır.
Üçüncü sınıftaki eklentilerin kritik sorunu, koşulsuz yükleme yapmalarıdır. İletişim formu eklentisi yalnızca iletişim sayfasında gerekir ama varsayılan davranışı kendi dosyalarını 500 sayfanın hepsine eklemektir. Bir sitede bu tür beş eklenti varsa, ana sayfa hiç kullanılmayan beş ayrı kütüphaneyi indiriyor demektir.
Bir eklentiyi kurmadan önce sorman gereken üç soru var:
- Bu işlevi tema ya da mevcut bir eklenti zaten yapıyor mu? (Çoğu zaman evet.)
- Eklenti yalnızca gerektiği sayfada mı yükleniyor, yoksa her yere mi giriyor?
- Son güncellemesi ne zaman ve destek forumunda performans şikâyeti var mı?
Satın Almadan Önce Bir Temayı Nasıl Test Edersin#
Tema seçimi geri dönüşü pahalı bir karar olduğu için satın almadan önce test etmek her zaman kârlıdır. İyi haber şu: temaların hemen hepsinin canlı demo sayfası vardır ve bu demo, gerçek performans hakkında dürüst bir sinyal verir. Kötü haber şu: demo genellikle güçlü bir sunucuda ve tam önbellekli çalışır, yani gördüğün TTFB gerçeği yansıtmaz. O yüzden demoda sunucudan bağımsız metriklere bak.
Bir demo sayfasında ölçmen gereken üç şey var: toplam istek sayısı, sıkıştırılmamış JavaScript boyutu ve DOM düğüm sayısı. Bunlar sunucudan bağımsızdır; temanın kendi mimarisini gösterir. Komut satırından hızlı bir ön eleme yapabilirsin:
# Demo sayfasının HTML'ini indir ve varlık sayısını çıkar
curl -s https://demo.tema-ornegi.example/ -o /tmp/demo.html
echo "CSS dosyası: $(grep -o 'rel="stylesheet"' /tmp/demo.html | wc -l)"
echo "JS dosyası: $(grep -oE 'script[^ ]* src=' /tmp/demo.html | wc -l)"
echo "HTML boyutu: $(wc -c < /tmp/demo.html) bayt"
# Sayfadaki benzersiz dış alan adları (üçüncü taraf yükü)
grep -oE 'https?://[a-zA-Z0-9.-]+' /tmp/demo.html | sort -u | head -20
Bu basit dökümde 30'un üzerinde CSS ve JavaScript dosyası görüyorsan tema büyük ihtimalle şişkindir. Dış alan adları listesinde beş altı farklı kaynak varsa, temanın kendisi bile üçüncü taraf bağımlılığı taşıyor demektir ve bunların her biri ayrı DNS çözümlemesi ile TLS el sıkışması maliyeti getirir.
İkinci test, temayı gerçekten kurup kendi sunucunda ölçmektir. Deneme kopyasında iki ölçüm al: temayı etkinleştirmeden önce ve sonra. Aradaki fark temanın net maliyetidir. Bu ölçümü mutlaka önbellek kapalıyken yap; önbellekli ölçüm temanın sunucu tarafı maliyetini gizler.
| Kontrol | İyi tema | Riskli tema |
|---|---|---|
| Ön uç CSS + JS dosya sayısı | 10 altı | 25 üstü |
| Sıkıştırılmış JS toplamı | 100 KB altı | 400 KB üstü |
| DOM düğüm sayısı (ana sayfa) | 1200 altı | 3000 üstü |
| Sayfa başına veritabanı sorgusu | 60 altı | 200 üstü |
| Üçüncü taraf alan adı | 0-1 | 4 üstü |
Mevcut Sitede Kim Ne Kadar Yavaşlatıyor#
Zaten kurulu bir sitede suçluyu bulmanın en güvenilir yolu, tek tek devre dışı bırakıp ölçmektir. Bunu canlı sitede yapma; bir test kopyası oluştur ve orada çalış. Yöntem şu: temel ölçümü al, sonra eklentileri birer birer kapat ve her adımdan sonra aynı sayfayı aynı koşullarda tekrar ölç. Bir eklentiyi kapattığında süre belirgin biçimde düşüyorsa suçluyu bulmuşsun demektir.
Ölçümü elle yapmak yerine küçük bir betikle otomatikleştirebilirsin:
#!/bin/bash
# Aynı sayfayı 5 kez ölç, ortalama TTFB'yi yazdır
URL="https://test.firmaniz.com/"
TOPLAM=0
for i in $(seq 1 5); do
T=$(curl -s -o /dev/null -w "%{time_starttransfer}" "$URL")
TOPLAM=$(echo "$TOPLAM + $T" | bc -l)
done
echo "Ortalama TTFB: $(echo "scale=3; $TOPLAM / 5" | bc -l) sn"
Her eklenti değişikliğinden sonra bu betiği çalıştır ve sonucu bir listeye yaz. Beş ölçümün ortalamasını almak önemlidir; tek ölçüm rastgele dalgalanmalardan etkilenir ve seni yanlış yönlendirir.
WordPress kullanıyorsan işini çok kolaylaştıran bir yol daha var: geliştirme amaçlı sorgu izleme eklentileri, her isteğin hangi eklentiye ne kadar süre harcadığını ve kaç sorgu attığını doğrudan gösterir. Bu araçlar tek bir sayfa yüklemesinde suçluyu isim isim listeler ve tek tek kapatma turuna hiç gerek kalmadan sonuca ulaşırsın. Yalnızca test ortamında kullan ve canlıda kapalı tut; kendileri de bir miktar yük getirir.
Sunucu tarafında ise yavaş sorgu günlüğü aynı işi veritabanı açısından yapar:
-- Yarım saniyeden uzun süren sorguları topla
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
-- Sonra günlükte hangi tablo ve desenlerin öne çıktığına bak
-- Aynı sorgunun yüzlerce kez tekrarı = eklenti kaynaklı N+1
Sayfa Oluşturucular Meselesi#
Sayfa oluşturucular (page builder) hız tartışmasının en polemikli konusudur ve dürüst cevap "duruma bağlı"dır. Bir sayfa oluşturucunun maliyeti iki yerden gelir. Birincisi, düzeni oluşturmak için ürettiği iç içe HTML yapısıdır; aynı görsel sonucu elde etmek için el yazımı bir şablondan çok daha fazla DOM düğümü kullanır. İkincisi, kendi çalışma zamanı JavaScript ve CSS paketidir; bu paket çoğunlukla her sayfaya yüklenir.
Buna karşılık gerçek bir faydası vardır: içerik ekibinin geliştirici beklemeden sayfa üretebilmesi. Bu faydayı görmezden gelip "hiç kullanma" demek gerçekçi değildir. Yapman gereken, maliyeti kabul edilebilir sınırda tutmaktır:
- Oluşturucuyu yalnızca gerçekten görsel düzen gereken sayfalarda kullan; blog yazıları ve ürün sayfaları tema şablonuyla kalsın.
- Oluşturucunun varlık dosyalarını, kullanılmadığı sayfalarda yüklememesi için sunduğu koşullu yükleme ayarını aç (çoğu modern oluşturucuda vardır).
- Aynı sitede iki farklı sayfa oluşturucu kullanma; bu, iki ayrı çalışma zamanı paketi demektir ve en pahalı hatalardan biridir.
- Oluşturucunun kendi widget'larından, temanın zaten sunduğu bir işlevi tekrar eden ağır olanlarını kullanma.
Bir de eklenti-oluşturucu köprüsü meselesi var: "şu sayfa oluşturucu için ek widget paketi" türü eklentiler kendi başlarına ciddi yük getirir ve genellikle içindeki 60 widget'tan üçünü kullanırsın. Bunları kurmadan önce ihtiyacın olan tek widget'ı tema şablonunda çözüp çözemeyeceğine bak.
Koşullu Yükleme: Kaldırmadan Hafifletmek#
Bazı eklentileri kaldıramazsın çünkü işlevine gerçekten ihtiyacın vardır. Bu durumda ikinci en iyi çözüm, o eklentinin varlık dosyalarını yalnızca gerektiği sayfalarda yüklemektir. Örneğin iletişim formu eklentisinin CSS ve JavaScript'i yalnızca iletişim sayfasında yüklensin, kalan 499 sayfada hiç yüklenmesin.
WordPress'te bunu tema fonksiyonlarında birkaç satırla yapabilirsin:
// İletişim formu varlıklarını yalnızca iletişim sayfasında yükle
add_action('wp_enqueue_scripts', function () {
if (is_page('iletisim')) {
return; // bu sayfada kalsın
}
wp_dequeue_style('form-eklentisi-css');
wp_dequeue_script('form-eklentisi-js');
}, 100);
Buradaki 100 önceliği önemlidir; eklenti kendi dosyalarını varsayılan öncelikte eklediği için senin kaldırma kodunun sonra çalışması gerekir. Daha düşük bir öncelik verirsen kod, dosyalar henüz kuyruğa girmeden çalışır ve hiçbir etkisi olmaz. Bu, en sık yapılan uygulama hatasıdır.
Aynı mantığı sosyal paylaşım, galeri, harita ve yorum eklentileri için de kurabilirsin. Eklentileri elle yönetmek istemiyorsan, varlık yöneticisi barındıran önbellek eklentileri bu işi arayüzden yaptırır; LiteSpeed Cache bunlardan biridir ve sunucu LiteSpeed ise ayrıca sayfa önbelleğini de üstlenir.
Bir uyarı daha: dosyaları kaldırırken bağımlılıkları kırma. Bazı eklentiler kendi JavaScript'ini jQuery gibi ortak bir kütüphaneye bağımlı ilan eder. Bağımlılığı kaldırırsan başka bir şey bozulur. Değişiklikten sonra tarayıcı konsolunda JavaScript hatası olup olmadığını mutlaka kontrol et.
Sık Yapılan Hatalar#
Demo içeriğini olduğu gibi bırakmak. Tema demolarını içe aktardığında onlarca örnek sayfa, görsel ve widget birlikte gelir; çoğu kişi bunları temizlemez. Bu içerik hem veritabanını şişirir hem de bazı temalarda ön uçta gereksiz sorgu üretir.
Aynı işi yapan iki eklentiyi birlikte tutmak. İki önbellek eklentisi, iki SEO eklentisi ya da iki görsel optimizasyon eklentisi yalnızca çakışma üretir. Performans eklentilerinde bu çakışma bazen sessizdir: her ikisi de kendi başına çalışır, birbirinin çıktısını bozar ve sonuçta hiçbiri işe yaramaz.
Ölçmeden eklenti kaldırmak. "Az eklenti iyidir" varsayımıyla ön uçta hiçbir maliyeti olmayan yönetim eklentilerini kaldırıp gerçek suçluyu kaçırmak yaygındır. Önce ölç, sonra karar ver.
Önceliği yanlış vererek varlık kaldırmaya çalışmak. Yukarıda anlattığım dequeue kodunun çalışmama sebebi neredeyse her zaman budur.
Temayı doğrudan düzenlemek. Tema dosyalarını değiştirirsen ilk güncellemede tüm değişikliklerin silinir; üstelik güncellemeleri hiç yapmamayı seçersen güvenlik açığı biriktirirsin. Alt tema (child theme) kullan.
Sunucu yavaşlığını temaya yıkmak. Bazen tema iyidir, sorun paylaşımlı pakette kaynak sınırlarına takılmaktır. Nasıl ayırt edeceğini hosting seçimi site hızını nasıl etkiler yazısında anlattım.
Sıkça Sorulan Sorular#
Kaç eklenti kullanmak fazla sayılır#
Sayının kendisi bir ölçüt değildir. Ön uçta hiçbir dosya yüklemeyen, yalnızca yönetim panelinde çalışan otuz eklenti sitene neredeyse hiçbir maliyet getirmez; buna karşılık her sayfaya kendi kütüphanesini ekleyen beş eklenti siteni belirgin biçimde yavaşlatır. Doğru ölçüt, eklentilerin ön uçta ürettiği toplam istek ve sorgu sayısıdır. Bu sayıyı ölç, eklenti adedini değil.
Ücretsiz temalar ücretli temalardan daha mı yavaş#
Fiyat ile performans arasında doğrudan bir ilişki yok. Aksine, en şişkin temaların bir kısmı pazar yerlerinde satılan çok amaçlı ücretli temalardır; çünkü satış argümanı "her şeyi yapar" olduğu için her şeyi yükleyerek gelirler. Sade ve iyi yazılmış birçok ücretsiz tema, bu temaların çok üstünde performans verir. Karar verirken fiyata değil, ölçüme bak.
Eklentiyi devre dışı bırakmak yeterli mi yoksa silmeli miyim#
Devre dışı bırakmak ön uç maliyetini durdurur, o yüzden performans açısından yeterlidir. Ama silmemek iki risk taşır: güncellenmeyen bir eklenti dosyası sunucuda durduğu sürece güvenlik açığı taşıyabilir ve veritabanında bıraktığı tablolar şişkinlik yapar. Kullanmayacaksan devre dışı bırakmakla yetinme, sil ve mümkünse veritabanı artıklarını da temizle.
Sayfa oluşturucu kullanırsam sitem kesin yavaşlar mı#
Kesin değil ama bir maliyeti olduğu kesin. Bu maliyet, oluşturucuyu yalnızca gerçekten gerekli sayfalarda kullanır, koşullu varlık yükleme ayarını açar ve ikinci bir oluşturucu kurmazsan kabul edilebilir sınırda kalır. Blog yazıları ve ürün sayfaları gibi şablonla üretilebilen içerikleri oluşturucuya sokmamak, tek başına en büyük kazancı sağlar.
Hangi eklentinin siteyi yavaşlattığını nasıl bulurum#
En güvenilir yöntem, bir test kopyasında temel ölçümü aldıktan sonra eklentileri birer birer kapatıp aynı sayfayı aynı koşullarda tekrar ölçmektir; süre belirgin düştüğünde suçluyu bulmuşsundur. Daha hızlı yol ise sorgu izleme eklentileri kullanmaktır: bunlar tek bir sayfa yüklemesinde hangi eklentinin kaç sorgu attığını ve ne kadar süre harcadığını isim isim listeler.
Temayı değiştirmeden hızlandırabilir miyim#
Büyük ölçüde evet. Kullanılmayan varlık dosyalarını koşullu yüklemeyle kaldırmak, tam sayfa önbelleği kurmak, görselleri optimize etmek ve gereksiz üçüncü taraf scriptleri temizlemek çoğu şişkin temada belirgin kazanç sağlar. Ancak temanın ürettiği DOM derinliği ve sunucu tarafı sorgu yükü kalır; bir noktadan sonra tavan yaparsın ve gerçek çözüm tema değişikliğidir.
Kapanış#
Tema ve eklenti seçiminde akılda tutman gereken dört alışkanlık var. Birincisi, kararı ölçerek ver: bir temayı ya da eklentiyi kurmadan önce test kopyasında öncesi-sonrası ölçümü al. İkincisi, eklenti sayısını değil ön uç maliyetini takip et; asıl yük, her sayfaya kendi dosyalarını ekleyen eklentilerdedir. Üçüncüsü, kaldıramadığın eklentileri koşullu yüklemeyle hafiflet ve dequeue önceliğini yeterince yüksek ver. Dördüncüsü, tema dosyalarını asla doğrudan düzenleme; alt tema kullan ki güncellemeler seni geri almasın.
Ölçümler temanın değil altyapının yavaş olduğunu gösteriyorsa, doğru adım paket tarafında atılır. NVMe diskli ve güncel PHP sürümlü WordPress hosting paketlerimiz sunucu tarafı gecikmesini büyük ölçüde ortadan kaldırır; büyüyen bir site için kaynakların ayrıldığı VDS sunucu daha kararlı bir zemin sunar. Tema değişikliği sırasında kesinti yaşamamak için site taşıma hizmetimizden yararlanabilir, sunucu tarafı ayarlarını hiç kurcalamak istemiyorsan sunucu yönetimi ekibimize bırakabilirsin.