Core Web Vitals nedir? LCP, INP, CLS ve sayfa hızının UX tarafı

Kısaca

Core Web Vitals, sayfanın kullanıcı tarafında nasıl çalıştığını üç sayıyla anlatır. web.dev bu üç metriği, her web sayfasına uygulanan Web Vitals alt kümesi olarak tanımlar.

• LCP (Largest Contentful Paint): görünür alandaki en büyük görselin ya da metin bloğunun çizildiği an. Yüklenmeyi ölçer.
• INP (Interaction to Next Paint): tıklama, dokunma ve tuşa basmadan sonra ekranın tepki süresi. Etkileşimi ölçer.
• CLS (Cumulative Layout Shift): içeriğin beklenmedik kayma miktarı. Görsel kararlılığı ölçer.

Bu metrikler geliştirici raporundan çıkmış gibi durur. Bana göre her biri, ölçülmüş bir kullanıcı şikâyetidir: "sayfa açılmadı", "bastım ama bir şey olmadı", "yanlış yere tıkladım".

LCP, INP ve CLS eşikleri

web.dev her metrik için iki sınır verir. Değer iyi sınırında ya da altındaysa iyi, zayıf sınırının üstündeyse zayıf sayılır. İkisinin arası "iyileştirilmeli" bölgesidir.

Metrik	İyi	İyileştirilmeli	Zayıf
LCP	2,5 sn ve altı	2,5 sn ile 4 sn arası	4 sn üstü
INP	200 ms ve altı	200 ms ile 500 ms arası	500 ms üstü
CLS	0,1 ve altı	0,1 ile 0,25 arası	0,25 üstü

Tabloyu web.dev'in eşikleri anlatan makalesinden aldım. Makale en son 7 Mayıs 2025'te güncellendi. Web Vitals ana sayfası da (son güncelleme 31 Ekim 2024) aynı iyi sınırlarını verir.

75. yüzdelik kuralı

Eşikler tek bir ölçüme uygulanmaz. web.dev, sayfa yüklemelerinin 75. yüzdeliğine bakmayı ve mobil ile masaüstünü ayrı değerlendirmeyi önerir.

Pratikte şöyle okunur: sayfa görüntülemelerinin en az yüzde 75'i iyi sınırını karşılıyorsa sonuç iyidir. Görüntülemelerin en az yüzde 25'i zayıf bölgedeyse sonuç zayıftır.

Bu kuralı seviyorum, çünkü ortalamanın sakladığı kullanıcıyı öne çıkarır. Ofisin hızlı ağında her şey iyi görünebilir. Eski telefonu ve zayıf bağlantısı olan kullanıcı ise bambaşka bir sayfa görür.

Kendi değerlerinizi aşağıya girin. Etiketler yukarıdaki tablonun sınırlarını kullanır.

Eşik etiketleyici

Bu araç JavaScript ile çalışır. Eşikler yukarıdaki tabloda yazılıdır.

Etiketler web.dev'in eşiklerini kullanır: iyi sınırına eşit değer iyi, zayıf sınırını aşan değer zayıf sayılır. Kaydırıcı aralıklarını ben seçtim. Buraya tek bir ölçümü değil, ziyaretlerin 75. yüzdeliğini girin.

LCP: sayfa ne zaman hazır görünüyor?

LCP, görünür alandaki en büyük görselin, videonun ya da metin bloğunun çizildiği andır. Kullanıcının "sayfa geldi" dediği an budur. Ürün sayfasında bu öğe ürün fotoğrafı, bir yazıda başlık ya da ilk paragraf olabilir.

web.dev'e göre LCP adayı olabilen öğeler img, SVG içindeki image ve video öğeleridir. CSS url() ile yüklenen arka plan görselleri ve metin içeren blok öğeler de sayılır. Gradyan arka planlar sayılmaz.

Audit'lerde gördüğüm kadarıyla LCP sorunlarının bir kısmı tasarım masasında başlar. İlk ekrana ağır bir video koymak ya da başlığı geç yüklenen bir yazı tipine bağlamak buna örnektir.

web.dev LCP için şunları önerir:

• Ana görsel HTML kaynağında doğrudan yer alsın, tarayıcı onu JavaScript beklemeden bulabilsin.
• Ana görsele tembel yükleme (loading="lazy") verilmesin. web.dev bunun her zaman gereksiz gecikme yarattığını yazar.
• Ana görsele fetchpriority="high" verilsin. web.dev bu önceliği yalnızca bir ya da iki görsele vermeyi önerir.
• LCP öğesi web yazı tipine bağlı bir metinse yazı tipi HTML'de rel="preload" ile yüklensin. Böylece tarayıcı onu erkenden keşfeder.

Bu maddeler geliştiricinin işi gibi durur. Ama hangi öğenin LCP olacağına tasarım karar verir. İlk ekranda tek ve net bir ana görsel, geliştiriciye kolay bir iş bırakır.

