Core Web Vitals Nedir: LCP, INP ve CLS

Search Console'da bir sabah "Core Web Vitals" raporunu açıp sayfalarınızın çoğunun kırmızı ya da turuncu kutuya düştüğünü görmek can sıkıcıdır; özellikle site sizin gözünüzde gayet hızlı açılıyorsa. Buradaki asıl sorun, sizin ofis internetinizle ve son model bilgisayarınızla ölçtüğünüz hız ile Google'ın gerçek ziyaretçilerden topladığı verinin aynı şey olmamasıdır. Core Web Vitals, tam olarak bu ikinci veriyi, yani gerçek kullanıcıların yaşadığı deneyimi üç somut sayıya indirger: LCP, INP ve CLS.

Bu rehberde bu üç metriğin her birinin fiziksel olarak neyi ölçtüğünü, hangi eşik değerlerin "iyi" sayıldığını, Google'ın neden ortalamayı değil 75. yüzdelik dilimi kullandığını ve kendi sitenizde bu değerleri nasıl ölçüp yorumlayacağınızı anlatacağım. Ayrıca sahada en çok gördüğüm yanlış anlamaları da tek tek açacağım — çünkü Core Web Vitals ile ilgili yapılan hataların çoğu teknik yetersizlikten değil, metriğin ne ölçtüğünü yanlış bilmekten kaynaklanıyor.

Core Web Vitals Tam Olarak Neyi Ölçer#

Google, uzun yıllar boyunca "sayfa hızı" dediğimiz şeyi yükleme süresi (load time) üzerinden değerlendirdi. Ama bir sayfanın load olayının tetiklenmesi, kullanıcının o sayfayı kullanabildiği anlamına gelmiyor. Reklam kodları hâlâ inmeye devam ederken load çoktan tetiklenmiş olabilir; ya da tam tersi, kullanıcı içeriği okumaya başlamışken arka planda bir analitik betiği yüzünden load gecikebilir. Core Web Vitals bu yüzden "sayfa ne zaman bitti" sorusunu bırakıp üç ayrı kullanıcı deneyimi sorusunu sorar: içerik ne zaman göründü, tıkladığımda ne zaman cevap verdi ve okurken sayfa ayağımın altından kaydı mı.

Üç metriğin de resmi eşik değerleri vardır ve bu eşikler "iyi", "iyileştirme gerekli", "kötü" olmak üzere üç bölgeye ayrılır. Bir sayfanın Core Web Vitals değerlendirmesini geçmesi için her üç metriğin de iyi bölgede olması gerekir; ikisi mükemmel biri kötüyse sayfa geçemez.

Dikkat edilmesi gereken nokta, bu üç metriğin birbirinin yerine geçmemesidir. LCP sunucu ve ağ tarafını, INP tarayıcıdaki JavaScript yükünü, CLS ise düzen ve stil disiplinini yansıtır. Yani LCP'si kötü bir site genelde hosting veya varlık optimizasyonu sorunu yaşıyordur; INP'si kötü bir sitede ise sorun neredeyse her zaman ana iş parçacığını (main thread) tıkayan JavaScript'tir. Doğru teşhis için hangi metriğin hangi katmana işaret ettiğini bilmek, çözüm süresini saatlerden dakikalara indirir.

LCP: Sayfanın Ana İçeriği Ne Zaman Görünür#

LCP (Largest Contentful Paint), görünür alandaki en büyük içerik öğesinin ekrana çizilme anını ölçer. "En büyük içerik öğesi" dediğimiz şey genellikle hero görseli, ürün fotoğrafı veya büyük bir başlık bloğudur. Tarayıcı sayfa yüklenirken bu adayı sürekli günceller; kullanıcı ilk etkileşimi yapana kadar en büyük olan hangisiyse LCP odur. Yani LCP, "kullanıcı bu sayfaya baktığında artık bir şey okuyabiliyor mu" sorusunun sayısal karşılığıdır.

