Ziyaretçi sitenize geldi, ama sayfa açılmadı, butona bastı ama tepki gelmedi, okumaya başladı ve metin aşağı kaydı. Bu üç küçük hayal kırıklığının her birinin Google’da bir adı var: Core Web Vitals. Site hızını ölçmenin ve iyileştirmenin en net yolu da bu üç metrikten geçiyor.
Bu yazıda Core Web Vitals’ın ne olduğunu, LCP, INP ve CLS metriklerinin güncel “iyi” eşiklerini, bu değerleri hangi araçlarla ve nasıl doğru ölçeceğinizi ve her biri için en çok fark yaratan iyileştirmeleri anlatıyoruz.
Teknik ekibiniz olmasa bile yazının sonunda sitenizin durumunu kendiniz kontrol edebilecek ve ajansınıza ya da yazılımcınıza doğru soruları sorabileceksiniz.
Site hızı neden hem müşteri hem SEO meselesi?
Yavaş bir site önce kullanıcıyı kaybettirir. Mobil bağlantıda birkaç saniye boş ekrana bakan ziyaretçi, aramaya geri dönüp bir sonraki sonuca tıklar. Bu, reklamla getirdiğiniz trafikte doğrudan para kaybı demektir.
Google tarafında ise Core Web Vitals, “sayfa deneyimi” kapsamında sıralama sistemlerinin dikkate aldığı sinyaller arasında yer alıyor. Google Search Central bunu açıkça ifade ediyor; ancak aynı belgede, içeriğin alaka düzeyinin hâlâ çok daha belirleyici olduğu da vurgulanıyor. Yani hızlı ama içeriği zayıf bir sayfa üst sıralara çıkmaz; benzer kalitede iki sayfa arasında ise deneyim fark yaratabilir.
Hız tek başına sizi birinci yapmaz, ama yavaşlık sizi kolayca geride bırakır.
Core Web Vitals metrikleri ve 2026 eşik değerleri
Core Web Vitals üç metrikten oluşur. Her biri kullanıcı deneyiminin farklı bir yönünü ölçer: yükleme, etkileşim ve görsel kararlılık.
| Metrik | Neyi ölçer? | İyi | İyileştirilmeli | Zayıf |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Sayfadaki en büyük görsel ya da metin bloğunun ekranda belirme süresi | ≤ 2,5 sn | 2,5–4 sn | > 4 sn |
| INP (Interaction to Next Paint) | Tıklama, dokunma ve tuş vuruşlarına sayfanın görsel tepki verme süresi | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Sayfa açılırken ve kullanılırken öğelerin beklenmedik kayması | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Önemli bir ayrıntı: Google bu değerleri gerçek kullanıcıların 75. yüzdelik dilimine göre değerlendirir. Yani ziyaretlerin en az yüzde 75’i “iyi” eşiğin içinde kalmalıdır. Bir sayfanın Core Web Vitals’ı geçmesi için üç metriğin de iyi olması gerekir; biri zayıfsa ortalama alınmaz.
Core Web Vitals nasıl ölçülür: saha verisi ve laboratuvar verisi
Ölçümde en sık yapılan hata, tek bir PageSpeed puanına bakıp karar vermektir. İki tür veri vardır ve ikisi farklı şey söyler:
- Saha verisi (field data): Chrome kullanıcılarının gerçek deneyimlerinden toplanan Chrome UX Report (CrUX) verisidir. Google’ın sıralamada dikkate aldığı veri budur ve son 28 günün ortalamasını yansıtır.
- Laboratuvar verisi (lab data): Lighthouse’un tek bir simüle cihaz ve bağlantıda yaptığı testtir. Sorunları teşhis etmek için idealdir, ancak gerçek kullanıcı deneyimini birebir göstermez. INP’yi doğrudan ölçemez; yerine Total Blocking Time (TBT) değerine bakılır.
Hangi aracı ne için kullanmalı?
- PageSpeed Insights: Tek bir adres için hem saha hem laboratuvar verisini birlikte gösterir. Üstteki “gerçek kullanıcı deneyimi” bölümünü esas alın.
- Search Console — Core Web Vitals raporu: Tüm sitenizi benzer sayfa gruplarına ayırarak mobil ve masaüstü için hangi URL’lerin zayıf olduğunu gösterir.
- Chrome DevTools (Performance paneli): Yavaş etkileşimlerin ve kaymaların nedenini satır satır bulmak için geliştiricilerin aracıdır.
- web-vitals kütüphanesi: Kendi analitik aracınıza gerçek kullanıcı ölçümü göndermek için Google’ın küçük JavaScript kütüphanesidir.
LCP nasıl iyileştirilir: ana içeriği daha hızlı gösterin
Çoğu kurumsal sitede LCP öğesi, sayfanın üst kısmındaki büyük görsel (hero) ya da ana başlıktır. LCP süresi dört parçadan oluşur: sunucunun ilk yanıtı (TTFB), kaynağın keşfedilmesi, kaynağın indirilmesi ve ekrana çizilmesi. İyileştirme de bu sırayla yapılır.
- Sunucu yanıtını hızlandırın: web.dev, TTFB için 0,8 saniye ve altını iyi kabul ediyor. Sayfa önbelleği, kaliteli barındırma ve CDN bu süreyi belirgin şekilde düşürür.
- LCP görselini erken keşfettirin: Görseli CSS arka planı veya JavaScript ile değil, HTML içinde doğrudan verin; fetchpriority="high" ile önceliklendirin.
- Üst kısımdaki görsele lazy loading uygulamayın: Tembel yükleme ekranın altındaki görseller içindir; ana görselde LCP’yi geciktirir.
- Görseli küçültün: WebP veya AVIF biçimi, doğru boyut ve srcset ile mobilde gereksiz büyük dosya indirilmesini önleyin.
- Render’ı engelleyen kaynakları azaltın: Kritik CSS’i öne alın, kullanılmayan CSS ve senkron yüklenen betikleri temizleyin, yazı tiplerinde font-display: swap kullanın.
Barındırma tarafındaki kararların hıza etkisini alan adı ve hosting seçimi yazımızda ayrıca ele aldık.
INP nasıl iyileştirilir: tıklamalara anında tepki verin
INP sorunu genellikle tarayıcının ana iş parçacığının (main thread) JavaScript ile meşgul olmasından kaynaklanır. Kullanıcı menüye dokunur, ama tarayıcı o anda bir analitik betiğini ya da büyük bir slider kodunu çalıştırdığı için tepki gecikir.
- Uzun görevleri bölün: 50 ms’yi aşan JavaScript görevlerini parçalara ayırın; kullanıcıya görsel geri bildirimi önce verin, ağır işi sonra yapın.
- Üçüncü taraf betikleri gözden geçirin: Sohbet balonları, ısı haritası araçları, birden fazla reklam ve analitik etiketi INP’nin en yaygın suçlularıdır. Gerçekten kullandıklarınızı bırakın, diğerlerini geciktirerek yükleyin.
- DOM’u küçük tutun: Binlerce öğe içeren sayfalarda her etkileşim sonrası yeniden çizim pahalılaşır.
- Eklenti ve tema yükünü azaltın: Hazır temaların her sayfada yüklediği kullanılmayan kodlar, özellikle düşük donanımlı telefonlarda etkileşimi yavaşlatır.
Bu noktada altyapı seçimi belirleyici olur. Eklentiyle büyüyen bir site ile ihtiyaca göre yazılmış hafif bir site arasındaki farkı WordPress mi özel yazılım mı yazımızda karşılaştırdık.
CLS nasıl iyileştirilir: sayfanın kaymasını önleyin
Okuduğunuz satırın aniden aşağı kayması ya da tam tıklayacakken butonun yer değiştirmesi, CLS’nin ölçtüğü şeydir. Neyse ki çözümleri genellikle basittir:
- Görsellere ve videolara boyut verin: width ve height öznitelikleri ya da CSS aspect-ratio ile tarayıcı yeri önceden ayırır.
- Reklam, banner ve gömülü içeriklere sabit alan ayırın: Sonradan yüklenen çerez bildirimi veya kampanya şeridi içeriği itmesin; üstte kaplama (overlay) olarak açılsın.
- Yazı tipi değişimini yumuşatın: Web fontunu önceden yükleyin ve yedek fontun ölçülerini ona yakın tutun.
- Animasyonlarda transform kullanın: top, left, height gibi düzeni etkileyen özellikler yerine transform ve opacity ile animasyon yapın.
Site türüne göre en sık görülen hız sorunları
Her site aynı nedenle yavaşlamaz. Projelerde karşılaştığımız tabloyu site türüne göre özetlersek:
| Site türü | En sık sorun | İlk bakılacak yer |
|---|---|---|
| Hazır temalı kurumsal site | Ağır tema, çok sayıda eklenti, büyük slider görselleri | Kullanılmayan eklentiler, ana görselin boyutu, sayfa önbelleği |
| E-ticaret sitesi | Ürün görselleri, filtreler, çok sayıda takip ve pazarlama etiketi | Kategori sayfası LCP’si, üçüncü taraf betikler, sepet etkileşimlerinin INP’si |
| Tek sayfa uygulaması (React, Vue vb.) | Büyük JavaScript paketleri, içeriğin tarayıcıda geç oluşması | Sunucu tarafı render veya ön render, kod bölme |
| Haber ve blog sitesi | Reklam alanlarının sonradan yüklenip içeriği kaydırması | Reklam yuvaları için ayrılmış sabit alanlar, CLS |
Bu tablo bir başlangıç noktasıdır; kesin teşhis her zaman ölçümle yapılır. Yine de sorunun büyük ihtimalle nerede olduğunu bilmek, geliştiriciyle konuşurken zaman kazandırır. Örneğin bir e-ticaret sitesinde ürün detay sayfası hızlı olduğu halde kategori sayfası yavaşsa, sorun çoğu zaman listelenen onlarca görselin aynı anda ve tam boyutta indirilmesidir.
Mobil uygulama gibi hissettiren, hızlı ve hafif bir deneyim hedefliyorsanız, bunu tasarım aşamasında konuşmak gerekir. Sayfaya sonradan eklenen her “küçük” özellik, hız bütçesinden pay alır.
Site hızını artırmak için adım adım plan
Her şeyi aynı anda düzeltmeye çalışmak yerine, etkisi en büyük olandan başlayın:
- 1. Adım — Search Console’da Core Web Vitals raporunu açın, mobilde “zayıf” olan sayfa gruplarını listeleyin.
- 2. Adım — Her gruptan örnek bir adresi PageSpeed Insights’ta test edin, hangi metriğin takıldığını not edin.
- 3. Adım — Önce şablon düzeyindeki sorunları çözün: aynı şablonu kullanan yüzlerce sayfa tek düzeltmeyle iyileşir.
- 4. Adım — Görseller, önbellek ve CDN gibi hızlı kazanımları uygulayın; ardından JavaScript ve üçüncü taraf betiklere geçin.
- 5. Adım — Search Console’da “düzeltmeyi doğrula” deyin ve saha verisinin 28 gün içinde güncellenmesini bekleyin.
Hız, bir kerelik bir proje değil, sürekli korunması gereken bir bütçedir. Yeni bir eklenti, büyük bir görsel ya da ek bir takip kodu kazanımları birkaç hafta içinde geri alabilir. Bu yüzden her yeni özellik eklenmeden önce “bu, sayfayı ne kadar yavaşlatır?” sorusunu sorun. Hızın arama görünürlüğündeki yerini daha geniş çerçevede görmek isterseniz teknik SEO kontrol listemize de göz atabilirsiniz.
- Mobilde LCP 2,5 saniyenin altında mı?
- INP 200 ms’nin altında, gereksiz üçüncü taraf betikler temizlendi mi?
- CLS 0,1’in altında, tüm görsellerde boyut tanımlı mı?
- Ana görsel lazy loading olmadan ve öncelikli yükleniyor mu?
- Görseller WebP/AVIF ve doğru boyutta mı?
- Sayfa önbelleği, sıkıştırma ve CDN etkin mi?
- Search Console Core Web Vitals raporu düzenli izleniyor mu?
Sık sorulan sorular
Core Web Vitals nedir?
Core Web Vitals, Google’ın gerçek kullanıcı deneyimini ölçmek için belirlediği üç metriktir: yükleme hızı için LCP, etkileşime tepki için INP ve görsel kararlılık için CLS. Bu metrikler Google’ın sayfa deneyimi değerlendirmesinde kullanılır.
İyi bir LCP değeri kaç saniyedir?
Google’a göre LCP 2,5 saniye veya altındaysa iyi, 4 saniyenin üzerindeyse zayıf kabul edilir. Değerlendirme, gerçek kullanıcı ziyaretlerinin 75. yüzdelik dilimine göre yapılır.
INP neden FID’nin yerini aldı?
FID yalnızca sayfadaki ilk etkileşimin gecikmesini ölçüyordu ve çoğu site bu testi kolayca geçiyordu. INP ise sayfadaki tüm etkileşimleri izleyip en yavaşlarından birini raporlar; bu yüzden kullanıcının gerçek deneyimini daha iyi yansıtır. Değişiklik Mart 2024’te yürürlüğe girdi.
PageSpeed puanı 100 olmazsa SEO’m kötü mü olur?
Hayır. Lighthouse puanı bir laboratuvar testidir ve doğrudan sıralama sinyali değildir. Önemli olan, gerçek kullanıcı verisinde LCP, INP ve CLS değerlerinin iyi eşikler içinde olmasıdır. 85 puanlı ama saha verisi iyi olan bir sayfa, 100 puanlı bir test sonucundan daha anlamlıdır.
Core Web Vitals düzeltmeleri ne zaman yansır?
Saha verisi son 28 günün kullanıcı deneyimine dayandığı için düzeltmelerin raporlara tam yansıması yaklaşık dört hafta sürer. Laboratuvar testlerinde ise iyileşmeyi hemen görebilirsiniz.
Son söz
Core Web Vitals, sitenizin ziyaretçiye nasıl hissettirdiğini üç sayıya indirger: ana içerik 2,5 saniyede görünsün, her tıklama 200 milisaniyede tepki bulsun, sayfa 0,1’in altında kaysın. Bu hedefler çoğu zaman pahalı bir yeniden yapım değil, doğru teşhis ve disiplinli küçük düzeltmeler gerektirir.
CYF Tech olarak geliştirdiğimiz web sitelerini ve web yazılımlarını en baştan hız bütçesiyle tasarlıyor, mevcut sitelerde de Core Web Vitals analizi ve iyileştirmesi yapıyoruz. Sitenizin neden yavaş olduğunu birlikte bulmak isterseniz bize ulaşın.
- web.dev — Web Vitals
- web.dev — How the Core Web Vitals metrics thresholds were defined
- web.dev — Largest Contentful Paint (LCP)
- web.dev — Interaction to Next Paint (INP)
- web.dev — Cumulative Layout Shift (CLS)
- web.dev — Time to First Byte (TTFB)
- Google Search Central — Understanding Core Web Vitals and Google search results
- Google Search Central — Understanding page experience