Sayfa hızı, ziyaretçinin siteyi ne kadar sürede kullanılabilir gördüğüdür ve hem Google sıralaması hem dönüşüm için ölçülebilir etkisi vardır. Hızlandırma işinde en sık hata, rastgele eklenti kurup puan kovalamaktır. Doğru yöntem: gerçek kullanıcı verisiyle ölçmek, darboğazın sunucuda mı, görsellerde mi, JavaScript'te mi olduğunu bulmak ve etkisi en büyük adımdan başlamak. Bu rehber öncelik sıralı 12 adım ve ölçüm yöntemi sunar.
Sayfa hızı neden önemli?
Üç sebep. Birincisi kullanıcı: mobilde 3 saniyeden uzun süren yüklemede ziyaretçilerin önemli bir kısmı sayfayı terk eder; her saniye gecikme dönüşümü düşürür. İkincisi Google: Core Web Vitals 2021'den beri sıralama sinyali; etkisi küçük ama eşit içerikte eşitliği bozar. Üçüncüsü tarama: yavaş sunucu, Googlebot'un aynı sürede daha az sayfa taraması demektir; büyük sitelerde indekslenme hızını etkiler.
Hız bir puan değil, deneyimdir. 95 puanlı ama ana görseli 4 saniyede gelen sayfa, 80 puanlı ama 1,5 saniyede okunabilir hale gelen sayfadan kötüdür. Bu yüzden hedef puan değil metriktir: mobilde LCP 2,5 saniye altı.
Önce ölçün: hangi araç, hangi veri?
| Araç | Veri türü | Ne için? |
|---|---|---|
| Search Console, Önemli Web Verileri | Gerçek kullanıcı (alan) | Hangi sayfa grupları sorunlu; sıralama için geçerli veri |
| PageSpeed Insights | Alan (üstte) + laboratuvar (altta) | Tek sayfa teşhis ve öneriler |
| Chrome DevTools, Lighthouse ve Performance | Laboratuvar | Ayrıntılı zaman çizelgesi, uzun görevler, hangi dosya ne zaman yükleniyor |
| WebPageTest | Laboratuvar, farklı konum ve cihaz | Film şeridi, waterfall, tekrar test |
| Chrome UX Report (CrUX) Dashboard | Gerçek kullanıcı, aylık | Trend takibi |
Yöntem: Search Console'da sorunlu sayfa grubunu bulun, o gruptan bir sayfayı PageSpeed Insights'ta mobil modda test edin, "Fırsatlar" ve "Teşhis" bölümlerinden en büyük kazancı veren maddeyi alın. Her düzeltmeden sonra aynı sayfayı yeniden ölçün. Alan verisi 28 gün sonra güncellenir; sabırlı olun.
Darboğazı bulmak: sunucu mu, görsel mi, JavaScript mi?
PageSpeed Insights'ta üç sayıya bakın:
- TTFB (sunucu yanıt süresi) 600 ms üstü: Sorun sunucuda. Hosting, önbellek, veritabanı. Görselleri küçültmek bunu çözmez.
- LCP öğesi bir görsel ve büyük: Sorun görselde. Boyut, format, öncelik.
- TBT (toplam engelleme süresi) 300 ms üstü, çok sayıda JS dosyası: Sorun JavaScript'te. Üçüncü taraf betikler, ağır tema, kullanılmayan kod.
Çoğu sitede üçü birden vardır ama biri baskındır. Baskın olanı önce çözün; diğerleri onun arkasında ikinci dalga.
Sayfa hızını artıran 12 adım (öncelik sırasıyla)
- Sunucu yanıt süresini düşürün. Sayfa önbelleği (tam sayfa HTML önbelleği) en büyük tek kazançtır: dinamik siteyi statik gibi sunar. Hosting yetersizse değiştirin; ucuz paylaşımlı hostingte 1 saniyelik TTFB yaygındır. PHP ve veritabanı sürümlerini güncel tutun.
- LCP öğesini önceliklendirin. Ana görsele
fetchpriority="high", lazy loading yok, mümkünse<link rel="preload">. LCP öğesi metinse fontun geç gelmesini engelleyin. - Görselleri küçültün. WebP veya AVIF; görüntülendiği boyutta çözünürlük (mobilde 400 piksellik alana 2000 piksellik görsel göndermeyin);
srcsetile cihaza göre sürüm; kalite yüzde 75-80 yeterli. Hero görseli 150 KB altı hedef. - Ekran dışı görselleri geciktirin.
loading="lazy"ekranın altındaki tüm görsellere; üstündekilere asla. - Görsel ve gömülü öğelere boyut verin.
width,heightveyaaspect-ratio; CLS'yi önler, hız algısını düzeltir. - Render engelleyen CSS'i azaltın. Kritik CSS'i satır içine alın, kalan CSS'i ertelenmiş yükleyin. Kullanılmayan CSS'i temizleyin; sayfa oluşturucular yüzlerce KB gereksiz CSS üretir.
- JavaScript'i erteleyin ve azaltın. Tüm betiklere
defer; kullanılmayan eklenti ve kütüphaneleri kaldırın (jQuery ve 5 slider kütüphanesi bir arada mı?). Her sayfada her betiği yüklemeyin; yalnızca gereken sayfada yükleyin. - Üçüncü taraf betikleri denetleyin. Sohbet widget'ı, pazarlama pikselleri, ısı haritası, A/B test, sosyal medya gömmeleri. Her biri INP'yi ve LCP'yi bozar. Gerekli olanları kullanıcı etkileşiminden sonra veya gecikmeli yükleyin; gereksizleri silin. Google Tag Manager'daki unutulmuş etiketler sık suçludur.
- Fontları optimize edin. En fazla 2 font ailesi, 3-4 ağırlık; WOFF2;
font-display: swap; ana fontu preload; mümkünse kendi sunucunuzdan sunun (Google Fonts'a ek DNS ve bağlantı maliyeti). Sistem fontu hızın en kestirme yoludur. - Sıkıştırma ve tarayıcı önbelleği. Sunucuda Brotli veya gzip açık; statik dosyalara (CSS, JS, görsel, font) uzun
Cache-Controlsüresi. Bu ayarlar bir kez yapılır, kalıcı kazanç sağlar. - CDN kullanın. Statik dosyaları kullanıcıya yakın sunucudan sunar; Cloudflare'in ücretsiz planı çoğu site için yeterlidir ve ek olarak Brotli, HTTP/3 ve görsel optimizasyonu getirir.
- Yönlendirme zincirlerini ve gereksiz istekleri kaldırın. http → https → www zinciri her sayfada yüz milisaniyeler kaybettirir; tek adımda yönlendirin. Sayfadaki istek sayısını (DevTools Network) 50'nin altına indirmeyi hedefleyin.
İlk beş adım, çoğu sitede LCP sorununu çözer. Altı ile sekiz, INP sorununu. Dokuz ile on iki, kalan iyileştirmeler.
WordPress için hız notları
- Önbellek eklentisi: WP Rocket, LiteSpeed Cache (LiteSpeed sunucuda) veya FlyingPress. Tek bir tane; hosting önbelleğiyle çakıştırmayın.
- Görsel eklentisi: ShortPixel, Imagify veya EWWW ile WebP dönüşümü ve yüklemede sıkıştırma.
- Tema: Elementor ve Divi gibi sayfa oluşturucular ağırdır. Hafif tema (GeneratePress, Kadence, Blocksy) ve blok düzenleyici, aynı tasarımı 3-5 kat daha az kodla verir.
- Eklenti temizliği: Query Monitor ile hangi eklentinin ne kadar sorgu ve betik eklediğini görün; kullanılmayanları silin.
- Veritabanı: Yazı revizyonlarını sınırlayın, geçici verileri temizleyin (WP-Optimize).
- Heartbeat ve cron: Yönetim panelinin arka plan istekleri paylaşımlı hostingte yük yaratır; sıklığını azaltın.
WordPress'in SEO açısından diğer ayarları ayrı bir rehberde ele alınır.
Hız çalışmasında sık yapılan hatalar
- Puan kovalamak: 92'den 98'e çıkmak için üç gün harcamak. Eşikleri geçtikten sonra içeriğe dönün.
- Yalnızca masaüstünü ölçmek: Google mobil değerleri kullanır; masaüstü 95, mobil 40 yaygın bir tablodur.
- Laboratuvar ve alan verisini karıştırmak: Lighthouse 100 derken Search Console "zayıf" diyorsa gerçek kullanıcılar yavaş cihazda; alan verisi geçerlidir.
- Her şeyi geciktirmek: LCP görseline lazy loading koymak, kritik CSS'i ertelemek; hız eklentisinin "hepsini optimize et" düğmesi bunu yapar ve LCP'yi bozar.
- Sunucuyu atlamak: TTFB 1,2 saniyeyken görsel sıkıştırmakla uğraşmak.
- Tek seferlik iş sanmak: Yeni eklenti, yeni pazarlama pikseli, yeni slider; hız geri gider. Çeyrek dönemde ölçüm rutine girmeli.
- Hızın AI botlarına da yettiğini sanmak: Hızlı site, erişimi engellenmiş botu görünür kılmaz; bu ayrım başka bir yazının konusu.
Sık sorulan sorular
PageSpeed puanı kaç olmalı?
Puan değil metrikler: mobilde LCP 2,5 sn, INP 200 ms, CLS 0,1 altı. Sonrası anlamlı fark yaratmaz.
CDN gerekli mi?
Yerel kullanıcıya yakın sunucudan hizmet veren küçük site için şart değil; uluslararası kullanıcı veya yoğun trafik varsa belirgin fark yaratır.
Hız eklentisi kurdum, site bozuldu, ne yapmalıyım?
Optimizasyonları tek tek açıp her adımda test edin; sorun çıkaran dosyayı hariç tutun.
Hız çalışması ne kadar sürer?
Sunucu, önbellek ve görsel adımları bir günde yapılabilir ve en büyük kazancı verir. JavaScript sadeleştirme tema ve eklentilere bağlı olarak günler sürebilir. Yeni site yapılıyorsa hızı baştan tasarlamak, sonradan düzeltmekten her zaman ucuzdur.