Core Web Vitals Nedir? LCP, INP ve CLS Metrikleri

Google Search Console’da Core Web Vitals raporunda bazı URL’lerin “zayıf” olarak değerlendirilmesi, sitenin genel performansına dair önemli bir sinyal sunar. Ancak bu sonuçlar her zaman yalnızca sunucu altyapısı veya sayfa açılış hızıyla açıklanamaz. Kullanıcı deneyimini etkileyen farklı teknik faktörleri ve Google’ın ölçüm yöntemini birlikte değerlendirmek, sorunun kaynağını doğru belirlemek için kritik önem taşır.

Core Web Vitals, Google’ın gerçek kullanıcı verileri üzerinden sayfa deneyimini değerlendirmek için kullandığı üç temel metriktir. Bu rehberde, 2026 itibarıyla geçerli metrikleri ve eşik değerlerini, raporlardaki verilerin nasıl doğru yorumlanması gerektiğini ele alacağız.

Core Web Vitals Nedir?

Core Web Vitals, bir web sayfasının gerçek kullanıcılar tarafından nasıl deneyimlendiğini ölçen üç temel metriktir: sayfanın yüklenme hızını gösteren LCP, kullanıcı etkileşimlerine verilen yanıt süresini gösteren INP ve sayfa yüklenirken görsel öğelerin kayma miktarını gösteren CLS.

Tanımdaki belirleyici ifade “gerçek kullanıcılar” kısmıdır. Core Web Vitals, geliştirme ortamındaki performansı değil, sitenin farklı cihaz ve şebeke koşullarında ziyaret edilirken oluşan gerçek deneyimini ölçer. Kurumsal ağ bağlantısı üzerinden yapılan testler, mobil şebekede düşük donanımlı bir cihazla erişen kullanıcının deneyimini temsil etmez.

Google, değerlendirmeyi 75. yüzdelik dilim üzerinden yürütür. Kullanıcıların %75’i eşik değerinin altında bir deneyim yaşıyorsa sayfa “iyi” olarak sınıflandırılır. Ortalama yerine yüzdelik dilim kullanılması bilinçli bir tercihtir; ortalama değer, en olumsuz deneyimi yaşayan kullanıcı kesimini gizleme eğilimindedir.

2026’da Core Web Vitals Metrikleri ve Eşik Değerleri

Metrik	Ne Ölçer	İyi	İyileştirilmeli	Zayıf
LCP (Largest Contentful Paint)	Yükleme performansı	≤ 2,5 sn	2,5 – 4,0 sn	> 4,0 sn
INP (Interaction to Next Paint)	Etkileşim hızı	≤ 200 ms	200 – 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Görsel kararlılık	≤ 0,1	0,1 – 0,25	> 0,25

 

Bir sayfanın “iyi” olarak sınıflandırılması için üç metriğin de eşik değerini karşılaması gerekir. İki metrik hedefi tutturup biri tutturamıyorsa sayfa zayıf grubunda değerlendirilir.

Largest Contentful Paint (LCP) Yükleme Hızı Nedir?

LCP, kullanıcının sayfanın yüklendiğini algıladığı andır. Bu sürenin uzaması, içerik görüntülenmeden gerçekleşen çıkış oranını yükseltir.

LCP, görüntü alanındaki en büyük içerik öğesinin ekrana çizilmesi için geçen süreyi ölçer. Bu öğe genellikle hero görseli, ürün fotoğrafı veya büyük puntolu bir metin bloğudur. Hedef değer: 2,5 saniye ve altı.

LCP süresinin uzamasına yol açan üç yaygın etken:

• Yüksek sunucu yanıt süresi. Tarayıcı HTML belgesini almadan çizim işlemine başlayamaz. En sık göz ardı edilen bileşendir.
• LCP öğesinin geç keşfedilmesi. Görsel CSS içinde tanımlıysa veya JavaScript ile ekleniyorsa tarayıcı öğeyi geç fark eder.
• Render-blocking kaynaklar. Belge başında yüklenen büyük CSS ve senkron JavaScript dosyaları çizimi geciktirir.

Interaction to Next Paint (INP) Etkileşim Hızı Nedir?

INP, kullanıcının arayüzü yavaş algıladığı andır. Filtreleme veya sepete ekleme gibi işlemlerde yaşanan gecikme, dönüşüm hunisinin ortasında kayıp oluşturur.