LCP'nin kötü olmasının pratikte dört ana sebebi vardır: yavaş sunucu cevap süresi (TTFB), render'ı bloke eden CSS/JS, geç keşfedilen veya ağır görseller ve istemci tarafında geç çalışan bir çerçeve. Bunlardan hangisinin baskın olduğunu anlamanın en hızlı yolu, LCP'yi alt kırılımlarına ayırmaktır. Tarayıcıda şu kısa betikle LCP adayını ve zamanını doğrudan görebilirsiniz:

// Konsola yapıştırın, sayfayı yenileyin, LCP adayı ve süresi yazılsın
new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log("LCP:", Math.round(last.startTime), "ms", last.element);
}).observe({ type: "largest-contentful-paint", buffered: true });

Çıktıda size hem milisaniye cinsinden süre hem de hangi DOM öğesinin LCP olarak seçildiği gelir. Burada sık karşılaşılan sürpriz, LCP'nin beklediğiniz hero görseli değil, ekranın altında kalan devasa bir metin bloğu ya da bir çerez bildirim çubuğu olmasıdır. Öyleyse önce doğru öğeyi bulun, sonra optimize edin. LCP'ye özel derinlemesine teknikler ve kritik yol optimizasyonu için LCP nasıl iyileştirilir yazısına göz atın.

INP: Tıklamaya Kaç Milisaniyede Cevap Veriyorsunuz#

INP (Interaction to Next Paint), 2024 yılında FID'in (First Input Delay) yerini alan yanıt verebilirlik metriğidir ve iki metrik arasındaki fark çok önemlidir. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu ve etkileşimin sonucunun ekrana yansımasını hiç dikkate almıyordu. INP ise sayfa ömrü boyunca yapılan tüm tıklama, dokunma ve klavye etkileşimlerine bakar, her birinin girdi gecikmesi + işleme süresi + sonraki boyamaya kadar geçen süresini toplar ve bunlardan (etkileşim sayısına göre) en kötüye yakın olanı raporlar.

Bu değişiklik, gerçek dünyada birçok sitenin puanını sertçe düşürdü. Çünkü bir site açılışta hafif olabilir ama menü açma, filtre uygulama, sepete ekleme gibi etkileşimlerde ağır JavaScript çalıştırıyorsa INP kötüleşir. Aşağıdaki tablo, bir etkileşimin INP'ye katkısının üç bileşenini gösterir:

Pratikte en çok fayda getiren müdahale, olay dinleyicisi içindeki işi acil olan ve olmayan diye ikiye ayırmaktır. Kullanıcının hemen görmesi gereken kısmı (butonun basılı durumu, menünün açılması) hemen yapın; analitik gönderimi, ağır hesaplama gibi işleri sonraki kareye erteleyin. Detaylı teknikler ve ölçüm yöntemleri için INP nedir, nasıl iyileştirilir yazısına bakabilirsiniz.

CLS: Sayfa Okurken Gözünüzün Önünde Kayıyor mu#

CLS (Cumulative Layout Shift), sayfa yüklenirken görünür alandaki öğelerin beklenmedik şekilde yer değiştirmesini ölçer. Bunu somutlaştırayım: bir haber sitesinde makaleyi okumaya başlıyorsunuz, üstteki reklam alanı yükleniyor ve metin bir anda aşağı kayıyor; ya da bir "Kabul et" butonuna basmak üzereyken geç yüklenen bir görsel butonu iki santim aşağı itiyor ve yanlış yere tıklıyorsunuz. CLS puanı, kayan alanın ekrana oranı ile kayma mesafesinin oranının çarpımından oluşur ve oturum boyunca en kötü 5 saniyelik pencerede toplanır.

CLS'nin en güzel tarafı, çözümünün genelde ucuz ve kalıcı olmasıdır. Kaymanın büyük çoğunluğu, tarayıcıya "bu alanın boyutu ne olacak" bilgisini önceden vermemekten kaynaklanır. Görsellere width ve height özniteliklerini yazmak, gömülü iframe'lere sabit yükseklik vermek ve reklam yuvalarına en az yükseklik tanımlamak sorunun büyük bölümünü kapatır:

