Core Web Vitals Nedir? Site Hızı SEO'yu Nasıl Etkiler?

Üç metrik ve eşik değerleri

Core Web Vitals, Google’ın bir sayfanın gerçek kullanıcılar için ne kadar iyi çalıştığını ölçmek için seçtiği üç metriktir. Her biri kullanıcının hissettiği farklı bir sorunu temsil eder: yavaş açılma, geç tepki ve zıplayan sayfa.

Metrik	Ne ölçer	İyi	Geliştirilmeli	Zayıf
LCP (Largest Contentful Paint)	Ekrandaki en büyük içerik öğesinin görünme süresi	≤ 2,5 sn	2,5 – 4,0 sn	> 4,0 sn
INP (Interaction to Next Paint)	Tıklama veya dokunmadan ekranın güncellenmesine kadar geçen süre	≤ 200 ms	200 – 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Yükleme sırasında öğelerin beklenmedik kayma miktarı	≤ 0,1	0,1 – 0,25	> 0,25

Google bir sayfayı “geçti” saymak için üç metriğin de ziyaretlerin %75’inde iyi eşikte olmasını ister. Yani ortalama değil, en yavaş çeyrek belirleyicidir; masaüstünde mükemmel olup mobilde 4G’de yavaş açılan bir site geçemez.

Her metrik sade Türkçeyle ne demek?

LCP: sayfa ne zaman “açıldı” hissi verir?

Kullanıcı bir sayfaya girdiğinde beyaz ekranın ne kadar sürdüğünü değil, ana içeriğin ne zaman göründüğünü hatırlar. LCP tam olarak bunu ölçer: kahraman görseli, başlık bloğu veya ürün fotoğrafı gibi en büyük öğe ne zaman ekrana geldi? Kurumsal bir sitede LCP öğesi genellikle ana sayfadaki büyük görseldir; 800 KB’lık optimize edilmemiş bir PNG tek başına LCP’yi 4 saniyeye taşır.

INP: tıkladım, neden bir şey olmadı?

INP, sayfadaki tüm etkileşimlerin en yavaşına yakın olanını ölçer. Menüye dokundunuz, 600 ms sonra açıldı; sepete ekle dedi, yarım saniye sessizlik oldu. Kullanıcı bu boşlukta “çalışmadı mı?” diye tekrar tıklar. INP’nin baş sorumlusu ana iş parçacığını meşgul eden JavaScript’tir: canlı sohbet aracı, pazarlama izleme scriptleri, ağır slider kütüphaneleri.

CLS: yazıyı okurken buton kaydı

Bir bağlantıya basmak üzereyken üstten reklam banner’ı yüklenir, her şey aşağı kayar ve yanlış yere tıklarsınız. CLS bu kaymaların toplamını ölçer. Boyutu belirtilmemiş görseller, geç yüklenen web fontları ve sonradan eklenen çerez bildirimleri en sık nedenlerdir. 0,1 eşiği oldukça sıkıdır; ekranın %10’unu kaydıran tek bir öğe eşiği aşmaya yeter.

Google bu metrikleri sıralamada nasıl kullanır?

Core Web Vitals, 2021’den beri Google’ın “sayfa deneyimi” sinyalleri arasındadır ve sıralama sistemlerinde kullanılır. Ancak iki şeyi netleştirmek gerekir:

1. İçerik önce gelir. Google’ın kendi dokümantasyonu açıkça söyler: sayfa deneyimi güçlü bir sinyal olsa da içeriğin alaka düzeyi ve kalitesi belirleyicidir. Hızlı ama zayıf bir sayfa, yavaş ama iyi bir sayfayı geçmez.
2. Eşitlik bozucudur. Benzer kalitede içerik sunan iki sayfadan daha iyi deneyim sunan öne çıkar. Rekabetçi anahtar kelimelerde ilk sayfadaki tüm sonuçlar zaten kaliteli olduğundan, bu “küçük” sinyal ilk 3 ile 8. sıra arasındaki farkı yaratabilir.