INP, sayfayla kurulan tüm etkileşimlerin (tıklama, dokunma, klavye girişi) yanıt sürelerini ölçer ve bunlar arasından en olumsuz değere yakın bir sonucu raporlar. Ölçülen süre, etkileşimin ardından ekranda görsel bir değişikliğin oluşmasına kadar geçen zamandır. Hedef değer: 200 milisaniye ve altı.

FID Neden Kaldırıldı? INP’ye Geçiş Ne Anlama Geliyor?

2024 yılına kadar etkileşim metriği First Input Delay (FID) idi. FID yalnızca sayfadaki ilk etkileşimi ve yalnızca gecikme süresini ölçüyor, işlemin tamamlanma süresini kapsamıyordu. Bu iki sınırlama metriği fazla iyimser hâle getirmiş; sayfalar eşik değerini kolaylıkla karşılarken gerçek kullanımda performans sorunları devam etmiştir.

Geçişin uygulamadaki üç sonucu:

• FID eşiğini karşılayan bir sayfa INP eşiğini karşılamayabilir. Metrik değişimi sonrasında çok sayıda site zayıf gruba geçmiştir.
• İlk etkileşimin optimize edilmesi yeterli değildir; sayfa ömrü boyunca gerçekleşen tüm etkileşimler ölçüme dahildir.
• Çözüm seti farklılaşmıştır. FID için JavaScript’in ertelenmesi çoğu durumda yeterliyken, INP ana iş parçacığındaki uzun görevlerin parçalanmasını gerektirir.

Cumulative Layout Shift (CLS) Görsel Kararlılık Nedir?

CLS, hedeflenen arayüz öğesinin son anda yer değiştirmesi durumudur. Hatalı tıklamaya ve işlem terkine yol açar.

CLS, sayfa yüklenirken görsel öğelerin beklenmedik biçimde kaymasını ölçer. Puanlama, kayan alanın büyüklüğü ile kayma mesafesinin çarpımına dayanır. Hedef değer: 0,1 ve altı.

Başlıca kaynaklar: boyutu tanımlanmamış görseller, geç yüklenen reklam alanları, sonradan eklenen çerez bildirimleri ve web fontu yüklendiğinde metnin yeniden akması.

Core Web Vitals SEO’yu ve Dönüşümü Nasıl Etkiler?

Sorunun iki ayrı katmanda değerlendirilmesi gerekir. Sektördeki içeriklerin çoğu birinci katmanı olduğundan büyük gösterip ikincisini kapsam dışı bırakmaktadır.

1. Sıralama etkisi. Google, Core Web Vitals’ı sayfa deneyimi sinyalleri kapsamında değerlendirdiğini belirtmektedir. Ancak beklentinin gerçekçi tutulması önemlidir: Core Web Vitals, içerik kalitesi yetersiz bir sayfayı üst sıralara taşımaz. Metrik, içerik kalitesi ve arama niyetine uygunluk açısından birbirine yakın sayfalar arasında ayrıştırıcı işlev görür. Etkisi, rekabetin yoğun olduğu sorgularda anlamlıdır.
2. Dönüşüm etkisi. Ticari açıdan belirleyici katman budur ve sıralama etkisine kıyasla çok daha net ölçülebilir:

• Yavaş yüklenen sayfalarda kullanıcı içeriği görüntülemeden çıkar. Bu kayıp organik trafik verisine yansımaz, gelir tarafına yansır.
• Yavaş etkileşimler (INP) dönüşüm hunisinin orta bölümünde zarar verir: filtreleme, sepete ekleme ve form doldurma adımları.
• Kayan düzen (CLS) hatalı tıklamaya yol açar; mobil cihazlardaki etkisi masaüstüne kıyasla belirgin biçimde yüksektir.

Bu etki tahmin edilmek yerine ölçülebilir. Analitik aracında kullanıcılar LCP değerine göre segmentlere ayrılarak (2,5 saniyenin altı ve üstü) her segmentin dönüşüm oranı karşılaştırıldığında, teknik iyileştirme bütçesinin kurum içinde gerekçelendirilmesi için ölçülebilir bir dayanak elde edilir.

Core Web Vitals Nasıl Ölçülür?