INP: bastım, bir şey oldu mu?

INP, sayfanın kullanıcı etkileşimlerine genel tepkisini ölçer. Fareyle tıklama, dokunmatik ekranda dokunma ve tuşa basma sayılır. Fareyle üzerine gelme, yakınlaştırma ve kaydırma sayılmaz.

web.dev, INP'yi FID (First Input Delay) metriğinin halefi olarak tanımlar. FID yalnızca sayfadaki ilk etkileşimin giriş gecikmesini ölçüyordu.

web.dev duyurusunda INP'nin 12 Mart 2024'te Core Web Vital olacağını ve FID'nin yerini alacağını yazdı. Sayfaya sonradan eklenen not ise INP'nin FID'nin yerini resmen aldığını söyler.

Kullanıcı açısından INP basit bir soruya cevaptır: bastığım şey işe yaradı mı? Ekran tepki vermezse insanlar ikinci kez basar ya da sayfanın donduğunu düşünür.

Doherty eşiği INP'yi iyi tamamlar. Doherty eşiği sistemin yanıt süresine bakar, INP ise ekranın ilk tepkisine. İkisinden çıkardığım ders aynı: beklettiğinizi kullanıcıya hemen gösterin.

Uzun görevler

web.dev'e göre 50 milisaniyeden uzun süren her görev uzun görevdir. Uzun görev, sürdüğü boyunca ana iş parçacığını engeller.

web.dev'in önerisi, uzun görevi küçük parçalara bölmek ve parçaların arasında ana iş parçacığına sıra vermektir (yield). Böylece tarayıcı daha öncelikli işlere, örneğin kullanıcı etkileşimine, çok daha erken yanıt verebilir.

Tasarımcının işi o ilk tepkiyi tanımlamaktır. Butona basılınca hemen değişen bir durum ya da bir yükleniyor göstergesi tasarlayın. Ağır iş arkada sürerken ekran kullanıcıya "aldım" desin.

CLS: kayan sayfa ve yanlış tıklama

CLS, sayfa açık kaldığı sürece yaşanan beklenmedik düzen kaymalarının en büyük patlamasını puanlar. web.dev'in ifadesiyle kayma, ancak kullanıcı onu beklemiyorsa kötüdür. Kullanıcı girdisinden sonraki 500 milisaniye içindeki kaymalar hesap dışında bırakılabilir.

web.dev'e göre beklenmedik kayma çoğunlukla kaynaklar eşzamansız yüklendiğinde ya da mevcut içeriğin üstüne yeni öğeler eklendiğinde olur. Makalenin saydığı nedenler şunlar:

• Boyutu belirtilmemiş görseller ve videolar.
• Yedek yazı tipinden daha büyük ya da daha küçük çizilen web yazı tipleri.
• Kendini dinamik olarak yeniden boyutlandıran üçüncü taraf reklamlar ve gömülü bileşenler.

Kullanıcı tarafında CLS, kaybolan okuma yeri ve yanlış tıklamadır. Bir ödeme sayfasında onay butonu yerine bir reklama ya da iptal butonuna basmak, kaymanın en pahalı hâlidir.

Aşağıda önce "Yer ayır" kapalıyken reklamı yükleyin ve reklam gelmeden "Siparişi onayla" butonuna tıklamaya hazırlanın. Sonra "Yer ayır"ı açıp aynısını tekrarlayın.

Kayma simülasyonu

Sepet özeti

2 ürün, kargo dahil toplam 1.248 TL

Siparişi onayla Siparişi iptal et

Bu örnek JavaScript ile çalışır. Kapalıyken reklam yüklenmez ve butonlar yerinde durur.

Örnekteki sepet, reklam ve tutarlar uydurmadır. Reklam, kaymayı görebilmeniz için 2 saniye gecikmeyle gelir. Butonları CSS transform ile taşıdım ve kutunun yüksekliğini sabit tuttum, böylece bu sayfanın kendisi kaymıyor.

Yer ayırmanın kodu çoğu zaman tek satırdır: reklam alanına bir min-height vermek. web.dev bunu reklam ve gömülü içerik için yollardan biri olarak gösterir. Geç gelen içeriği sayfanın aşağısına koymayı da önerir, böylece CLS'ye etkisi azalır.

Tasarım tarafından düzeltmeler

Bu metriklerin bir kısmı tasarım dosyasında kazanılır ya da kaybedilir. Audit'lerde baktığım başlıklar şunlar.

Görsel boyutları

Her görsel ve video için en boy oranını tasarımda sabitleyin. web.dev her görselde ve videoda width ile height niteliklerini kullanmayı önerir. Diğer yol, yeri CSS aspect-ratio ile ayırmaktır.

Kullanıcının yüklediği ya da yönetim panelinden gelen görsellerde oran değişkendir. Tasarımda bunlar için sabit bir kutu ve kırpma kuralı tanımlayın.

İskelet ekranlar

