Rehber

Core Web Vitals nedir? LCP, INP ve CLS nasıl ölçülür, nasıl iyileştirilir?

Core Web Vitals'ın üç metriği neyi ölçer, sıralamayı ne kadar etkiler, doğru ölçüm nasıl yapılır? Eşikler, adım adım iyileştirme ve Türkiye'ye özgü bir ölçüm sınırı.

Fratres Editör · 11 Kasım 2026

Core Web Vitals, bir sayfanın gerçek kullanıcılar için ne kadar hızlı yüklendiğini, etkileşime ne kadar çabuk tepki verdiğini ve içeriğin ne kadar sabit kaldığını ölçen üç Google metriğidir: LCP, INP ve CLS. Mobil ve masaüstü ayrı değerlendirilir. Sayfanın geçmesi için ziyaretlerin dörtte üçünde üç metriğin de iyi eşiğinde kalması gerekir.

Üç metrik neyi ölçer, eşikler kaç?

web.dev başarıyı 75. yüzdelikte arar: Ziyaretleri en iyiden en kötüye dizdiğinizde dörtte üçüncü sıradaki değer eşiği geçmelidir. Üç metriğin de geçmesi şarttır. İki iyi sonuç üçüncüyü telafi etmez.

LCP (Largest Contentful Paint, en büyük içeriğin görünmesi): Ekrandaki en büyük görsel, video veya metin bloğunun ne zaman göründüğünü ölçer. Kullanıcı için karşılığı "Sayfa geldi mi?" sorusudur. web.dev 2,5 saniye ve altını iyi, 4 saniyenin üstünü kötü sayar.
INP (Interaction to Next Paint, etkileşimden sonraki ilk boyama): Tıklama, dokunma veya tuşa basmadan sonra ekranın ne kadar sürede güncellendiğini ölçer. Kaydırma ve imleci üzerine getirme sayılmaz. Karşılığı "Düğmeye bastım, sayfa duydu mu?" sorusudur. web.dev 200 milisaniye ve altını iyi, 500 milisaniyenin üstünü kötü sayar.
CLS (Cumulative Layout Shift, birikimli düzen kayması): Sonradan yüklenen öğelerin içeriği beklenmedik biçimde itmesini puanlar. Karşılığı, okurken satırın kaçması veya yanlış düğmeye basmaktır. Birimi yoktur; kayan alanın büyüklüğü ile kayma mesafesi çarpılır. web.dev 0,1 ve altını iyi, 0,25'in üstünü kötü sayar.

Eski yazılarda rastlayacağınız FID artık bu üçlüde yok. Yerini alan INP yalnız ilk etkileşimi değil, ziyaret boyunca tüm etkileşimleri izler. Eşikler 2 Kasım 2026 itibarıyla web.dev, Search Console ve PageSpeed Insights belgelerinde aynıdır. 2026 tarihli bazı blog yazılarındaki farklı eşikler bu belgelerde yer almıyor. Yeni bir eşik iddiası görürseniz önce web.dev'e bakın.

Core Web Vitals sıralamayı ne kadar etkiler?

Yanıt, tanıtım metinlerinin ima ettiğinden daha ölçülü. Google'ın sayfa deneyimi belgesi Core Web Vitals'ın sıralama sistemlerinde kullanıldığını söyler. Aynı belge tek bir deneyim sinyali olmadığını, deneyimi zayıf olsa bile en alakalı içeriğin gösterileceğini ve yalnız SEO için kusursuz skor kovalamanın zamanı iyi kullanmak olmayabileceğini de yazar.

Pratik okuması şu: Deneyim, benzer ölçüde yararlı sayfalar yarışırken fark yaratır. Zayıf içeriği öne çıkarmaz, eşikleri geçmek de sıralama garantisi vermez. Bu işe ayrılan bütçenin gerekçesi yalnız sıralama olmamalı. Yavaş açılan ürün sayfası veya kayan form, trafik gelse bile kullanıcıyı yolda bırakabilir. Google, yapay zekâ özellikleri belgesinde de iyi sayfa deneyimini temel uygulamalar arasında sayıyor; o tarafı AI Overviews yazımızda ele aldık.