/* Görsel yüklenene kadar alanın çökmesini engelle */
.hero-img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

/* Reklam yuvasına rezerve alan ayır */
.ad-slot {
  min-height: 280px;
  contain: layout;
}

Bir başka gizli CLS kaynağı, web fontlarının geç yüklenmesiyle oluşan metin sıçramasıdır. font-display: optional veya swap kullanımı ile size-adjust ayarını birlikte kullanmak bu sıçramayı ciddi ölçüde azaltır. Bu konudaki tüm senaryolar ve düzeltmeler CLS düzen kayması nasıl düzeltilir yazısında ayrıntılı biçimde ele alınıyor.

75. Yüzdelik Kuralı ve 28 Günlük Pencere#

Google, Core Web Vitals değerlendirmesinde ortalama değil 75. yüzdelik dilimi kullanır. Yani ziyaretçilerinizin en hızlı %75'inin altında kaldığı değer sizin skorunuzdur. Bu tercih tesadüf değil: ortalama, bir avuç çok hızlı ziyaretçi sayesinde kötü bir deneyimi kolayca gizler. 75. yüzdelik ise "kullanıcıların dörtte üçü en az bu kadar iyi bir deneyim yaşıyor mu" sorusunu sorar ve gerçeğe çok daha yakın bir cevap verir.

İkinci önemli ayrıntı, verinin 28 günlük kayan pencere üzerinden hesaplanmasıdır. Bugün bir düzeltme yayınlarsanız, Search Console'daki grafiğin tam olarak toparlanması dört haftayı bulur; ilk hareketi genelde bir hafta içinde görürsünüz ama sabırsız olup üst üste değişiklik yaparsanız hangi düzeltmenin işe yaradığını anlayamaz hale gelirsiniz. Benim önerim şu sıralamadır:

1. Değişikliği yayınlayın ve tarihi bir yere not edin.
2. Aynı gün lab ölçümü (Lighthouse) alın; iyileşme lab'da görünmüyorsa alanda da görünmez.
3. 7 gün sonra CrUX/Search Console verisine bakın; eğilimin yönünü kontrol edin.
4. 28 gün dolmadan ikinci büyük bir performans değişikliği yapmayın.
5. Mobil ve masaüstünü ayrı ayrı takip edin; genelde yalnızca mobil kırmızıdır.

Alan verisi ile lab verisi arasındaki bu ayrım o kadar kritiktir ki, ayrı bir yazının konusu: CrUX alan verisi ve lab verisi farkı yazısında iki veri türünün neden farklı sonuç verdiğini ve hangisine ne zaman güveneceğinizi bulabilirsiniz.

Kendi Sitenizde Nasıl Ölçersiniz#

Ölçüm için elinizde birden fazla araç var ve her biri farklı soruya cevap veriyor. En sık kullanacağınız üçlü şudur: PageSpeed Insights (hem alan hem lab verisini yan yana verir), Lighthouse (tarayıcıda çalışan lab testi) ve web-vitals kütüphanesi (kendi kullanıcılarınızdan gerçek veri toplar). Aşağıdaki tablo hangi durumda hangisine bakacağınızı özetler:

Kendi ölçümünüzü kurmak istiyorsanız Google'ın resmi web-vitals kütüphanesi birkaç satırda çalışır. Metrikleri kendi toplama uç noktanıza gönderip zaman içindeki eğilimi izleyebilirsiniz:

import { onLCP, onINP, onCLS } from "web-vitals";

function gonder(metric) {
  // Sayfa kapanırken bile kaybolmayan gönderim
  navigator.sendBeacon(
    "/api/vitals",
    JSON.stringify({ ad: metric.name, deger: metric.value, id: metric.id })
  );
}

onLCP(gonder);
onINP(gonder);
onCLS(gonder);