Geç gelen içerik için, gelecek içerikle aynı boyutta bir iskelet (skeleton) tasarlayın. web.dev, yükleme sonrası gelen arayüz için yeri yer tutucu ya da iskeletle önceden ayırmayı önerir. İçerik geldiğinde sayfa kaymaz, kullanıcı da neyin geleceğini görür.

Burada dikkat ettiğim nokta, iskeletin gerçek içerikle aynı yüksekliği taşımasıdır. Üç satırlık iskeletin yerine beş satırlık metin gelirse kayma yine olur.

Yazı tipi yükleme

Özel yazı tipi yüklenirken tarayıcı önce yedek yazı tipini gösterebilir. İkisinin ölçüleri farklıysa satırlar değişir ve sayfa kayar. Yedek yazı tipini, ölçüleri özel yazı tipine yakın olandan seçin.

web.dev yeniden yerleşimi önlemek için font-display: optional kullanmayı ve kritik yazı tiplerini önden yüklemeyi önerir. Ben tasarımda kullanılan yazı tipi ağırlıklarını da azaltırım, çünkü her ağırlık ayrı bir dosyadır.

Ağır etkileşimlerde ilk tepki

Filtreleme, sepete ekleme ya da form gönderme gibi etkileşimlerde ilk tepkiyi ayrıca tasarlayın. Buton anında basılı duruma geçsin, sonuç arkadan gelsin. Geliştiriciden bu tepkiyi ağır işten önce çizmesini isteyin.

Kim neyi düzeltir?

Raporu ekibe dağıtırken işi aşağıdaki gibi bölerim. Bu tablo web.dev'den gelmiyor, kendi çalışma biçimimi gösteriyor.

Metrik	Tasarımda	Kodda
LCP	İlk ekranda tek ana görsel, hafif yazı tipi seçimi	Görselin HTML'de olması, öncelik, tembel yüklemenin kaldırılması
INP	Basılı durum, yükleniyor göstergesi, iyimser güncelleme	Uzun görevleri bölmek, ilk tepkiyi önce çizmek
CLS	Sabit görsel oranları, iskeletler, bantların yeri	Boyut nitelikleri, min-height, yazı tipi yükleme ayarı

Animasyonlar

Hareket tasarlıyorsanız öğeleri top ya da left ile değil, transform ile taşıyın. web.dev taşıma, büyütme, döndürme ve eğme için transform animasyonlarını önerir. Yukarıdaki demoyu da bu yüzden transform ile kurdum.

Nasıl ölçülür?

Core Web Vitals gerçek kullanıcı verisiyle değerlendirilir. Chrome Kullanıcı Deneyimi Raporu (CrUX), her metrik için anonim gerçek kullanıcı verisi toplar. Bu veri PageSpeed Insights'ı, Chrome DevTools'u ve Search Console'daki Core Web Vitals raporunu besler.

web.dev laboratuvar araçları olarak Chrome DevTools'u ve Lighthouse'u sayar. Lighthouse INP'yi ölçemez, çünkü ortada kullanıcı girdisi yoktur. Laboratuvarda INP'ye yakın gösterge olarak Total Blocking Time (TBT) kullanılır.

Kendi ölçümünüzü toplamak için web.dev en kolay yol olarak web-vitals JavaScript kütüphanesini gösterir. Ben iki kaynağı birlikte kullanırım: saha verisi sorunun var olup olmadığını, laboratuvar ölçümü nedenini gösterir.

Benim notum

Ben Core Web Vitals'ı üç kullanıcı şikâyetinin sayacı gibi okurum. Raporda zayıf bir LCP görünce önce ilk ekrana bakarım. Kullanıcı orada ilk ne görüyor ve o şey neden geç geliyor?

Audit'lerde en sık gördüğüm kayma kaynağı sonradan gelen bantlardır. Çerez bildirimi ya da kampanya şeridi sayfanın üstüne iner ve her şeyi aşağı iter. Bunları baştan yer ayırarak ya da ekranın altına sabitleyerek göstermek çoğu zaman yeter.

Bu sitede mobil için web.dev'in iyi sınırlarından daha sıkı bir bütçe tutuyorum: 75. yüzdelikte LCP 2 saniyenin, INP 150 milisaniyenin, CLS 0,05'in altında. Sınırın hemen altında durmak, yavaş cihazlarda kolayca üstüne çıkmak demektir.

Hızlı bir sayfa kötü bir akışı kurtarmaz. Form bir saniyede açılır, kullanıcı yine de hata mesajında takılır. Bu yüzden Core Web Vitals'a akış incelemesinin bir parçası olarak bakarım.

E-ticaret UX çalışmalarında ilk baktığım yerler ödeme sayfası ve ürün detay sayfası olur. Bu üç metriği tasarım kararlarıyla birlikte görmek isterseniz UX Audit bunlara da bakar. Sürecin nasıl işlediğini UX audit rehberinde anlattım.