Site Hızı Neden Önemli?

Site hızı sadece bir konfor meselesi değil; doğrudan gelir ve görünürlük meselesidir. Google'ın araştırmalarına göre sayfa yüklenme süresi 1 saniyeden 3 saniyeye çıktığında hemen çıkma (bounce) olasılığı yaklaşık %32 artıyor; 5 saniyeye çıktığında bu oran %90'ı aşabiliyor.

Google, 2021'den bu yana Core Web Vitals'ı sıralama sinyali olarak kullanıyor. Yani teknik olarak aynı kalitede iki içerikten hızlı açılanı arama sonuçlarında öne geçiyor. Mobil ziyaretçi oranının %60'ı aştığı bir dönemde, mobilde yavaş bir site ciddi bir dezavantaj demek.

💡 Bilgi: Core Web Vitals, alan (field) verisiyle ölçülür — yani gerçek kullanıcı deneyimiyle. Google, bu veriyi CrUX (Chrome User Experience Report) üzerinden toplar. Bir metriğin "geçer" sayılması için ziyaretçilerin %75'inin hedef eşiğin altında kalması gerekir.

Core Web Vitals: LCP, INP, CLS

Google, kullanıcı deneyimini üç ölçülebilir metrikle özetliyor:

  • LCP (Largest Contentful Paint): Görüntü alanındaki en büyük içerik ögesinin (genelde bir görsel veya başlık bloğu) ekrana çizilme süresi. Kısaca "sayfa ne kadar hızlı dolu görünüyor?" sorusunun cevabı.
  • INP (Interaction to Next Paint): 2024 Mart'ta FID'nin yerini aldı. Kullanıcının tıklama/dokunma gibi bir etkileşiminden sonra sayfanın görsel olarak yanıt vermesine kadar geçen süre. Kısaca "site tıklayınca ne kadar hızlı tepki veriyor?"
  • CLS (Cumulative Layout Shift): Sayfa yüklenirken ögelerin beklenmedik şekilde kayması. Yazı okurken reklamın araya girip metni aşağı itmesi klasik örnektir. Görsel kararlılığı ölçer.

Bu üç metrik birbirini tamamlar: LCP hızı, INP tepkiselliği, CLS kararlılığı ölçer. Hepsinin "iyi" bölgede olması hedeftir.

Metrik Hedef Tablosu

Aşağıdaki tablo, Google'ın 2026 itibarıyla geçerli olan resmi eşik değerlerini gösterir. "İyi" sütunundaki değerleri hedefleyin:

Metrik Ölçtüğü Şey ✅ İyi ⚠️ Geliştirilmeli ❌ Kötü
LCP Yükleme hızı ≤ 2,5 sn 2,5 – 4 sn > 4 sn
INP Tepkisellik ≤ 200 ms 200 – 500 ms > 500 ms
CLS Görsel kararlılık ≤ 0,1 0,1 – 0,25 > 0,25

Kendi sitenizi ölçmek için PageSpeed Insights (hem lab hem alan verisi verir), Chrome DevTools içindeki Lighthouse ve Google Search Console'daki "Core Web Vitals" raporunu birlikte kullanın.

LCP'yi İyileştirme

LCP genellikle sitenin en yavaş metriğidir çünkü sunucu yanıt süresi, görsel boyutu ve render engelleyen kaynakların hepsinden etkilenir. Öncelik sırasına göre yapılacaklar:

  1. Sunucu yanıt süresini (TTFB) düşürün: TTFB 200 ms'nin altında olmalı. Yavaş TTFB'nin çözümü genelde daha iyi hosting ve önbellektir (aşağıda ayrıntılı).
  2. LCP görselini önceden yükleyin: Kapak/hero görselini tarayıcıya erkenden bildirin.
  3. Render engelleyen CSS/JS'i azaltın: Kritik CSS'i satır içi (inline) yapın, geri kalanı ertelemeli yükleyin.
  4. Görselleri boyutlandırın: 3000px genişliğinde bir görseli 800px'lik alanda göstermeyin.

Hero görselini önceden yüklemek için sayfa <head> bölümüne şu satırı ekleyin:

<link rel="preload" as="image"
      href="/img/hero.webp"
      fetchpriority="high">

<!-- Ayrıca img etiketinde de belirtin -->
<img src="/img/hero.webp" width="1200" height="630"
     fetchpriority="high" alt="Kapak görseli">

Bu iki değişiklik, hero görselinin baskın olduğu sitelerde LCP'yi genellikle 0,5–1 saniye kısaltır.

INP'yi İyileştirme