Sunucu tarafındaki temeli de ihmal etmeyin: LCP'nin ilk bileşeni TTFB'dir ve TTFB'yi düşürmenin en doğrudan yolu hızlı bir barındırma altyapısıdır. NVMe diskli ve LiteSpeed'li paketlerimizle çalışan web hosting veya kaynakların tamamen size ait olduğu VDS sunucu çözümleri, uygulama tarafında hiçbir şey değiştirmeden LCP'nin ilk yarım saniyesini geri kazandırabilir.

Sık Yapılan Hatalar ve Tuzaklar#

En sık gördüğüm hata, Lighthouse performans skorunu (0-100) Core Web Vitals ile eşitlemektir. Bunlar farklı şeylerdir. Lighthouse skoru ağırlıklandırılmış bir lab puanıdır ve INP'yi hiç ölçmez; Core Web Vitals ise gerçek kullanıcı verisidir. 100/100 alan bir sitenin CrUX'te kırmızı olması gayet mümkündür, tersi de doğrudur. Kararlarınızı alan verisine göre verin, lab verisini yalnızca "değişiklik doğru yönde mi" kontrolü için kullanın.

İkinci klasik hata, tek bir URL'ye bakıp tüm site hakkında hüküm vermektir. Search Console raporu URL'leri gruplar ama ana sayfa ile bir ürün detay sayfasının performans profili birbirine hiç benzemez. Ürün listeleme sayfanız 40 görsel yüklüyorsa oradaki LCP ana sayfanınkiyle aynı olmaz. Şablon başına en az bir temsilci URL seçip her birini ayrı ölçün.

Üçüncüsü, eklenti ile çözme refleksi. Bir önbellek eklentisi kurup "tamam, hızlandı" demek çoğu zaman LCP'yi bir miktar iyileştirir ama INP'ye hiç dokunmaz, hatta ek JavaScript yüzünden kötüleştirebilir. Önbellekleme sunucu cevabını hızlandırır; ana iş parçacığındaki JavaScript yükünü azaltmaz. İkisi ayrı problemlerdir ve ayrı çözülür.

Dördüncüsü, mobil ile masaüstünü karıştırmak. Core Web Vitals mobil ve masaüstü için ayrı raporlanır ve mobil neredeyse her zaman daha kötüdür; çünkü CPU daha yavaş, ağ daha değişkendir. Masaüstünde yeşil görüp rahatlamayın, kararlarınızı mobil verisine göre verin. Son olarak, CDN'in her şeyi çözeceğini varsaymak da yaygın bir yanılgıdır; CDN varlık dağıtımını hızlandırır ama HTML dinamikse ve uygulama yavaşsa TTFB yerinde sayar. Bu ayrımı CDN mi daha iyi hosting mi yazısında ayrıntısıyla tartıştık.

Sıkça Sorulan Sorular#

Core Web Vitals SEO sıralamasını gerçekten etkiler mi#

Evet, ancak etkinin büyüklüğünü abartmamak gerekir. Core Web Vitals, Google'ın sayfa deneyimi sinyalleri arasında yer alır ve özellikle içerik kalitesi bakımından birbirine yakın iki sayfa arasında ayırt edici olur. İçeriğiniz rakiplerinizden zayıfsa mükemmel bir LCP tek başına sizi yukarı taşımaz. Buna karşılık kötü bir CLS ya da 5 saniyelik bir LCP, dönüşüm oranınızı sıralamadan bağımsız olarak düşürür; yani düzeltmenin karşılığını yalnızca SEO'da değil doğrudan gelirde alırsınız.

Core Web Vitals ölçümü ücretsiz mi#

Evet. PageSpeed Insights, Search Console'daki Core Web Vitals raporu, Chrome DevTools içindeki Lighthouse ve CrUX veri seti tamamen ücretsizdir. Google'ın web-vitals JavaScript kütüphanesi de açık kaynaktır; kendi kullanıcılarınızdan gerçek veri toplamak istediğinizde tek maliyetiniz bu verileri saklayacağınız uç nokta olur. Ücretli araçlar genellikle daha uzun geçmiş, uyarı mekanizmaları ve karşılaştırmalı raporlama sunar; başlangıç için ücretsiz araçlar fazlasıyla yeterlidir.