Pazarın geneli de bir ölçü verir. HTTP Archive Web Almanac 2025, Temmuz 2025 ölçümünde sitelerin mobilde %48'inin, masaüstünde %56'sının üç metriği de geçtiğini raporluyor. Mobilde en zayıf halka LCP: Sitelerin %62'si iyi eşikte. INP'de bu oran %77, CLS'de %81. Mobilde eşiği geçmek hâlâ sitelerin yarısından azının başardığı bir iş.

Nasıl ölçülür: Saha verisi mi, laboratuvar testi mi?

Karar saha verisiyle verilir, teşhis laboratuvarda konur. web.dev önceliği saha verisine verir, çünkü bu veri gerçek cihazları, bağlantıları ve kullanıcı davranışını yansıtır. Laboratuvar testi tek cihaz ve tek ağla çalışır, ama tekrarlanabilir olduğu için hata ayıklamaya ve yayın öncesi denemeye yarar.

Araçları şu sırayla kullanın:

Search Console, Core Web Vitals raporu: Nereden başlayacağınızı gösterir. Google'ın yardım sayfasına göre benzer URL'leri gruplar, son 28 günün gerçek kullanıcı verisini kullanır ve grubun durumunu en kötü metriğine göre belirler.
PageSpeed Insights: Tek bir URL'yi inceler. Belgesine göre saha verisini önceki 28 günlük Chrome kullanıcı raporundan (CrUX, Chrome User Experience Report), laboratuvar verisini Lighthouse'tan alır. URL'nin verisi yetmezse sitenin tamamına ait sonucu gösterir.
Lighthouse ve Chrome DevTools: Nedeni bulmaya yarar. Lighthouse INP ölçmez, yerine Toplam Engelleme Süresi'ni (TBT, Total Blocking Time) kullanır. web.dev TBT iyi olsa bile INP'nin kötü çıkabileceğini belirtir.
Gerçek kullanıcı izleme (RUM, Real User Monitoring): web-vitals JavaScript kütüphanesiyle ölçümü kendi verinizde toplarsınız. Görüntüleme düzeyinde ayrıntı burada bulunur.

Lighthouse'un 0-100 arası performans puanı ile Core Web Vitals değerlendirmesi farklı şeylerdir. Puan tek bir simülasyonun özetidir. Değerlendirme ise gerçek ziyaretlerin 75. yüzdeliğine bakar. Bu yüzden 90 puan alan bir sayfa saha verisinde kalabilir.

LCP, INP ve CLS nasıl iyileştirilir?

Sıra metrikten değil şablondan başlar. Aynı şablonu paylaşan sayfalar çoğunlukla aynı sorunu paylaşır.

Sorunlu şablonu seçin. Search Console'da mobil görünümde en çok URL içeren sorunlu grubu açın. Ürün, kategori veya blog şablonunu bir kez düzeltmek, sayfa sayfa uğraşmaktan verimlidir.
LCP öğesini belirleyin. Web Almanac verisine göre mobil sayfaların %76'sında bu öğe bir görsel. Görselse src veya srcset değerini JavaScript ile değil doğrudan HTML'de verin, fetchpriority="high" ekleyin, loading="lazy" kullanmayın, AVIF veya WebP biçiminde doğru boyutta sunun (web.dev).
Sunucu yanıtını ölçün. LCP süresi dört parçaya ayrılır. web.dev kılavuzu ilk bayta kadar geçen süreye (TTFB, Time to First Byte) ve kaynağın inmesine yaklaşık %40'ar pay ayırır, iki gecikme parçasını %10'un altında tutmayı önerir. Yönlendirmeleri azaltın, önbellekteki içeriği CDN (içerik dağıtım ağı) üzerinden sunun.
INP için ana iş parçacığını (main thread) boşaltın. Uzun görevleri bölün, tıklama işleyicisinde yalnız bir sonraki görsel güncellemeyi yapın, kaydetme gibi işleri sonraki göreve bırakın, DOM'u küçültün, betik miktarını azaltın (web.dev).
CLS için yer ayırın. Görsel ve videolara width ve height verin, reklam ve gömülü içerik için min-height tanımlayın, animasyonda top ve left yerine transform kullanın, web fontlarına uygun bir yedek font seçin (web.dev).
Düzeltmeyi doğrulayın. Search Console'da doğrulamayı başlatın. Google 28 gün izler. Bu sürede sorunu taşıyan URL çıkmazsa konu kapanır.