INP, ağır JavaScript çalıştıran sitelerin en zayıf noktasıdır. Sorunun kaynağı neredeyse her zaman ana iş parçacığını (main thread) kilitleyen uzun görevlerdir. Çözümler:

  • Uzun görevleri parçalayın: 50 ms'den uzun süren JavaScript görevlerini küçük parçalara bölün, aralarına setTimeout veya scheduler.yield() ekleyin.
  • Kullanılmayan JavaScript'i kaldırın: Üçüncü taraf scriptler (canlı destek, analitik, reklam) INP'nin en büyük düşmanıdır. Gerçekten gerekli olanları tutun.
  • Scriptleri ertelemeli yükleyin: Kritik olmayan scriptlere defer veya async ekleyin.
  • Etkileşimde anında geri bildirim verin: Ağır işlem başlamadan önce butonu "yükleniyor" durumuna geçirin ki kullanıcı tepki hissetsin.
<!-- Kritik olmayan scriptleri ertele -->
<script src="/js/analytics.js" defer></script>
<script src="/js/chat-widget.js" defer></script>

<!-- Ağır görevi bölerek ana iş parçacığını serbest bırak -->
<script>
async function agirIslem(veri) {
  for (const parca of veri) {
    isle(parca);
    await new Promise(r => setTimeout(r, 0)); // tarayıcıya nefes aldır
  }
}
</script>

CLS'yi İyileştirme

CLS'nin nedeni neredeyse her zaman boyutu belirtilmemiş ögelerdir. Sayfa yüklenirken tarayıcı, görselin veya reklamın ne kadar yer kaplayacağını bilmediği için layout'u sonradan kaydırır. Çözümler:

  • Görsellere width ve height verin: Tüm <img> ve <video> etiketlerine boyut ekleyin. Tarayıcı böylece yeri baştan ayırır.
  • Reklam/embed alanlarına yer ayırın: Reklamın geleceği kutuya sabit bir min-height verin.
  • Fontları doğru yükleyin: font-display: swap kullanın ve kritik fontları önceden yükleyin ki "yazının zıplaması" olmasın.
  • Yeni içeriği mevcut içeriğin üstüne enjekte etmeyin: Bildirim çubuğu vb. ögeleri sonradan tepeye eklemeyin.
⚠️ Sık yapılan hata: CSS'te img { max-width: 100%; height: auto; } tanımlarken HTML'de width/height özniteliklerini kaldırmak. Bunları HTML'de tutun — modern tarayıcılar en-boy oranını bu değerlerden hesaplayıp yer ayırır ve CLS'yi engeller.

Görsel Optimizasyonu (WebP)

Görseller, ortalama bir web sayfasının toplam ağırlığının %50'sinden fazlasını oluşturur. En büyük hız kazancı da buradadır. Modern format WebP, aynı görsel kalitesinde JPEG'e göre %25–35, PNG'ye göre %50'ye varan tasarruf sağlar. Daha yeni AVIF formatı daha da iyidir ancak destek biraz daha dardır.

Var olan görselleri komut satırından WebP'ye dönüştürmek için:

# Google'ın cwebp aracıyla tek dosya (kalite 80 iyi bir denge)
cwebp -q 80 kapak.jpg -o kapak.webp

# Bir klasördeki tüm JPG'leri toplu dönüştür (Linux/macOS)
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

# ImageMagick ile alternatif
magick kapak.jpg -quality 80 kapak.webp

Tarayıcı desteği olmayan eski istemciler için <picture> etiketiyle geri dönüş (fallback) sunun:

<picture>
  <source srcset="/img/kapak.avif" type="image/avif">
  <source srcset="/img/kapak.webp" type="image/webp">
  <img src="/img/kapak.jpg" width="1200" height="630"
       loading="lazy" alt="Ürün kapağı">
</picture>

Ayrıca ekranın altındaki (viewport dışı) görsellere loading="lazy" ekleyerek yalnızca ihtiyaç anında yüklenmelerini sağlayın. WordPress kullanıyorsanız EWWW, ShortPixel veya Imagify gibi eklentiler bu dönüşümü otomatik yapar.

✅ Öneri: Bir e-ticaret ürün sayfasında 12 adet 400 KB'lık JPEG'i 120 KB'lık WebP'ye çevirmek toplam sayfa ağırlığını yaklaşık 3,4 MB'tan 1,4 MB'a indirir — bu tek başına LCP'yi 3G/yavaş mobil bağlantılarda saniyeler mertebesinde iyileştirir.

Önbellek (Cache) Yapılandırması

Önbellek, aynı işi tekrar tekrar yapmayı engelleyerek hem sunucuyu rahatlatır hem de ziyaretçiye içeriği anında sunar. Üç katmanda düşünün:

  1. Tarayıcı önbelleği: CSS, JS ve görsel gibi değişmeyen dosyaların ziyaretçinin tarayıcısında saklanmasını sağlar. İkinci ziyarette bu dosyalar hiç indirilmez.
  2. Sunucu / sayfa önbelleği: WordPress gibi dinamik sistemlerde her istekte PHP+veritabanı çalışmasını engeller. LiteSpeed Cache, WP Rocket, W3 Total Cache popüler çözümlerdir.
  3. CDN önbelleği: İçeriği ziyaretçiye coğrafi olarak yakın sunuculardan sunar. Cloudflare gibi bir CDN hem hız hem güvenlik sağlar.