Düzeltmelerimin Search Console'a yansıması ne kadar sürer#

CrUX verisi 28 günlük kayan pencere üzerinden hesaplandığı için tam yansıma dört haftayı bulur. İlk kıpırdanmayı genelde 7-10 gün içinde görürsünüz; grafiğin tamamen yeni seviyeye oturması ise 28 günü tamamlar. Bu süre boyunca sabırlı olun ve arka arkaya büyük değişiklikler yapmaktan kaçının; aksi halde hangi müdahalenin işe yaradığını ayırt edemezsiniz. Hızlı geri bildirim istiyorsanız aynı değişikliği lab ortamında Lighthouse ile ölçün.

FID neden kaldırıldı, INP yerine ne değişti#

FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; etkileşimin sonucunun ekrana yansıması hiç hesaba katılmıyordu. Bu yüzden pek çok site FID'de mükemmel görünürken kullanıcılar gerçekte takılma yaşıyordu. INP ise sayfa ömrü boyunca yapılan tüm etkileşimleri kapsar ve girdi gecikmesi, işleme süresi ile boyama gecikmesini birlikte ölçer. Sonuç olarak INP, gerçek yanıt verebilirliği FID'den çok daha dürüst yansıtır ve bu yüzden birçok sitede skor düşmüştür.

Her üç metrik de iyi olmak zorunda mı#

Evet. Bir URL'nin Core Web Vitals değerlendirmesini geçmesi için LCP, INP ve CLS'nin üçünün de kendi iyi eşiğinin altında olması gerekir. İki metriğiniz mükemmel, biriniz kötüyse sayfa "iyileştirme gerekli" ya da "kötü" grubunda kalır. Bu yüzden önceliklendirme yaparken en kötü durumdaki metriği hedefleyin; zaten iyi olan bir metriği daha da iyileştirmek değerlendirme açısından size ek puan getirmez.

Düşük trafikli sitemde alan verisi neden görünmüyor#

CrUX veri seti, istatistiksel olarak anlamlı sayıda gerçek Chrome kullanıcısı örneği toplayamadığı URL'ler için veri yayımlamaz. Bu yüzden yeni açılmış veya günlük birkaç yüz ziyaretçinin altındaki sitelerde PageSpeed Insights yalnızca lab verisi gösterir. Bu durumda iki seçeneğiniz var: origin (alan adı) düzeyindeki toplu veriye bakmak ya da web-vitals kütüphanesiyle kendi gerçek kullanıcı ölçümünüzü kurmak. İkincisi düşük trafikte bile çalışır çünkü örnekleme sizin elinizdedir.

Kapanış#

Core Web Vitals'ı bir "Google puanı" olarak değil, üç ayrı mühendislik sorusu olarak düşünürseniz iş çok kolaylaşır: içerik yeterince erken görünüyor mu (LCP), tıklamaya hızlı cevap veriliyor mu (INP), sayfa okunurken kaymıyor mu (CLS). Aklınızda kalması gereken dört alışkanlık şunlar: kararları alan verisine göre verin, lab verisini yalnızca doğrulama için kullanın; şablon başına ayrı ölçün, tek URL'den genelleme yapmayın; her seferinde tek bir değişiklik yayınlayıp 7-28 gün bekleyin; ve mobil veriyi ana referans alın.

Bu üçlüden LCP ve TTFB tarafı büyük ölçüde altyapıyla ilgilidir ve doğru barındırma seçimi işin yarısını çözer. Sunucu cevap süresini düşürmek için NVMe ve LiteSpeed tabanlı web hosting ya da WordPress için özelleştirilmiş WordPress hosting paketlerimize bakabilir, kaynak paylaşımı olmayan bir ortam istiyorsanız VDS sunucu tarafına geçebilirsiniz. Ölçüm ve düzeltme işini tamamen bize bırakmak isterseniz sunucu yönetimi hizmetimiz performans ayarlarını da kapsıyor; kendi ölçümünüzü yapmak için ise ücretsiz araçlar sayfamızdaki hesaplayıcılar iyi bir başlangıç noktası.