Bunun pratik sonucu şudur: Core Web Vitals’ı düzeltmek tek başına sıralama getirmez, ama düzeltmemek iyi içeriğin hak ettiği yere çıkmasını engeller. Sıralama sürecinin tamamı için SEO ne kadar sürede sonuç verir yazısına bakabilirsiniz.

Nasıl ölçülür: laboratuvar verisi ile gerçek kullanıcı verisi

Bu ayrımı anlamayan çoğu site sahibi yanlış hedefe koşar.

Kaynak	Veri türü	Ne gösterir	Nerede bakılır
CrUX (Chrome User Experience Report)	Alan (field) verisi	Gerçek Chrome kullanıcılarının son 28 günlük deneyimi	PageSpeed Insights üst bölüm, Search Console
Lighthouse	Laboratuvar (lab) verisi	Sabit bir cihaz ve ağ simülasyonunda tek ölçüm	PageSpeed Insights alt bölüm, Chrome DevTools
Search Console CWV raporu	Alan verisi, URL grupları halinde	Hangi sayfa gruplarının hangi metrikte zayıf olduğu	Search Console > Deneyim > Core Web Vitals
Gerçek kullanıcı izleme (RUM)	Alan verisi, kendi ziyaretçileriniz	Sayfa, cihaz ve bölge bazında canlı ölçüm	web-vitals kütüphanesi + analytics

Google sıralamada yalnızca alan verisini kullanır. PageSpeed Insights’taki 0–100 performans puanı Lighthouse’a aittir, sıralama faktörü değildir; teşhis için kullanılır. Trafiği düşük siteler için CrUX yeterli örnek toplayamaz ve rapor boş kalır; bu durumda Lighthouse ölçümünü mobil profilde, eşiklere göre değerlendirin.

Search Console raporu ise tek tek sayfa değil, benzer şablonlu URL grupları gösterir. “Ürün sayfaları grubu INP’de zayıf” uyarısı, sorunun şablonda olduğu ve tek düzeltmeyle yüzlerce sayfanın iyileşeceği anlamına gelir.

En sık 10 hız sorunu, çözümü ve beklenen kazanım

#	Sorun	Etkilediği metrik	Çözüm	Beklenen kazanım
1	Sıkıştırılmamış büyük görseller	LCP	WebP/AVIF formatı, doğru boyutlandırma, LCP görseline preload	LCP’de 1–2,5 sn
2	Render’ı engelleyen JavaScript	LCP, INP	Script’leri defer/async yapmak, kritik olmayanları ertelemek	LCP’de 0,5–1,5 sn
3	Boyutsuz görseller ve iframe’ler	CLS	width/height veya aspect-ratio tanımlamak	CLS 0,3’ten 0,05’e
4	Web fontu kaynaklı kayma	CLS, LCP	font-display: swap + size-adjust, fontu self-host etmek	CLS’de 0,05–0,15
5	Üçüncü parti scriptler (chat, ısı haritası, pikseller)	INP, LCP	Etkileşim sonrası yükleme, Tag Manager’da tetikleyici disiplini	INP’de 100–300 ms
6	Yavaş sunucu yanıtı (TTFB > 800 ms)	LCP	CDN, sayfa önbelleği, hosting değişimi	LCP’de 0,5–1,5 sn
7	Eklenti yükü (WordPress’te 30+ eklenti)	Hepsi	Kullanılmayanları kaldırma, tek amaçlı hafif alternatifler	Sayfa ağırlığında %30–50
8	Kullanılmayan CSS ve JS	LCP, INP	Kritik CSS ayrımı, kod bölme, tree-shaking	LCP’de 0,3–0,8 sn
9	Uzun JavaScript görevleri (> 50 ms)	INP	Görevleri parçalamak, ağır işi web worker’a taşımak	INP’de 100–250 ms
10	Geç enjekte edilen banner ve çerez bildirimleri	CLS	Alanı önceden ayırmak veya overlay olarak göstermek	CLS’de 0,1–0,2