Ölçüm, süreçte en çok hata yapılan aşamadır. Aracın amacı dışında kullanılması, ekiplerin uzun süre yanlış önceliklere odaklanmasına yol açar.

Araç	Veri Tipi	Ne İçin Kullanılır
Google Search Console	Saha (CrUX)	Sıralamayı etkileyen gerçek durumu görmek
PageSpeed Insights	Saha + Laboratuvar	Tek bir URL’yi hem gerçek hem test verisiyle incelemek
Lighthouse / DevTools	Laboratuvar	Geliştirme sırasında hata ayıklamak
Chrome UX Report (CrUX)	Saha	Rakip karşılaştırması ve trend analizi
RUM (gerçek kullanıcı izleme)	Saha	Sürekli izleme ve segment bazlı analiz

 

Saha Verisi ve Laboratuvar Verisi Farkı

En sık karşılaşılan soru şudur:

“PageSpeed Insights skoru 95 olmasına rağmen Search Console sayfaları ‘zayıf’ olarak raporluyor. Hangi veri esas alınmalıdır?”

İki kaynak da doğrudur; farklı ölçüm yöntemlerine dayanır.

• Laboratuvar verisi (lab data): Kontrollü ortamda gerçekleştirilen tek seferlik simülasyondur. Lighthouse, tanımlı bir cihaz ve şebeke profiliyle sayfayı bir kez yükler. Tekrarlanabilir olduğu için hata ayıklama aşamasında tercih edilir.
• Saha verisi (field data): Siteyi son 28 gün içinde ziyaret etmiş Chrome kullanıcılarından toplanan anonim ölçümlerdir. Chrome User Experience Report (CrUX) veri kümesinde toplanır; Search Console ve PageSpeed Insights’ın üst bölümünde sunulur.

Belirleyici nokta şudur: Google, arama sistemlerinde saha verisini esas alır. Laboratuvar skoru 100 olsa dahi, kullanıcıların önemli bir bölümü düşük şebeke koşullarında erişiyorsa saha verisi zayıf sonuç verecektir.

Buradan çıkan üç uygulama kuralı:

• Kararlar Search Console verisine dayandırılmalı, laboratuvar skoruna göre alınmamalıdır.
• Teşhis DevTools üzerinden yapılmalıdır; saha verisi sorunun kaynağını satır düzeyinde göstermez.
• PageSpeed Insights’ın üst bölümü mevcut durumu, alt bölümü iyileştirme yönünü gösterir. 0–100 aralığındaki skor bir Core Web Vitals metriği değildir.

Google Search Console Core Web Vitals Raporu

Süreç bu raporla başlatılmalıdır. Rapor, URL’leri benzer sayfa gruplarına ayırır ve her grup için mobil ile masaüstü ayrımında durum bilgisi sunar. Tekil URL bazında ilerlemek yerine grup bazında çalışılması önerilir; bir ürün detay şablonunda yapılan düzeltme binlerce URL’yi aynı anda etkiler.

PageSpeed Insights, Lighthouse ve DevTools

• PageSpeed Insights: Tekil URL incelemesi için en pratik araçtır. Önce saha verisi, ardından laboratuvar bulguları değerlendirilmelidir.
• Lighthouse: Geliştirme aşamasının aracıdır. Yapılan değişikliğin etkisini anında görünür kılar.
• DevTools Performance sekmesi: INP teşhisi için en kapsamlı araçtır. Uzun görevler, ana iş parçacığını meşgul eden scriptler ve etkileşim sonrası çizim gecikmesi bu sekmede analiz edilir.

Sürekli İzleme: Tek Seferlik Ölçümün Yetersizliği

Saha verisi 28 günlük kayan bir pencereden hesaplanır. Bunun iki sonucu vardır:

• Yapılan düzeltmenin Search Console’a yansıması haftalar sürer. Ertesi gün yapılan değerlendirme erken sonuç üretir.
• Regresyonlar da (örneğin pazarlama tarafında eklenen yeni bir script) aynı gecikmeyle görünür hâle gelir ve bu noktada kök neden analizi zorlaşır.

Bu nedenle Core Web Vitals bir proje değil, süreklilik gerektiren bir süreçtir. Yayın öncesi performans kontrolü ve sürekli izleme kurgusu oluşturulmadığı takdirde iyileştirilen metrikler kısa sürede eski seviyesine döner.