Önce ölç — tahminle uğraşma
Optimizasyona başlamadan mevcut durumu ölç ki neyin işe yaradığını görebilesin. İki araç yeterli. PageSpeed Insights (pagespeed.web.dev) mobil ve masaüstü skorunu artı Core Web Vitals'ı gösterir — mobil skora odaklan, çünkü ziyaretçilerin çoğu telefonda. TTFB (Time To First Byte) sunucunun ilk baytı gönderme süresidir.
Sağlıklı hedefler: LCP 2,5 saniyenin, TTFB yaklaşık 200 ms'nin, INP 200 ms'nin altında ve CLS 0,1'in altında. Yüksek TTFB sorunun sunucu, hosting, PHP veya veritabanında olduğunu gösterir. Düşük TTFB ama yüksek LCP ise sorun görsel ve teslimat tarafındadır. Ölçüm sana aşağıdaki hangi bölüme öncelik vereceğini söyler.
WordPress tarafı — kendi elinle yapılacaklar
Bir CDN şişkin bir WordPress kurulumunu kurtaramaz; önce kendi evini topla. PHP sürümünü 8.1 veya üstüne yükselt — 7.x'e göre belirgin şekilde hızlıdır. Kullanmadığın eklentileri sil (devre dışı bırakmak yetmez); her aktif eklenti script ve veritabanı sorgusu ekler, 'belki lazım olur' eklentileri en büyük yavaşlatıcıdır. Sayfa başına onlarca CSS/JS yükleyen ağır page builder ve temaları sorgula — hafif, blok tabanlı bir tema çoğu zaman daha hızlıdır.
Veritabanını temizle: eski revizyonlar, spam yorumlar ve birikmiş geçici (transient) kayıtları sil, sonra tabloları optimize et. Chat widget'ları, ısı haritaları, gereksiz yazı tipleri ve takip pikselleri gibi harici script'leri azalt; her biri ek istek ve gecikmedir. WooCommerce, üyelik veya forum gibi çok sorgulu sitelerde Redis object cache tekrarlayan veritabanı sorgularını belleğe alır ve TTFB'yi ciddi düşürür — paylaşımlı hostinglerde çoğu zaman yoktur, ayrı bir Redis servisi gerekir.
Önbellek — en yüksek getirili adım
WordPress her ziyarette sayfayı PHP ve veritabanıyla sıfırdan üretir. Page cache, üretilen HTML'i saklayıp sonraki ziyaretçiye hazır servis eder; sunucu yükü ve TTFB anında düşer. WP Super Cache, W3 Total Cache veya LiteSpeed Cache gibi bir page cache eklentisi kur (ya da hostingin yerleşik önbelleğini aç), GZIP/Brotli sıkıştırmayı aç ve tarayıcı önbelleği başlıklarını ayarla ki tekrar eden ziyaretçiler statik dosyaları yeniden indirmesin.
Page cache siteni tek sunucuda hızlandırır; edge cache ise dünyanın her yerinde. cdn.com.tr statik dosyalarını ziyaretçiye en yakın edge sunucudan Brotli ve HTTP/2 ile servis eder — İstanbul'daki de Almanya'daki ziyaretçi de hızlı açar. İkisi birlikte çalışır: WordPress page cache artı cdn.com.tr edge cache.
Görseller — sayfanın en büyük yükü
Bir sayfanın ağırlığının çoğu görsellerdir; burada kazanılacak çok var. Görselleri gösterildikleri boyutta yükle — 4000px'lik bir fotoğrafı 800px'lik alanda göstermek saf israftır. Lazy-load kullan (WordPress bunu yerleşik yapar) ki ekranda görünene kadar görsel yüklenmesin. Sonra next-gen formatlara geç: WebP ve destekleniyorsa AVIF, aynı kalitede JPEG/PNG'ye göre %25–50 daha küçüktür ve PageSpeed'in 'Serve images in next-gen formats' uyarısını bitirir.
Elle dönüştürmekle uğraşmak yerine ücretsiz CDNTR eklentisi bunu otomatik yapar: görsellerini kendi sunucunda WebP (destekliyse AVIF) formatına çevirir, CDN üzerinden bir picture öğesiyle servis eder ve eski tarayıcılara orijinali gösterir. Dönüştürülmüş dosya yalnızca gerçekten daha küçükse kullanılır, yani iyi sıkıştırılmış bir fotoğraf asla büyütülmez; medya kütüphanenin tamamını da toplu dönüştürebilir.
Teslimat — neden CDN şart
WordPress tarafını mükemmel yapsan bile hâlâ tek bir sunucun var: uzaktaki ziyaretçi bekler, ani trafikte sunucu zorlanır. CDN statik dosyalarını dünyaya yayılmış edge sunuculara kopyalar ve her ziyaretçi en yakınından servis alır — düşük gecikme, yük altında dayanıklılık ve hızla birlikte otomatik SSL, WAF ve DDoS koruması.
WordPress'e bağlamak ücretsiz CDNTR eklentisiyle dakikalar sürer. WordPress panelinde Eklenti → Yeni Ekle'ye gir, 'CDNTR' ara, kur ve etkinleştir; sonra CDNTR Ayarları'na cdn.com.tr API bilgilerini gir — CDN adresin otomatik dolar. O andan itibaren CSS, JavaScript ve görsellerin temaya dokunmadan CDN'den servis edilir. Eklenti ayrıca tek tık ve otomatik purge sağlar (güncellenen içerik anında yayına girer) ve purge sonrası sayfalarını önden ısıtan cache warm-up ile ilk ziyaretçi soğuk sayfa beklemez.
Platformun halletmesini istersen
Önbellek, CDN, görsel ve SSL'i tek tek kendin kurabilir ya da altyapıyı cdn.com.tr'ye devredebilirsin. Çok trafikli veya WooCommerce siteler için cdn.com.tr ayrıca yönetilen WordPress hosting, object cache için yönetilen Redis ve medya offload için S3-uyumlu object storage sunar — yani 'WordPress tarafı' işlerin bir kısmı da bize geçer. Sertifikalar kendini yeniler, ani trafik edge'de karşılanır ve sen altyapıyla değil siteyle ilgilenirsin.
Hızın en çok işe yaradığı yerler
Hızlı ürün ve ödeme sayfaları dönüşümü doğrudan artırır; önbellek ve CDN yoğun bir mağazayı yük altında akıcı tutar.
Bir yazı tuttuğunda edge cache kalabalığı tek sunucuyu boğmak yerine onlara yakın kopyalardan karşılar.
Ziyaretçilerin çoğu mobilde; hafif next-gen görseller ve önbelleklenmiş sayfalar Google'ın sıraladığı Core Web Vitals'ı iyileştirir.
WordPress hız — sık sorulanlar
CDN kurunca cache eklentisine hâlâ gerek var mı?
Evet — ikisi farklı işi yapar. Page cache eklentisi WordPress'in ürettiği HTML'i sunucunda saklar; CDN o çıktıyı ve statik dosyaları ziyaretçiye yakın bir edge'den servis eder. Birlikte en iyi sonucu verir.
WebP'ye geçince görsel kalitesi bozulur mu?
Hayır. WebP ve AVIF aynı görsel kalitede daha küçük dosya üretir. CDNTR yalnızca dönüştürülmüş dosya gerçekten daha küçükse onu servis eder; değilse orijinali bırakır.
WooCommerce mağazam var, dinamik sayfalar bozulur mu?
Bozulmaz. Yalnızca statik dosyalar (CSS, JS, görsel) CDN'den servis edilir; sepet, ödeme ve hesap sayfaları normal çalışır ve otomatik purge kategori ile mağaza sayfalarını taze tutar.
Sunucum yavaş — CDN yeterli mi?
CDN statik teslimatı hızlandırır ama yüksek TTFB'nin kaynağı hosting, PHP veya veritabanıysa önce onu çözmen gerekir (WordPress tarafı ve önbellek adımlarına bak). Çok yavaş bir sunucu için yönetilen WordPress'e geçmek en kalıcı çözümdür.