Detaylı tanım
Core Web Vitals, kullanıcı deneyimi sinyalleri olarak Google'ın SEO sıralamasında dikkate aldığı 3 metrik: LCP (Largest Contentful Paint — ana içeriğin yüklenme süresi, hedef <2.5s), INP (Interaction to Next Paint — kullanıcı etkileşimi sonrası ilk yanıt, hedef <200ms), CLS (Cumulative Layout Shift — beklenmeyen layout kaymaları, hedef <0.1). PageSpeed Insights ile ölçülür. Mobil ve masaüstü ayrı değerlendirilir.
Core Web Vitals nasıl çalışır?
Üç metrik iki ayrı yoldan ölçülür ve tartışmaların çoğu bu ayrımı atlamaktan çıkar. Sıralamada dikkate alınan veri saha verisidir: Chrome kullanıcılarından toplanan CrUX kayıtları, son 28 günün yuvarlanan penceresinde ve 75. yüzdelik dilimde değerlendirilir. Yani ziyaretçilerin dörtte birinin yaşadığı kötü deneyim, sayfanın karnesini belirler. Laboratuvar verisi ise tek bir simüle edilmiş yüklemedir; teşhis için değerli, karne için yetersizdir. Eşikler nettir: LCP 2,5 saniye, INP 200 milisaniye, CLS 0,1 altında iyi kabul edilir; LCP'de 4 saniye, INP'de 500 milisaniye ve CLS'te 0,25 üstü zayıf sayılır. Search Console raporu URL'leri benzer şablon gruplarına toplar, yani değerlendirme tek sayfa değil sayfa ailesi düzeyindedir.
LCP'yi tek bir sayı olarak görmek yerine dört parçaya bölmek gerekir: sunucunun ilk baytı gönderme süresi, ana görselin keşfedilmesine kadar geçen gecikme, indirme süresi ve tarayıcının ekrana çizme gecikmesi. Hangi parçanın şiştiği bilinmeden yapılan iyileştirme rastgeledir; sorun sunucu yanıtındaysa görsel sıkıştırmak hiçbir şey değiştirmez. INP ise 2024 Mart'ında FID'in yerini aldı ve ölçümü sertleştirdi. Yalnızca ilk etkileşimin bekleme süresini değil, tıklamanın ardından JavaScript'in çalışmasını ve yeni karenin çizilmesini kapsayan toplam yanıt süresini, üstelik ziyaret boyunca yaşanan en kötüye yakın etkileşimi baz alır. Uzun süren ana iş parçacığı görevleri ve üçüncü taraf script'leri buradaki tipik suçlulardır.
CLS, sayfa ömrü boyunca biriken kaymaların en yoğun beş saniyelik penceresini ölçer; her kayma, etkilenen ekran alanı ile taşınma mesafesinin çarpımıdır. Ölçüm bu yüzden açılış anıyla sınırlı değildir: aşağı kaydırdıkça yüklenen reklamlar, çerez bandı, geç gelen yazı tipi ve boyutu belirtilmemiş görseller skoru sonradan bozar. Pratikte iş yükü şuraya iner; görsel ve iframe'lere genişlik-yükseklik vermek, dinamik alanlara baştan yer ayırmak, ilk ekrandaki büyük görseli geç yüklemeye bırakmamak, kritik olmayan script'leri ertelemek. Ölçümün asıl faydası da sıralamadan önce dönüşümdür: yavaş açılan ve tıklanırken kayan bir sepet sayfası, arama motoru fark etmeden önce kullanıcıyı kaybettirir. Bu nedenle iyileştirme sırası ciro taşıyan şablonlardan başlamalıdır.
Hangi terimlerle karıştırılıyor?
| Karıştırılan terim | Aradaki fark |
|---|---|
| Lighthouse performans skoru | Simüle edilmiş tek bir yüklemeden çıkan 0-100'lük laboratuvar puanıdır. Core Web Vitals ise gerçek ziyaretçilerin 28 günlük verisinden 75. yüzdelik dilimle hesaplanır; ikisi aynı sayfa için farklı sonuç verebilir. |
| FID (First Input Delay) | İlk etkileşimin yalnızca işleme başlama gecikmesini ölçerdi ve 2024 Mart'ında INP ile değiştirildi. INP, işleme süresi ve ekrana çizilme dahil toplam yanıt süresini baz alır. |
| TTFB (Time to First Byte) | Sunucunun ilk baytı gönderme süresidir. Core Web Vitals metriği değil, LCP'nin alt bileşeni ve teşhis göstergesidir; TTFB iyileşmeden LCP hedefine ulaşmak çoğu sitede mümkün olmaz. |
| PageSpeed Insights | Bir metrik değil ölçüm aracıdır; aynı ekranda hem saha verisini hem laboratuvar teşhisini gösterir. Skorun yüksek olması Core Web Vitals eşiklerinin geçildiği anlamına gelmez. |
Sık yapılan hatalar
Lighthouse skorunu karne sanmak
PageSpeed Insights'ın 0-100 performans puanı, laboratuvar koşullarında tek bir yüklemeden üretilen ağırlıklı bir bileşimdir. Google'ın değerlendirmeye aldığı veri ise gerçek kullanıcılardan gelen saha verisidir. Puan yüksekken saha verisinde LCP'nin zayıf çıkması sık görülür; karar verirken raporun saha bölümüne bakılmalıdır.
Yalnızca ana sayfayı optimize etmek
Rapor URL'leri benzer şablon gruplarına toplar ve ciroyu ürün, kategori, blog şablonları taşır. Ana sayfa yeşile döndüğünde iş bitmez; her şablondan örnek URL seçilip ayrı ölçülmeli, düzeltme şablon düzeyinde yapılmalıdır. Aksi halde ziyaretlerin çoğu hâlâ zayıf tarafta kalır.
İlk ekrandaki büyük görseli geç yüklemeye bırakmak
Sayfanın üst kısmındaki kapak görseline lazy loading uygulamak, tam da LCP olarak ölçülen öğenin keşfini geciktirir ve metriği kendi elinizle bozar. Bu görsel erken keşfedilmeli, öncelikli indirilmeli ve mümkünse ön yükleme ile işaretlenmelidir; geç yükleme yalnızca ilk ekranın altında kalan görseller için anlamlıdır.
Düzeltmenin rapora hemen yansımasını beklemek
Saha verisi 28 günlük yuvarlanan pencereyle hesaplandığı için bir iyileştirmenin karneye tam yansıması haftalar alır. Bu sürede panikle arka arkaya değişiklik yapmak, hangi müdahalenin işe yaradığını da ölçülemez hale getirir. Doğru yöntem, düzeltmeyi yayınlayıp gerçek kullanıcı ölçümünü paralel izlemek ve tek seferde tek değişiklik yapmaktır.
Core Web Vitals ne zaman kritik hâle gelir?
Rakiplerle içerik kalitesi ve otorite bakımından başa baş olduğunuz sorgularda, sıralamayı belirleyen ayrıntılar bu tür sinyallere iner. Mobil trafiğin ağırlıklı olduğu e-ticarette ise etki sıralamadan önce dönüşümde görülür: yavaş açılan ürün listesi ve tıklanırken kayan sepet butonu, aramadan gelen kullanıcıyı satın almaya varmadan kaybettirir. Site yenileme ve alan adı taşıma projelerinde de yayın öncesi eşik kontrolü şarttır.
Örnekler
- Resimlerin width/height attribute'u olmaması CLS'i artırır.
- Sayfada lazy loading kullanımı LCP'yi iyileştirir.