Core Web Vitals nedir? LCP, INP ve CLS rehberi
Core Web Vitals, Google’ın sayfa deneyimini ölçtüğü üç göstergedir. Tek başına ilk sıraya çıkarmazlar ama eşit güçteki iki site arasında ayırt edici olurlar.
Üç ölçüt, tek amaç
Core Web Vitals, Google’ın sayfa deneyimini ölçmek için seçtiği üç metrik. Hepsi tek bir soruyu farklı açıdan soruyor: bu sayfa kullanıcıya hızlı ve düzgün mü davranıyor?
Metrik | Ne ölçüyor | İyi | Geliştirilmeli | Kötü |
|---|---|---|---|---|
LCP | En büyük içeriğin görünme süresi | 2,5 sn altı | 2,5–4 sn | 4 sn üstü |
INP | Etkileşime cevap süresi | 200 ms altı | 200–500 ms | 500 ms üstü |
CLS | Görsel kayma miktarı | 0,1 altı | 0,1–0,25 | 0,25 üstü |
Eşik değerler 75. yüzdelik üzerinden hesaplanıyor. Yani kullanıcılarınızın dörtte üçü iyi deneyim yaşıyorsa geçer not alıyorsunuz. Ortalamaya değil dağılıma bakılıyor — bu önemli, çünkü yavaş cihazlardaki azınlık kullanıcı ortalamada kayboluyor ama 75. yüzdelikte görünüyor.
LCP — en büyük içerik boyaması
Sayfadaki en büyük görsel veya metin bloğunun ekranda belirme süresi. Kullanıcının "sayfa açıldı" hissi genelde buna denk geliyor.
Yavaşlatan başlıca sebepler:
- Sunucu cevap süresi. Her şeyin başı. Sunucu 800 ms'de cevap veriyorsa LCP'yi 2,5 sn altına indirmek çok zorlaşıyor.
- Büyük görseller. Sıkıştırılmamış veya boyutu ekrandan büyük görseller.
- Render engelleyen kaynaklar. Baştaki CSS ve senkron JavaScript.
- İstemci tarafı render. İçerik JavaScript ile geliyorsa LCP gecikiyor.
En etkili düzeltmeler sırayla: görselleri modern biçime (WebP/AVIF) çevirmek, hero görseline yükleme önceliği vermek, sunucu tarafı render kullanmak, önbellek katmanı eklemek.
INP — etkileşim sonrası boyama
2024'te FID'nin yerini aldı ve daha zorlayıcı bir ölçüt. Kullanıcı bir şeye tıkladığında ekranda değişikliğin görünmesine kadar geçen süre.
FID sadece ilk etkileşimin gecikmesini ölçüyordu. INP tüm etkileşimleri ve tamamlanma süresini ölçüyor. Bu yüzden birçok site FID'de iyiyken INP'de kötü çıktı.
INP'yi bozan şey neredeyse her zaman aynı: ana iş parçacığını uzun süre meşgul eden JavaScript. Tipik kaynaklar:
- Ağır üçüncü taraf betikleri (sohbet aracı, ısı haritası, reklam)
- Büyük React bileşen ağaçlarının yeniden render'ı
- Etkileşim anında yapılan senkron hesaplama
Çözüm yönü: gereksiz betiği kaldırmak, kalanını ertelemek, uzun işleri parçalara bölmek.
CLS — kümülatif düzen kayması
Sayfa yüklenirken içeriğin yer değiştirmesi. Bir yazıyı okurken metnin aşağı kayması veya butona basacakken başka bir şeye basmanız.
Neredeyse tamamı dört sebepten geliyor:
Sebep | Çözüm |
|---|---|
Boyutsuz görsel | width ve height özniteliği vermek |
Sonradan yüklenen yazı tipi | font-display ayarı ve ön yükleme |
Üstten giren banner veya reklam | Yerini baştan ayırmak |
Dinamik içerik enjeksiyonu | Yer tutucu koymak |
CLS düzeltmesi diğer ikisine göre çok daha kolay ve kalıcı. Genelde bir günlük iş.
Saha verisi ve laboratuvar verisi
Ölçütlerin tanımı ve eşik değerleri web.dev üzerindeki resmi belgede duruyor; kendi sayfanızı ölçmek içinse PageSpeed Insights yeterli. Aynı sayfanın iki farklı sonuç vermesi hata değil: biri gerçek kullanıcı verisi, diğeri denetimli bir test.
En sık karışan konu bu. İki farklı veri kaynağı var ve farklı şeyler söylüyorlar:
Saha verisi (CrUX). Gerçek Chrome kullanıcılarından toplanıyor, 28 günlük kayan pencere. Search Console’daki Core Web Vitals raporu ve PageSpeed Insights’ın üst kısmı bunu gösteriyor. Sıralamaya etki eden veri bu.
Laboratuvar verisi (Lighthouse). Tek bir simüle edilmiş cihazda tek seferlik ölçüm. PageSpeed Insights’ın alt kısmı ve tarayıcıdaki Lighthouse sekmesi.
Aradaki farkın pratik sonucu: Lighthouse'ta 100 puan almış olabilirsiniz ama saha verisinde kötü görünebilirsiniz. Sebebi genelde gerçek kullanıcıların daha yavaş cihaz ve bağlantı kullanması.
Ayrıca saha verisi 28 gün geriden geliyor. Bugün yaptığınız düzeltme raporda haftalar sonra görünüyor — bu, "düzelttim ama değişmedi" paniğinin en yaygın sebebi.
Sıralamaya etkisi ne kadar?
Dürüst cevap: sanıldığından az. Core Web Vitals bir sıralama sinyali ama içerik uygunluğunun yanında ağırlığı düşük. Google bunu açıkça söylüyor — eşit kalitedeki iki sayfa arasında ayrım yapıyor, kötü içeriği iyi yapmıyor.
Yine de üzerinde çalışmaya değer, çünkü:
- Dönüşüm oranını doğrudan etkiliyor. Yavaş sayfa satmıyor.
- Mobil kullanıcılarda terk oranını düşürüyor.
- Rekabetin sıkı olduğu kelimelerde ayrım noktası olabiliyor.
Yani asıl kazanç SEO’dan çok kullanıcı tarafında.
Örnek senaryo — Bir kurumsal sitede LCP 6,2 saniyeydi. Tek sebep vardı: ana sayfadaki hero görseli 2,8 MB'lık bir PNG'ydi. WebP'ye çevirip doğru boyutta sunduk, LCP 2,1 saniyeye indi. Tek dosya, yarım saatlik iş, üç metrikten biri yeşile döndü.
En sık karşılaştığımız beş sebep
Onlarca site denetledikten sonra oluşan liste. Sıralama, düzeltme başına kazanca göre:
1. Optimize edilmemiş hero görseli. Ana sayfanın üstündeki büyük görsel çoğu zaman 1–3 MB. WebP'ye çevirip doğru boyutta sunmak tek başına LCP'yi yarıya indirebiliyor. En ucuz kazanç bu.
2. Yazı tipi yükleme sırası. Google Fonts'un varsayılan yerleştirmesi hem LCP'yi geciktiriyor hem CLS üretiyor. Yazı tipini kendi sunucunuzdan servis edip ön yükleme etiketi vermek ikisini birden çözüyor.
3. Üçüncü taraf betikleri. Sohbet aracı, ısı haritası, sosyal medya gömüsü, piksel. Her biri ana iş parçacığını meşgul ediyor ve INP'yi bozuyor. Gerçekten kullanılmayanları kaldırmak, kalanları ertelemek gerekiyor.
4. Sunucu cevap süresi. Paylaşımlı barındırmada 800–1500 ms cevap süresi sık görülüyor. Bu, diğer tüm optimizasyonların üstüne binen sabit bir gecikme. Önbellek katmanı veya daha iyi barındırma tek çözüm.
5. Boyutsuz görsel ve gömü. width/height olmayan her görsel potansiyel CLS kaynağı. YouTube gömüleri ve reklam alanları da aynı sorunu yaratıyor.
Bu beşi düzeltmek çoğu sitede üç metriği de yeşile çeviriyor. Geri kalanı ince ayar.
Ölçüm araçları
Araç | Veri tipi | Ne için |
|---|---|---|
Search Console | Saha | Site geneli durum, sorunlu sayfa grupları |
PageSpeed Insights | İkisi de | Tek sayfa teşhisi |
Chrome DevTools | Laboratuvar | Geliştirme sırasında |
CrUX Dashboard | Saha | Zaman içindeki değişim |
web-vitals kütüphanesi | Saha | Kendi analitiğinize kaydetmek |
Son satır en az bilinen ama en faydalısı. Kendi kullanıcılarınızın gerçek verisini topluyorsunuz ve 28 gün beklemiyorsunuz.
Nereden başlamalı?
Sırayla:
- Search Console'da hangi sayfa gruplarının kötü olduğunu görün.
- En çok trafik alan kötü grubu seçin.
- O gruptan bir temsilci sayfayı PageSpeed Insights'ta inceleyin.
- Önce CLS'yi düzeltin — en ucuz kazanç.
- Sonra LCP'ye geçin — genelde görsel ve sunucu işi.
- INP'yi en sona bırakın — en zoru, çoğu zaman betik temizliği gerektiriyor.
Dikkat — Lighthouse'ta 100 puan almış olmak saha verisinde iyi olduğunuz anlamına gelmiyor. Lighthouse tek bir simüle cihazda ölçüyor; sıralamaya etki eden veri ise gerçek kullanıcılardan geliyor ve 28 gün geriden takip ediyor.
Ne zaman uğraşmayın?
Sitenizin hiç trafiği yoksa Core Web Vitals sizin sorununuz değil. Önce indekslenme ve içerik tarafını çözmek gerekiyor — hızlı ama görünmeyen sayfa kimseye fayda sağlamıyor.
Aynı şekilde, üç metrik de yeşilse daha da hızlandırmaya çalışmak getiri sağlamıyor. 2,4 saniyeyi 1,9'a düşürmek ölçülebilir bir kazanç getirmiyor.
Sitenizin hız tarafını bizim ele almamızı isterseniz teknik SEO hizmetimiz ölçüm, teşhis ve uygulamayı kapsıyor.
Bu konuyla ilgili
- web sitesi geliştirme — Hız, sonradan eklenen değil mimaride kurulan bir şey.
- Googlebot ne iş yapar? — Yavaş sunucunun tarama tarafındaki bedeli.
- Screaming Frog — Hız sorunlarının hangi sayfa gruplarında toplandığını bulmak.
