Google, 2020'de web performansını ölçmek için üç temel metrik belirledi: LCP, FID ve CLS. 2021'den itibaren resmi sıralama faktörü.
Yıllardır "hızlı site" diyorduk ama somut eşik yoktu. 2.5 saniye mi, 5 saniye mi? Core Web Vitals bu belirsizliği bitirdi. Artık Google'ın neyi iyi saydığını biliyoruz: sayılar var.
Core Web Vitals tam olarak ne ölçüyor?
Üç farklı kullanıcı deneyimi boyutu: yükleme hızı, etkileşim gecikmesi, görsel kararlılık.
LCP (Largest Contentful Paint) sayfadaki en büyük içerik öğesinin ne zaman görünür hale geldiğini ölçüyor. Genellikle hero görseli, ürün fotoğrafı veya büyük metin bloğu. Kullanıcı scroll yapmadan önce ne görüyor? LCP bunu yakalıyor.
FID (First Input Delay) kullanıcı bir butona tıkladığında tarayıcının ne kadar sürede yanıt verdiğini ölçüyor. JavaScript yoğun sitelerde sorunlu. Ana thread bloke olmuşsa kullanıcı tıklıyor, hiçbir şey olmuyor, 300 milisaniye sonra tepki geliyor. Kullanıcı o sırada başka yere tıklamış olabilir.
CLS (Cumulative Layout Shift) sayfa yüklenirken içeriğin kaydığını tespit ediyor. Reklam geç yükleniyor, metin aşağı kayıyor, kullanıcı yanlış butona basıyor. Mobil e-ticaret sitelerinde klasik: "Satın Al" butonuna basacaksınız, o sırada üstte bir banner açılıyor, "İptal Et"e basıyorsunuz.
Eşikler nasıl belirleniyor?
Google üç seviye tanımlamış: iyi, iyileştirme gerekli, kötü. Eşikler gerçek kullanıcı verilerine dayanıyor.
LCP: 2.5 saniye altı iyi, 2.5-4 saniye arası iyileştirme gerekli, 4 saniye üstü kötü. Sayfanın en büyük içeriği 2.5 saniye içinde görünmeli.
FID: 100 milisaniye altı iyi, 100-300 milisaniye arası iyileştirme gerekli, 300 milisaniye üstü kötü. Kullanıcı tıkladığında tarayıcı 100 milisaniye içinde yanıt vermeli. İnsanlar etkileşimde sabırsız; 300 milisaniye bile uzun geliyor.
CLS: 0.1 altı iyi, 0.1-0.25 arası iyileştirme gerekli, 0.25 üstü kötü. Sayı soyut çünkü piksel veya saniye değil. Görsel kayma miktarı × etkilenen alan = CLS skoru.
Neden bu metrikler seçildi?
Google yüzlerce performans metriği arasından bunları seçti çünkü kullanıcının gerçekten hissettiği şeyleri ölçüyorlar.
TTFB (Time to First Byte) sunucu yanıt süresini ölçüyor. Kullanıcı bunu doğrudan hissetmiyor. Sayfa boş görünse bile arka planda veri gelmeye başlamış olabilir. LCP ise kullanıcının gerçekten bir şey gördüğü anı yakalıyor. Sayfa beyaz ekrandan çıkıp içerik gösterdiğinde LCP tamamlanıyor.
Toplam sayfa boyutu da önemli ama tek başına yeterli değil. 5 MB'lık bir sayfa iyi optimize edilmişse 2 MB'lık kötü optimize edilmiş sayfadan daha hızlı yüklenebilir. Görseller lazy load ediliyorsa, JavaScript code splitting yapılmışsa, kritik CSS inline ise 5 MB sorun olmayabilir. Core Web Vitals sonuca bakıyor, sürece değil.
LCP detayları
LCP sayfadaki en büyük görünür öğeyi tespit ediyor. Genellikle hero görseli, ürün fotoğrafı, blog yazısının öne çıkan görseli. Bazen büyük metin bloğu da olabiliyor.
Önemli nokta: LCP viewport içindeki en büyük öğeyi ölçüyor. Sayfanın aşağısında daha büyük görsel olsa bile ekranda görünmüyorsa LCP'ye dahil edilmiyor. Kullanıcı scroll yapmadan önce ne gördüğü önemli.
LCP dinamik. Sayfa yüklenirken önce metin bloğu en büyük öğe olabilir, sonra görsel yüklenince o en büyük öğe haline gelebilir. LCP son değişikliği kaydediyor. Görseller geç yükleniyorsa LCP sürekli değişiyor, bu kötü.
Yaygın LCP sorunları: büyük görseller optimize edilmemiş (2 MB PNG yerine 200 KB WebP kullanılmalı), sunucu yanıt süresi yavaş (TTFB 600 milisaniye üstü), render-blocking CSS ve JavaScript var (kritik CSS inline olmalı, JavaScript defer/async ile yüklenmeli), lazy loading yanlış uygulanmış. Hero görseline lazy loading uygulamak klasik hata; görsel geç yükleniyor, LCP kötüleşiyor. Hero görseli her zaman eager loading olmalı.
FID ve INP farkı
FID 2024'te yavaş yavaş INP (Interaction to Next Paint) ile değiştirilmeye başlandı. İkisi de etkileşim gecikmesini ölçüyor, farklı şekillerde.
FID sadece ilk etkileşimi ölçüyor. Kullanıcı sayfaya geldiğinde ilk tıklama veya tuş basışında ne kadar gecikme oluyor? Önemli ama eksik. Kullanıcı sayfada 5 dakika geçiriyorsa ilk etkileşim yeterli değil. İkinci, üçüncü, onuncu tıklamada ne oluyor?
INP tüm etkileşimleri ölçüyor, en kötü %25'lik dilimi raporluyor. Kullanıcı 100 kez tıkladıysa en yavaş 25 etkileşimin ortalamasını alıyor. Daha gerçekçi çünkü tek bir iyi etkileşim yeterli değil; tutarlı performans gerekiyor. Kullanıcı 99 kez hızlı yanıt alıp 1 kez 2 saniye beklemişse deneyim bozuluyor.
FID eşiği 100 milisaniye, INP eşiği 200 milisaniye. INP daha kapsamlı ölçtüğü için eşik biraz daha yüksek. 200 milisaniye altı iyi, 200-500 milisaniye arası iyileştirme gerekli, 500 milisaniye üstü kötü.
CLS nasıl hesaplanıyor?
CLS iki faktörü çarpıyor: impact fraction (etkilenen alan) × distance fraction (kayma mesafesi).
Impact fraction viewport'un ne kadarının etkilendiğini gösteriyor. Görsel geç yüklendiğinde altındaki metin aşağı kayıyor. Hem görselin hem metnin kapladığı alan impact fraction'a dahil. Viewport'un %50'si etkilendiyse impact fraction 0.5.
Distance fraction içeriğin ne kadar kaydığını ölçüyor. Metin 100 piksel aşağı kaydıysa, viewport yüksekliği 1000 piksel ise distance fraction 0.1.
Formül: 0.5 × 0.1 = 0.05. Bu tek bir layout shift skoru. Sayfa yüklenirken birden fazla kayma olabilir; hepsi toplanıyor, toplam CLS skoru çıkıyor.
Yaygın CLS sorunları: görsellere width ve height verilmemiş (tarayıcı yer ayıramıyor, görsel yüklenince layout kayıyor), reklamlar ve embed'ler dinamik boyutlu (300x250 reklam yeri ayrılmış, 300x600 reklam geliyor), fontlar geç yükleniyor ve FOIT (Flash of Invisible Text) oluşuyor (font yüklenene kadar metin görünmüyor, sonra aniden beliriyor ve layout kayıyor), içerik dinamik ekleniyor ama yer ayrılmamış (AJAX ile yorum yükleniyor, üstteki içerik aşağı kayıyor).
Hangi sayfa tipleri daha hassas?
E-ticaret ürün sayfaları LCP açısından kritik. Ürün görseli genellikle en büyük öğe, kullanıcı bunu hemen görmek istiyor. Görsel optimize edilmemişse veya CDN kullanılmıyorsa LCP kötüleşiyor. 2 MB PNG yerine 200 KB WebP kullanın, Resim Sıkıştırma aracımız ile görselleri optimize edin.
Blog yazıları ve haber siteleri CLS açısından sorunlu. Reklamlar geç yükleniyor, içerik kayıyor. Mobilde daha belirgin çünkü ekran dar, kayma daha fark ediliyor. Reklam alanlarına sabit height verin.
SaaS uygulamaları ve dashboard'lar FID/INP açısından hassas. Çok fazla JavaScript var, kullanıcı sürekli etkileşimde bulunuyor. Butona tıkladığında 500 milisaniye gecikme olursa deneyim bozuluyor. Code splitting yapın, sadece gerekli JavaScript'i yükleyin.
Landing page'ler genellikle daha iyi performans gösteriyor: az içerik, az JavaScript, optimize edilmiş görseller. Ama form gönderimi sırasında FID/INP sorunu çıkabiliyor. Form validation JavaScript'i ana thread'i bloke ediyorsa kullanıcı "Gönder" butonuna basıyor, hiçbir şey olmuyor, 2 saniye sonra form gönderiliyor.
Mobil ve masaüstü farkları
Google mobil ve masaüstü için ayrı Core Web Vitals skorları tutuyor. Mobil genellikle daha kötü: cihazlar daha zayıf, ağ bağlantısı daha yavaş.
LCP mobilde 2-3 kat daha uzun olabiliyor. Aynı görsel masaüstünde 1.5 saniyede yüklenirken mobilde 4 saniye sürebiliyor. Mobil optimizasyon ayrı çaba gerektiriyor; sadece responsive tasarım yeterli değil. Mobil için ayrı, daha küçük görseller kullanın. <picture> elementi ile mobilde 800px genişlikte görsel, masaüstünde 1920px genişlikte görsel yükleyin.
FID/INP mobilde daha sorunlu. Mobil cihazların işlemcileri daha zayıf, JavaScript işleme daha yavaş. Masaüstünde 50 milisaniye süren işlem mobilde 200 milisaniye sürebiliyor. Mobilde test yapmadan yayınlamayın.
CLS mobilde daha belirgin. Ekran dar, kayma daha fark ediliyor. Mobil reklamlar genellikle daha büyük, daha geç yükleniyor. 320px genişlikte ekranda 300x250 reklam neredeyse tüm viewport'u kaplıyor, geç yüklenince tüm sayfa kayıyor.
Ölçüm araçları
Google PageSpeed Insights en yaygın araç. Hem lab data (laboratuvar verisi) hem field data (gerçek kullanıcı verisi) gösteriyor. Lab data Lighthouse ile ölçülüyor, kontrollü ortamda test ediliyor. Field data Chrome User Experience Report'tan geliyor, gerçek kullanıcıların deneyimini yansıtıyor.
Google Search Console'daki Core Web Vitals raporu gerçek kullanıcı verilerini gösteriyor. Hangi sayfaların iyi, hangi sayfaların kötü olduğunu URL bazında listeliyor. PageSpeed Insights'tan daha güvenilir çünkü gerçek ziyaretçilerin deneyimini yansıtıyor. PageSpeed Insights tek bir test, Search Console 28 günlük gerçek veri.
Chrome DevTools'daki Performance sekmesi detaylı analiz sunuyor. Hangi kaynağın ne zaman yüklendiğini, hangi JavaScript'in ana thread'i bloke ettiğini görebilirsiniz. CLS için Layout Shift bölümü hangi öğelerin kaydığını gösteriyor. Geliştirme aşamasında kullanışlı.
Web Vitals Chrome eklentisi gerçek zamanlı ölçüm yapıyor. Herhangi bir sayfayı ziyaret ettiğinizde LCP, FID ve CLS değerlerini gösteriyor. Kendi sitenizi test ederken kullanışlı. Rakip siteleri de test edebilirsiniz.
Site Analiz aracımız ile Core Web Vitals skorlarınızı ölçebilir, AI destekli iyileştirme önerileri alabilirsiniz. Lighthouse motorunu kullanır, detaylı rapor sunar.
Yaygın optimizasyon hataları
Preload her şey için kullanılıyor. Preload önemli kaynakları önceliklendirmek için iyi ama her CSS ve JavaScript dosyasına preload eklemek ters etki üretiyor. Tarayıcı neyin gerçekten önemli olduğunu anlayamıyor, ağ yarışı büyüyor. Sadece kritik kaynakları preload edin: hero görseli, kritik CSS, ana font. Trade-off: fazla preload kullanırsanız kritik kaynaklar geç yüklenir.
Lazy loading her görsele uygulanıyor. Ekranın altındaki görseller için mantıklı ama hero görseline veya ilk ekrandaki içeriğe uygulanmamalı. LCP öğesi lazy load edilirse skor kötüleşiyor. Hero görseli her zaman loading="eager" olmalı.
JavaScript bundle'ı bölünmüyor. Tüm JavaScript tek dosyada yüklenirse ilk yükleme ağır oluyor, FID/INP kötüleşiyor. Code splitting ile sadece gerekli kod yüklenmeli. Örnek: modal JavaScript'i modal açılınca yüklensin, anasayfada yüklenmesin.
Görsellere width ve height verilmiyor. Tarayıcı görsel boyutunu bilmiyorsa yer ayıramıyor. Görsel yüklenince layout kayıyor, CLS artıyor. Her görsele width ve height vermek basit ama etkili çözüm. <img width="800" height="600"> şeklinde.
Font yükleme stratejisi yok. Fontlar geç yüklenirse FOIT (Flash of Invisible Text) veya FOUT (Flash of Unstyled Text) oluşuyor. font-display: swap kullanın, kritik fontları preload edin. Trade-off: swap kullanırsanız önce sistem fontu görünür, sonra özel font yüklenir, hafif layout kayması olabilir. Ama FOIT'ten iyidir.
Sıralama etkisi ne kadar büyük?
Core Web Vitals resmi sıralama faktörü ama ağırlığı net değil. Google "içerik kalitesi daha önemli" diyor, rakamsal oran vermiyor.
Sektör analizleri bazı ipuçları veriyor. Backlinko'nun çalışmasında ilk sayfadaki sitelerin %70'inin Core Web Vitals skorları iyi. İkinci sayfada bu oran %40'a düşüyor. Korelasyon var ama nedensellik kanıtlanmış değil. İyi skorlu siteler zaten iyi optimize edilmiş, profesyonel ekipleri var, içerik kalitesi de yüksek olabilir.
Google'ın "page experience update" açıklaması: iki sayfa içerik kalitesi açısından eşitse Core Web Vitals iyi olan üst sırada çıkacak. Tie-breaker görevi görüyor. İçerik kalitesi, backlink profili, kullanıcı sinyalleri daha ağır basıyor. Yani kötü içerikli ama hızlı site, iyi içerikli ama yavaş siteyi geçemez. Ama iki site de iyi içerikli ise hızlı olan kazanır.
Kullanıcı deneyimi dolaylı olarak sıralamayı etkiliyor. Core Web Vitals kötüyse bounce rate artıyor, dwell time azalıyor, kullanıcılar geri tuşuna basıyor. Google bu sinyalleri görüyor, sıralamayı düşürebiliyor. Yavaş site → kullanıcı hemen çıkıyor → Google "bu site kullanıcıları memnun etmiyor" diyor → sıralama düşüyor.
Sürekli izleme neden gerekli?
Core Web Vitals statik değil; zaman içinde değişiyor. Yeni özellik eklediğinizde, görselleri güncellediğinizde, üçüncü parti script yüklediğinizde skorlar bozulabiliyor.
Trafik arttığında sunucu yavaşlayabilir, LCP kötüleşebilir. Paylaşımlı hosting kullanıyorsanız yoğun saatlerde TTFB artıyor, bu LCP'yi etkiliyor. Sabah 10:00'da site hızlı, akşam 20:00'de yavaş olabilir.
Üçüncü parti scriptler güncelleniyor, performans değişiyor. Google Analytics, Facebook Pixel, reklam ağları kendi kodlarını güncelliyor. Bazen bu güncellemeler performansı olumsuz etkiliyor. Dün 50 KB olan script bugün 150 KB olabilir.
Tarayıcılar değişiyor, ölçüm yöntemleri güncelleniyor. Chrome 90'da CLS hesaplama yöntemi değişti, bazı sitelerin skorları iyileşti. Bu tür değişiklikleri takip etmek gerekiyor. Bugün iyi olan skor yarın kötü olabilir.
Skorlarınızı düzenli kontrol edin, sorunları erken tespit edin. Site Analiz aracımız ile Core Web Vitals metriklerinizi ölçebilir, AI destekli iyileştirme önerileri alabilirsiniz.