Core Web Vitals 2026: LCP, INP ve CLS eşikleri ne anlama geliyor?

Bir web sitesinin “hızlı” olup olmadığını konuşurken herkes farklı bir şeyi kastediyor: sunucunun yanıt süresi, sayfanın tamamen yüklenme süresi, bir butona dokununca ne olduğu. Google bu tartışmayı üç ölçülebilir metriğe indirgedi ve 2026'da hâlâ bu üç metrik geçerli: LCP, INP ve CLS. Bu yazıda eşiklerin ne anlama geldiğini ve küçük bir kurumsal sitede onları tutturmak için hangi kararların gerçekten fark yarattığını anlatıyoruz.

Üç metrik, üç soru

Her metrik, ziyaretçinin sorduğu basit bir soruya karşılık gelir.

• LCP (Largest Contentful Paint): “İçerik ne zaman geldi?” Ekrandaki en büyük içerik parçasının (çoğu zaman bir kapak görseli ya da başlık) görünür olduğu an.
• INP (Interaction to Next Paint): “Dokunduğumda tepki veriyor mu?” Sayfayla yapılan etkileşimlerin, bir sonraki ekran çiziminde ne kadar gecikmeyle karşılık bulduğu. Mart 2024'ten bu yana FID'in yerini alan metrik budur.
• CLS (Cumulative Layout Shift): “Okurken içerik yer değiştiriyor mu?” Yükleme sırasında beklenmedik biçimde kayan öğelerin toplam etkisi.

Eşik değerleri

Google'ın kendi belgelerinde (web.dev) yayımlanan eşikler şöyle:

Kaynak: Defining the Core Web Vitals metrics thresholds, web.dev.

Yüzde 75 kuralı

Bu eşikler tek bir ölçüme değil, gerçek ziyaretçi verisinin 75. yüzdelik dilimine uygulanır. Yani bir sayfa, ziyaretlerinin en az yüzde 75'inde “iyi” eşiğini tutturuyorsa iyi sayılır. Google bu yaklaşımı iki nedenle seçtiğini yazıyor: ziyaretlerin çoğunluğunun hedef deneyimi yaşamasını garanti etmek ve aynı zamanda uç değerlerin (çok yavaş bir bağlantı, çok eski bir telefon) sonucu tek başına belirlemesini engellemek. Laboratuvar ölçümleri (Lighthouse gibi) yol gösterir; karar ise gerçek kullanıcı verisine göre verilir.

Küçük bir sitede neler fark yaratır?

Kurumsal bir sitenin performans sorunları genellikle birkaç tanıdık yerden çıkar. Aşağıdakiler, bizim projelerde yayına almadan önce kontrol ettiğimiz maddeler.

LCP için

• Kapak görselini doğru boyutta ve modern bir formatta (WebP ya da AVIF) sunun; 2000 piksellik bir görseli 800 piksellik bir alanda göstermeyin.
• Sayfanın en büyük görselini loading="lazy" ile geciktirmeyin; tam tersine yüksek öncelik verin.
• Yazı tiplerini kendi sunucunuzdan, yalnızca gereken alt kümelerle yükleyin ve font-display: swap kullanın.
• Sunucu yanıt süresini ölçün: önbellekleme ve doğru kurulmuş bir PHP-FPM, çoğu zaman en büyük kazancı verir.

INP için

• Ana iş parçacığını meşgul eden üçüncü taraf betikleri (sohbet balonları, izleme kodları, sosyal medya gömüleri) sorgulayın; her biri kaç milisaniye maliyet getiriyor?
• Menü, akordeon ve sekme gibi etkileşimleri mümkün olduğunca tarayıcının kendi öğeleriyle (details, dialog) kurun; JavaScript yalnızca eksiği tamamlasın.
• Kaydırma olaylarını dinleyen kod yerine IntersectionObserver kullanın.

CLS için

• Her görsele ve gömülü içeriğe width ve height verin; tarayıcı alanı önceden ayırsın.
• Sayfanın üstüne sonradan giren bildirim çubukları, çerez uyarıları ve reklam alanlarından kaçının ya da onlara baştan yer ayırın.
• Yazı tipi değişiminde satır yüksekliğinin sıçramasını önlemek için yedek yazı tipini gerçek yazı tipine yakın seçin.

Ölçmeden karar vermeyin

Her iyileştirme kararı bir ölçümle başlamalı. Search Console'daki Core Web Vitals raporu gerçek kullanıcı verisini, Lighthouse ve PageSpeed Insights ise laboratuvar verisini gösterir. Bir sayfa laboratuvarda iyi görünüp gerçek kullanıcıda kötü çıkıyorsa, sorun genellikle üçüncü taraf betiklerde ya da mobil cihazların işlem gücünde gizlidir.

Kendi sitenizin bu eşiklerin neresinde olduğunu merak ediyorsanız, web geliştirme hizmetimizde yaklaşımımızı anlattık; ölçmek için bize yazabilirsiniz.