Apache sunucularda tarayıcı önbelleğini .htaccess ile ayarlamak için:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType text/css   "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

# Metinsel dosyaları sıkıştır (Gzip)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>

Mümkünse Gzip yerine Brotli sıkıştırmasını tercih edin; metin dosyalarında %15–25 daha iyi sıkıştırma sağlar. Çoğu modern hosting ve CDN Brotli'yi otomatik destekler.

Hostingin Hıza Etkisi

Yukarıdaki tüm optimizasyonları yapsanız bile, altyapı yavaşsa tavana çarparsınız. Hostingin hıza etkisi üç noktada belirleyicidir:

  • Sunucu kaynağı ve komşuluk: Ucuz shared hosting'te aynı sunucuda yüzlerce site olur; yoğun bir "komşu" TTFB'nizi yükseltir. Yükü artan siteler için VPS'e geçiş belirgin fark yaratır.
  • Disk ve web sunucusu tipi: NVMe SSD + LiteSpeed/Nginx kombinasyonu, klasik SATA disk + Apache'ye göre kat kat hızlıdır.
  • Veri merkezi konumu: Türkiye'deki ziyaretçilere hizmet veriyorsanız, Türkiye veya yakın Avrupa lokasyonlu bir sunucu, ABD lokasyonuna göre gecikmeyi (latency) onlarca milisaniye azaltır.

Türkiye pazarında kaliteli shared hosting aylık ~₺100-250 bandında, giriş seviyesi bir VPS ise aylık ~₺200-400 bandında başlar. Hız odaklıysanız NVMe ve LiteSpeed sunan planları özellikle arayın.

Doğru altyapıyı seçmek için karşılaştırma araçlarımızı kullanabilirsiniz: paylaşımlı planlar için hosting karşılaştırma, daha fazla kaynak gerekiyorsa VPS karşılaştırma ve yüksek performans için VDS karşılaştırma sayfalarına göz atın. Sunucu konumunun gecikmeye etkisini merak ediyorsanız sunucu durum sayfamız da yol gösterir.

💡 İpucu: WordPress kullanıyorsanız cPanel üzerinden temel ayarları nasıl yapacağınızı cPanel rehberimizde bulabilirsiniz. Doğru hosting + önbellek + WebP üçlüsü çoğu siteyi "iyi" Core Web Vitals bölgesine taşımaya yeter.

Sıkça Sorulan Sorular

Core Web Vitals'ı ölçmek için hangi araçları kullanmalıyım?

Google PageSpeed Insights (hem laboratuvar hem gerçek kullanıcı verisi verir), Chrome DevTools içindeki Lighthouse ve Google Search Console'daki "Core Web Vitals" raporunu birlikte kullanın. Search Console gerçek ziyaretçi verisine dayandığı için sıralama açısından en değerli olanıdır.

WebP mı AVIF mi kullanmalıyım?

WebP, tarayıcı desteği neredeyse evrensel olduğu için güvenli varsayılan seçimdir. AVIF daha küçük dosya boyutu sunar ancak dönüştürme daha yavaştır ve çok eski tarayıcılarda desteklenmez. En iyisi <picture> etiketiyle önce AVIF, sonra WebP, en son JPEG geri dönüşü sunmaktır.

INP neden FID'nin yerini aldı?

FID yalnızca sayfadaki ilk etkileşimin gecikmesini ve sadece giriş gecikmesini ölçüyordu. INP ise sayfa ömrü boyunca tüm etkileşimleri ve işlemenin sonucunun ekrana çizilmesine kadar geçen süreyi dikkate alır. Bu, gerçek tepkiselliği çok daha doğru yansıtır. INP Mart 2024'te resmi metrik oldu.

Hosting değiştirmeden site hızını artırabilir miyim?

Evet, büyük ölçüde. Görselleri WebP'ye çevirmek, önbellek eklentisi kurmak, CDN kullanmak ve gereksiz JavaScript'i temizlemek çoğu sitede belirgin iyileşme sağlar. Ancak TTFB'niz sürekli yüksekse (200 ms üstü) ve sunucunuz yoğunsa, bir noktadan sonra daha güçlü bir plana geçmek kaçınılmaz olur.

Lazy loading her görsele uygulanmalı mı?

Hayır. Ekranın ilk açılışında görünen (viewport içindeki) görsellere, özellikle LCP görseline lazy loading uygulamayın — bu LCP'yi kötüleştirir. Lazy loading yalnızca aşağı kaydırınca görünen, viewport dışı görseller için kullanılmalıdır.