Sık yapılan hatalar

Yalnız ana sayfayı test etmek. Ana sayfa iki yönde yanıltır. Web Almanac verisinde mobilde üç metriği geçen ana sayfa oranı %45, iç sayfa oranı %56. INP'de tablo tersine dönüyor: Ana sayfaların %80'i, iç sayfaların %69'u iyi. Filtreli listeler ve sepet gibi etkileşimi yoğun sayfaları ayrıca ölçün.
LCP görselini tembel yüklemek (lazy loading). Aynı rapora göre mobil sayfaların %17'si bunu yapıyor. Tüm görsellere tembel yükleme uygulayan tema ve eklenti ayarlarını kontrol edin.
Görsel boyutlarını yazmamak. Mobil sayfaların %62'sinde boyutu belirtilmemiş en az bir görsel var (Web Almanac). CLS'nin en ucuz düzeltmesi budur.
Yükleme sonrası kaymaları kaçırmak. web.dev, laboratuvar araçlarının çoğunlukla ilk yüklemeyi, saha verisinin ise sayfanın tüm ömrünü ölçtüğünü belirtir. Laboratuvar temiz, saha kötüyse sonradan açılan çerez bandına, kampanya şeridine ve reklam alanlarına bakın.
Etkiyi ertesi gün aramak. Saha verisi 28 günlük bir pencere olduğu için eski ziyaretler pencereden çıkana kadar grafik yavaş değişir. Haftalık takipte laboratuvar sonucuna, aylık kararda saha verisine bakın.
Kampanya döneminde etiket yığmak. Her yeni etiket, ana iş parçacığında çalışan yeni bir betik demektir. INP'yi büyük kampanyanın başlangıcından sonra ayrıca kontrol edin.

Türkiye'de durum: Saha verisinde iPhone görünmez

CrUX'un kapsamı, Türkiye'deki siteler için pratik bir sınır getirir. Chrome'un metodoloji sayfası, veri setinin iOS'taki Chrome'u, Edge gibi diğer Chromium tarayıcılarını ve uygulama içi WebView'ları dışarıda bıraktığını söylüyor. Mobil tarafta elinizdeki tablo aslında Android Chrome tablosudur.

StatCounter, Ekim 2026'da Türkiye'nin mobil işletim sistemi payını Android için %76,78, iOS için %23,22 olarak gösteriyor. Search Console'un iyi dediği bir mobil şablon, iPhone kullanan kitlenin deneyimi hakkında bir şey söylemez. Kendi analitik hesabınızda iOS payına bakın. Payınız yüksekse ödeme, form ve ürün sayfalarını gerçek iPhone'da da deneyin. Çevrim içi alışverişin Türkiye'deki ölçeğini Türkiye e-ticaret verileri yazımızda bulabilirsiniz.

İkinci sınır trafik. CrUX asgari ziyaretçi sayısı ister ve bu eşiği açıklamaz. Trafiği düşük kurumsal sitelerde rapor boş kalabilir. O durumda PageSpeed Insights'ın laboratuvar sonucuyla ilerlemek, kurumsal web sitesi yenilemelerinde ise performans hedefini tasarım başlamadan yazılı hale getirmek gerekir.

Yarın ilk olarak Search Console'u açın

Core Web Vitals raporunda mobil görünüme geçin ve en çok URL içeren sorunlu grubu seçin. Örnek bir URL'yi PageSpeed Insights'a verin. Kalan metriği, 75. yüzdelik değerini ve LCP öğesini not edin. Geliştirici ekibinize dört alanlı tek bir iş açın: şablon adı, metrik, mevcut değer, hedef eşik. Rapor boşsa aynı notu en çok trafik alan üç şablonun laboratuvar sonucuyla hazırlayın. Bu not, ileride yapılacak bir teknik SEO çalışmasının da başlangıç noktası olur.