Kazanımlar tipik kurumsal sitelerde gözlenen aralıklardır. İlk üç madde çoğu sitede toplam sorunun yarısından fazlasını oluşturur ve bir haftadan kısa sürede düzeltilir.

Statik üretilen siteler neden yüksek skor alır?

Astro gibi statik site üreticileri HTML’i ziyaret anında değil, yayın anında oluşturur. Bunun Core Web Vitals’a doğrudan üç etkisi vardır:

• TTFB neredeyse sıfır. Sunucu veritabanına gitmez, PHP çalıştırmaz; CDN’den hazır dosya döner. LCP için en büyük engel baştan kalkar.
• Varsayılan olarak sıfır JavaScript. Astro, etkileşim gerektirmeyen bileşenlere hiç script göndermez. INP’yi bozacak ana iş parçacığı yükü oluşmaz; interaktif parçalar sadece gerektiğinde yüklenir.
• Derleme anında görsel optimizasyonu. Görseller build sırasında WebP/AVIF’e çevrilir, boyutları HTML’e yazılır; CLS kaynağı ortadan kalkar.

Sonuç olarak iyi kurulmuş bir Astro sitesi mobil Lighthouse’da 95+ ve üç metrikte yeşil değer alır; aynı tasarımın WordPress’teki karşılığında bu skoru tutturmak için önbellek, görsel eklentisi ve sürekli bakım gerekir. Kendi sitemiz dahil kurduğumuz SEO uyumlu web siteleri bu yüzden statik altyapı üzerinde çalışır. Maliyet karşılaştırması için web sitesi fiyatları yazısındaki yıllık hosting ve bakım tablosuna bakabilirsiniz.

İş etkisi: hız dönüşüme nasıl yansır?

Sıralamayı bir kenara bırakın; hız doğrudan gelirdir.

• Google’ın mobil araştırmasına göre yükleme süresi 1 saniyeden 3 saniyeye çıktığında terk olasılığı %32, 5 saniyeye çıktığında %90 artar.
• Google ve Deloitte’un “Milliseconds Make Millions” çalışmasında mobil hızda 0,1 saniyelik iyileşme perakende dönüşümünü %8, seyahat dönüşümünü %10 artırdı.
• Ayda 10.000 ziyaretçi alan ve %2 dönüşümle 200 form üreten bir kurumsal site, LCP’yi 4 saniyeden 2 saniyeye çektiğinde tipik olarak 240–260 forma çıkar. Form başına 500 ₺ değer biçerseniz, aylık 20.000–30.000 ₺’lik fark sadece hızdan gelir.

Aynı reklam bütçesiyle daha fazla müşteri anlamına geldiği için, hız iyileştirmesi çoğu zaman reklam bütçesini artırmaktan daha ucuz büyüme yoludur.

Kontrol listesi

Sitenizi bir saat içinde değerlendirmek için sırayla uygulayın:

1. PageSpeed Insights’ta ana sayfa, bir hizmet sayfası ve bir blog yazısını mobil profilde ölçün; üst bölümdeki alan verisine bakın.
2. Search Console > Core Web Vitals raporunda “Zayıf” ve “Geliştirilmeli” URL gruplarını listeleyin.
3. LCP öğesini tespit edin (PageSpeed raporunda gösterilir); görsel ise WebP/AVIF, doğru boyut ve preload uygulayın.
4. Tüm görsellere width/height verin; fontları self-host edin ve font-display ayarlayın.
5. Tag Manager’daki scriptleri listeleyin; son 6 ayda raporuna bakılmayan her aracı kaldırın.
6. TTFB’yi ölçün; 800 ms üzerindeyse hosting veya önbellek katmanını değiştirin.
7. WordPress kullanıyorsanız eklenti sayısını 15’in altına indirin.
8. Düzeltmelerden 28 gün sonra Search Console raporunu yeniden kontrol edin.

Mevcut sitenizin ölçümünü ve hangi maddelerin en hızlı kazanım getireceğini görmek için ücretsiz teknik ön inceleme talep edebilirsiniz; raporu 2 iş günü içinde metrik bazında paylaşırız.