Core Web Vitals Nedir? LCP, INP ve CLS Nasıl Düzeltilir?
Sayfa deneyimi Google için üç sayıya iniyor. Üçünün de ne ölçtüğünü, hangi değerin "iyi" sayıldığını ve nasıl düzeltileceğini sırayla anlatıyoruz.
Core Web Vitals, Google'ın bir sayfanın ziyaretçiye ne kadar hızlı ve stabil göründüğünü ölçen üç sayıdır: LCP, INP ve CLS. Üçü de laboratuvar testinden değil gerçek ziyaretçi verisinden hesaplanır; bir sayfanın bu ölçütleri geçip geçmediği geliştiricinin ekranında değil, ziyaretçilerin telefonunda ve bağlantı hızında belli olur. Bu yazıda üç metriğin ne ölçtüğünü, 2026 itibarıyla geçerli eşik değerlerini ve her birini sırayla nasıl düzelteceğinizi anlatıyoruz.
Üç metrik ne ölçüyor, eşik değerler ne?
Google her metriği ziyaretçilerin 75. yüzdelik dilimine göre değerlendirir — yani bir sayfanın "iyi" sayılması için ziyaretçilerin en az dörtte üçünün o eşiğin altında bir deneyim yaşaması gerekir. Ortalama değil, en yavaş dörtte birin dışında kalan performans esas alınır; bu yüzden tek bir hızlı cihazdan yapılan test yeterli değildir, farklı cihaz ve bağlantı hızlarında ölçüm gerekir.
| Metrik | Ne ölçer | İyi eşik (75. yüzdelik) |
|---|---|---|
| LCP (Largest Contentful Paint) | Sayfadaki en büyük görünür öğenin — genelde kahraman görsel veya ana başlık — ne kadar sürede boyandığı | 2,5 saniyenin altı |
| INP (Interaction to Next Paint) | Ziyaretçinin tıklama, dokunma veya tuş basışından sonra ekranın tepki verme süresi | 200 milisaniyenin altı |
| CLS (Cumulative Layout Shift) | Sayfa yüklenirken öğelerin beklenmedik biçimde kayma miktarı | 0,1 puanın altı |
LCP: en büyük öğe ne kadar sürede görünüyor?
LCP, ziyaretçinin "sayfa yüklendi" hissine ne zaman kavuştuğunu ölçer — teknik olarak sayfa yüklenmeye başladığı andan, görünür alandaki en büyük öğe (çoğunlukla bir kahraman görsel, video kapak karesi ya da büyük bir başlık) tam boyandığı ana kadar geçen süredir. Yavaş bir LCP'nin nedeni neredeyse hep aynı üçlüdür: sunucunun ilk baytı geç göndermesi, sayfayı boyamadan önce tarayıcının beklemek zorunda kaldığı CSS/JS dosyaları ve gereğinden büyük, optimize edilmemiş görseller.
- Sunucu yanıt süresini kısaltın. Statik sayfalarda edge/CDN dağıtımı, dinamik sayfalarda önbellekleme ilk baytı gelme süresini doğrudan düşürür.
- Görseli önceliklendirin. Kahraman görseli `loading="lazy"` yerine öncelikli yükleyin (preload), modern formatlara (WebP/AVIF) ve doğru boyuta indirin.
- Boyamayı engelleyen kaynakları azaltın. Kritik olmayan CSS ve JS dosyalarını ilk boyamadan sonraya erteleyin.
- Yazı tipini erken yükleyin. Web fontu geç gelirse ya metin görünmez ya da yer değiştirerek yeniden çizilir; ikisi de LCP'yi geciktirir.
- CDN ve edge dağıtımı kullanın. Ziyaretçiye coğrafi olarak en yakın sunucudan yanıt vermek, özellikle mobil ve zayıf bağlantıda fark yaratır.
INP: tıklamadan tepkiye kadar geçen süre
INP, Mart 2024'te eski FID (First Input Delay) metriğinin yerini aldı ve ondan daha zorlu bir ölçüttür: FID yalnızca sayfadaki ilk etkileşimi ölçerken, INP sayfanın tüm yaşam döngüsü boyunca her tıklama, dokunma ve tuş basışını izler ve en kötü tepkiyi raporlar. Bir menü açma, bir sepete ekleme veya bir form alanına yazma anında ekranın donması, tek seferlik değil sürekli tekrar eden bir sorundur — bu yüzden INP genelde LCP'den daha zor düzeltilir.
- Uzun JavaScript görevlerini bölün. Ana iş parçacığını 50 milisaniyeden uzun süre bloke eden tek bir işlem, o sırada gelen her tıklamayı geciktirir.
- Üçüncü parti script'leri erteleyin. Canlı destek widget'ı, reklam ve analitik kodları çoğunlukla asıl işlevden önce çalışmak zorunda değildir.
- Gereksiz yeniden render'ları azaltın. React/Next.js tabanlı arayüzlerde durum (state) değişikliklerinin gereğinden geniş bir bileşen ağacını yeniden çizmesi tipik bir INP sorunudur.
- Ağır hesaplamaları arka plana taşıyın. Web Worker kullanmak, ana iş parçacığını etkileşime açık tutar.
CLS: sayfa gözünüzün önünde kayıyor mu?
CLS, sayfa yüklenirken görünür öğelerin beklenmedik biçimde yer değiştirme miktarını toplar — bir görsel geç yüklenip metni aşağı ittiğinde, ya da bir reklam alanı aniden belirdiğinde ziyaretçinin tam tıklamak üzereyken başka bir bağlantıya tıklaması bu yüzdendir. Düşük CLS, çoğu zaman en ucuza düzeltilebilen metriktir çünkü kök neden neredeyse hep aynıdır: tarayıcı bir öğenin nihai boyutunu önceden bilmiyordur.
- Görsel ve videolara `width`/`height` (veya `aspect-ratio`) verin. Tarayıcı, dosya inmeden önce ne kadar yer ayıracağını bilir.
- Dinamik içerik için önceden yer ayırın. Banner, bildirim çubuğu veya kullanıcı onayına bağlı bir blok geç görünecekse, sabit yükseklikli bir kapsayıcı kullanın.
- Web fontlarında `font-display: swap` ile birlikte boyut eşleştirmesi yapın. Yedek yazı tipi ile asıl yazı tipinin satır yüksekliği yakın olmalı.
- Reklam ve gömülü içerik alanlarını sabitleyin. Yükleme öncesi ve sonrası aynı boyutta bir çerçeve kullanmak, en sık görülen CLS kaynağını ortadan kaldırır.
Alan verisi mi, laboratuvar verisi mi?
Google PageSpeed Insights bir URL'yi hem laboratuvar verisiyle (tek bir simüle cihaz ve bağlantıda anlık test) hem de mevcutsa alan verisiyle (CrUX veri kümesindeki gerçek ziyaretçi ölçümleri, son 28 gün) gösterir. Search Console'daki Core Web Vitals raporu yalnızca alan verisine dayanır ve Google'ın sıralamada baktığı da budur. Lighthouse ise sadece laboratuvar verisi üretir — geliştirme sırasında hızlı geri bildirim için değerlidir ama tek başına sitenizin gerçek ziyaretçiler için nasıl performans gösterdiğini söylemez.
Core Web Vitals arama sıralamasını nasıl etkiliyor?
Core Web Vitals, Google'ın "sayfa deneyimi" sinyallerinden biridir ve içerik kalitesi kadar ağırlıklı değildir; zayıf bir Core Web Vitals skoru, güçlü ve alakalı bir içeriği sıralamada geçemez. Asıl etkisi, birbirine yakın kalitede iki sayfa arasında kalındığında ortaya çıkar — bu durumda daha hızlı ve stabil olan öne geçer. Dolaylı etki daha büyüktür: yavaş yüklenen ve kayan bir sayfada ziyaretçi beklemeden ayrılır, bu da hemen çıkma oranını yükseltip dönüşümü doğrudan düşürür.
Ne zaman uzman desteği gerekir?
Görsel sıkıştırma veya font ayarı gibi düzeltmeler tek başına yapılabilir. Ancak sorun render mimarisinden kaynaklanıyorsa — örneğin sunucu tarafında render eksikliği, eklenti yığını veya kontrolsüz üçüncü parti script'ler — kalıcı çözüm mimariyi değiştirmekten geçer. Web ve uygulama geliştirme hizmetimizde Core Web Vitals optimizasyonu teslimin standart bir parçasıdır; teknoloji seçiminin performansa etkisini Next.js mi WordPress mi yazımızda karşılaştırdık. TVN Agency için geliştirdiğimiz kurumsal sitede hız optimizasyonunu nasıl ele aldığımıza buradan bakabilirsiniz.
Sitenizin Core Web Vitals raporunda hangi metrikte takıldığından emin değilseniz, mevcut siteyi birlikte gözden geçirelim — kısa bir görüşme talep edin.
Sık sorulan sorular
INP eşiği FID'den farklı mı?
Evet. INP, Mart 2024'te FID'in yerini aldı ve sayfadaki tüm etkileşimleri (yalnızca ilkini değil) izleyip en kötüsünü raporlar; bu yüzden FID'de geçen bir sayfa INP'de düşük kalabilir.
Core Web Vitals'ımı hangi araçla kontrol edebilirim?
Google PageSpeed Insights'a URL'nizi yapıştırmak hem laboratuvar hem (mevcutsa) alan verisini gösterir. Site sahipleri için asıl referans, Search Console'daki Core Web Vitals raporudur; bu rapor gerçek ziyaretçi verisine dayanır ve Google'ın sıralamada baktığı veridir.
CLS neden mobilde daha kötü çıkıyor?
Mobil cihazlarda ekran daha küçük olduğu için aynı piksel kayması görsel olarak daha büyük bir orana denk gelir; ayrıca mobil bağlantılar görselleri ve reklamları daha geç indirdiğinden geç beliren öğelerin kayma ihtimali artar.