Core Web Vitals, Google'ın 2021'den bu yana resmi sıralama sinyali olarak kullandığı üç performans metriğidir: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) ve Cumulative Layout Shift (CLS). Google Search Central belgelerine göre (Aralık 2025 güncellemesiyle) "iyi" eşikleri sırasıyla 2,5 saniye, 200 milisaniye ve 0,1 olarak tanımlanmıştır; tüm değerlendirme gerçek kullanıcı verilerinin 75. yüzdeliğinde yapılmaktadır. 2026 itibarıyla sitelerin yalnızca %47'si bu üç eşiği aynı anda karşılamaktadır.
Hızlı Özet
- 2026'da INP, sitelerin %43'ünün başarısız olduğu en yaygın ihlal edilen Core Web Vitals metriğidir; bu oran FID döneminin çok üzerindedir.
- LCP eşiğinin (2,5 sn) ötesindeki her bir saniyelik gecikme, hemen çıkma oranını %32 artırmaktadır; bir e-ticaret sitesi için bu gecikme aylık 7.000 dolar gelir kaybına dönüşebilir.
- Web Almanac 2025 verisine göre, mobil sayfaların %62'si boyut belirtilmemiş en az bir görsel içermekte ve bu durum CLS'nin en yaygın kaynağı olmaya devam etmektedir.
- Üç metriğin tamamını geçen siteler, geçemeyenlere kıyasla ortalama %24 daha düşük hemen çıkma oranı ve ölçülebilir sıralama avantajı elde etmektedir.
- Google, Core Web Vitals değerlendirmesini URL düzeyinde CrUX verisiyle yapmakta; yüksek trafikli sayfalardaki düşük performans tüm sitenin sıralamasını olumsuz etkileyebilmektedir.
core web vitals nedir?
core web vitals, google’ın gerçek kullanıcı deneyimini ölçmek amacıyla tanımladığı ve doğrudan sıralama sinyali olarak kullandığı üç web performans metriğidir: yüklenme hızını ölçen Largest Contentful Paint (LCP), etkileşim duyarlılığını ölçen Interaction to Next Paint (INP) ve görsel kararlılığı ölçen Cumulative Layout Shift (CLS). Google, bu metrikleri 2021’de resmi sıralama faktörü olarak benimsedi; Mart 2024’te ise FID’i (First Input Delay) INP ile değiştirerek sistemin kapsamını önemli ölçüde genişletti. 2026 itibarıyla bu üç metrik, benzer içerik kalitesine sahip sayfalar arasındaki sıralama farkını belirleyen kritik bir eşiğe dönüşmüştür.
Google Search Central belgelerine göre bir sayfanın “İyi” Core Web Vitals değerlendirmesi alabilmesi için üç eşiğin tamamının gerçek kullanıcı verilerinin 75. yüzdeliğinde karşılanması gerekir. Bu yaklaşım, ziyaretçilerin büyük çoğunluğunun iyi bir deneyim yaşadığını teyit etmek amacıyla tasarlanmıştır; en hızlı %25’lik dilimi değil, genel kullanıcı kitlesinin deneyimini esas alır. 2026 verisine göre sitelerin yalnızca %47’si bu üç eşiği aynı anda karşılamakta; geri kalan %53’lük kesim ise potansiyel dönüşüm, trafik ve gelir kaybıyla karşı karşıya kalmaktadır.
2026 Core Web Vitals Eşikleri: Güncel Tablolar
Aşağıdaki tablo, Google’ın resmi eşiklerini ve değerlendirme kategorilerini özetlemektedir.
| Metrik | İyi | İyileştirme Gerekiyor | Yetersiz |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2,5 sn | 2,6 – 4,0 sn | > 4,0 sn |
| INP (Interaction to Next Paint) | ≤ 200 ms | 201 – 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Kaynak: Google Search Central, Core Web Vitals Dokümantasyonu – Aralık 2025 güncellemesi
LCP (Largest Contentful Paint) Nedir ve Nasıl Optimize Edilir?
LCP, kullanıcının bir sayfa yüklemesini başlatmasından, görünüm alanındaki en büyük içerik öğesinin tam olarak render edilmesine kadar geçen süreyi ölçer. Söz konusu öğe genellikle bir hero görseli, büyük bir metin bloğu veya video küçük resmidir. Google, iyi bir kullanıcı deneyimi için LCP’nin ziyaretlerin en az %75’inde 2,5 saniye veya daha kısa sürmesini hedef olarak belirlemektedir.
LCP başarısızlıklarının dört temel nedeni vardır: geç kaynak keşfi, düşük indirme önceliği, uzun kaynak indirme süresi ve öğe render gecikmesi. Bu dört faktörden herhangi biri, metriği “Yetersiz” bölgesine taşıyabilir; dolayısıyla optimizasyon da bu dört alana ayrı ayrı uygulanmalıdır.
LCP Optimizasyon Teknikleri
1. fetchpriority=”high” ve preload kombinasyonu kullanın.
Tarayıcı, varsayılan olarak görsellere düşük öncelik atar ve CSS dosyası indirildikten sonra bu önceliği yükseltir; bu gecikme LCP süresini doğrudan artırır. fetchpriority="high" özelliği, görselin düşük öncelikli tespitinden kaçınarak tarayıcının onu hemen yüksek öncelikle indirmesini sağlar. Google Flights üzerinde yapılan testlerde yalnızca bu özelliğin eklenmesi, LCP süresini 2,6 saniyeden 1,9 saniyeye indirmiştir. Doğru uygulama için <link rel="preload"> etiketiyle erken keşif sağlanmalı, ardından <img> etiketine fetchpriority="high" eklenmelidir; bu “kemer ve askı” yaklaşımı her iki mekanizmayı birlikte devreye sokar.
<!-- <head> içinde -->
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">
<!-- <body> içinde -->
<img src="hero.webp" fetchpriority="high" loading="eager" alt="Hero görseli" width="1200" height="600">
2. LCP görseline asla lazy loading uygulamayın.
loading="lazy", tarayıcının görseli yalnızca düzen hesaplamaları tamamlandıktan sonra yüklemesine neden olur. Bu, görünüm alanındaki en büyük öğeye uygulandığında LCP süresini doğrudan artıran bir performans hatasıdır. LCP görseli her zaman loading="eager" veya özellik belirtilmeden bırakılmalıdır.
3. Sunucu taraflı render (SSR) veya statik render tercih edin.
İstemci taraflı render (CSR) ile oluşturulan görseller, tarayıcının yüksek hızlı ön yükleme tarayıcısı tarafından keşfedilemez; JavaScript çalıştırılana kadar görsel keşfedilmez ve bu durum ciddi bir LCP gecikmesine yol açar. SSR veya statik HTML kullanıldığında görsel ilk HTML yanıtında yer alır, tarayıcı onu anında keşfedebilir.
4. Critical CSS’i inline yapın, JavaScript’i kritik yoldan uzaklaştırın.
Başlangıç yüklemesindeki her render-blocking kaynak, LCP öğesinin tarayıcıya ulaşmasını geciktirir. LCP öğesini render etmek için gereken minimum CSS’i <head> içinde inline olarak sunmak; diğer script ve stil dosyalarını defer veya async ile geciktirmek, öğenin render süresini doğrudan kısaltır.
INP (Interaction to Next Paint) Nedir ve Nasıl Optimize Edilir?
INP, sayfanın tüm kullanım süresi boyunca gerçekleşen etkileşimlerin (tıklama, dokunma, klavye girişi) giriş noktasından bir sonraki görsel güncellemeye kadar geçen toplam süreyi ölçer. Yalnızca ilk etkileşimi ölçen FID’in aksine, INP ziyaret boyunca tüm etkileşimlerin 95. yüzdelik değerini dikkate alır; bu nedenle sayfa ne kadar karmaşık ve etkileşim yoğun ise INP o kadar sert şekilde etkilenir. 2026 itibarıyla sitelerin %43’ü 200 ms eşiğini karşılayamamakta ve INP, üç Core Web Vitals metriği içinde en yaygın ihlal edilen metrik olmaya devam etmektedir.
INP başarısızlıklarının temel kaynağı, JavaScript’in tarayıcının ana iş parçacığını (main thread) uzun süreler boyunca bloke etmesidir. Bir etkileşim gerçekleştiğinde tarayıcının yanıt vermesi için ana iş parçacığının müsait olması gerekir; aksi takdirde etkileşim kuyruğa girer ve kullanıcı arayüzü donmuş görünür.
INP Optimizasyon Teknikleri
1. Uzun görevleri scheduler.yield() ile bölün.
50 milisaniyenin üzerinde süren her JavaScript görevi, INP’yi olumsuz etkileyen bir “uzun görev” olarak tanımlanır. scheduler.yield() API’si, uzun görevleri küçük parçalara bölerek tarayıcıya aralarında etkileşimleri işleme fırsatı tanır. Bu API’nin en önemli avantajı, görevin devamını öncelikli olarak kuyruğa alması; üçüncü taraf scriptlerin araya girmesini engellemesidir.
async function saveSettings(jobs) {
for (const job of jobs) {
processJob(job);
// Her görev arasında ana iş parçacığına yer aç
await scheduler.yield();
}
}
2. Üçüncü taraf scriptleri denetleyin ve geciktirin.
Analitik araçları, canlı destek widget’ları ve reklam etiketleri, ana iş parçacığı sürelerinin büyük bölümünü tüketebilir. Bu scriptler yalnızca gerçekten gerektiğinde ve mümkün olduğunda etkileşim sonrasında yüklenmeli; kritik sayfa yüklemesi sırasında çalışmamalıdır. Chrome DevTools Performans panelinde 4x CPU yavaşlatma ile kayıt alarak hangi scriptlerin uzun görev oluşturduğunu tespit etmek mümkündür.
3. Olay işleyicilerini (event handler) hafifletin.
Bir tıklama veya dokunma olayı tetiklendiğinde aynı anda doğrulama, biçimlendirme, analitik ve arayüz güncellemesi çalıştırmak, her birinin işleme süresini toplar ve 200 ms eşiğini aşabilir. Yalnızca arayüzün hemen göstermesi gereken işi önce yapın; ikincil mantığı (analitik, arka plan senkronizasyonu) setTimeout veya requestIdleCallback ile sonraki bir göreve erteleyin.
4. Gereksiz JavaScript göndermekten kaçının.
2026 performans çerçevesindeki en yüksek ROI optimizasyonu, daha az JavaScript göndermektir. Chrome DevTools Coverage paneli, kullanılmayan kodu tespit etmek için kullanılabilir. Dinamik import ve kod bölme (code splitting) ile yalnızca ihtiyaç duyulan modüller yüklendiğinde, hem ilk yükleme hem de sonraki etkileşimler için ana iş parçacığı yükü ciddi ölçüde azalır.
CLS (Cumulative Layout Shift) Nedir ve Nasıl Optimize Edilir?
CLS, kullanıcının sayfa ziyareti boyunca gerçekleşen beklenmedik görsel kaymalar için hesaplanan kümülatif bir skorudur. Yalnızca ilk yükleme değil, ziyaretçi sayfadan ayrılana kadar oluşan tüm kaymalar hesaba katılır. Web Almanac 2025 verisine göre mobil sayfaların %62’si boyutsuz görsel barındırmakta ve bu durum CLS’nin en yaygın kaynağı olmaya devam etmektedir.
CLS’nin başlıca nedenleri şunlardır: açık boyut belirtilmemiş görseller ve medya öğeleri, farklı ölçülerdeki yedek fonttan özel fonta geçiş, sayfa yüklendikten sonra mevcut içeriğin üstüne enjekte edilen dinamik içerikler (reklam, çerez bandı, bildirim), ve top/left/margin/width gibi düzen etkileyen CSS animasyonları.
CLS Optimizasyon Teknikleri
1. Tüm görsel ve medya öğelerine açık boyut atayın.
Tarayıcı, <img> etiketinde width ve height özelliği olmayan bir görsel keşfettiğinde başlangıçta sıfır alan ayırır. Görsel indirilip gerçek boyutları öğrenildiğinde, tüm aşağıdaki içeriği kaydırır. Açık boyutlar eklendiğinde tarayıcı görsel yüklenmeden önce doğru alanı ayırır ve kayma gerçekleşmez.
<!-- Doğru kullanım -->
<img src="urun.webp" width="800" height="450" alt="Ürün görseli">
/* Duyarlı düzenler için CSS aspect-ratio ile birlikte */
img { width: 100%; height: auto; aspect-ratio: 16/9; }
2. Font yükleme stratejisini font-display: swap ile yönetin.
Web fontu indirilirken tarayıcı, yedek sistem fontuyla metni görüntüler. Font yüklendiğinde iki font arasındaki boyut farkı, metin bloğunu kaydırır. font-display: swap yedek fontu hemen gösterirken, ascent-override, descent-override ve line-gap-override metrikleri ile yedek fontun boyutları özel fonta eşitlendiğinde kayma miktarı asgari düzeye iner.
@font-face {
font-family: 'CustomFont';
src: url('/font.woff2') format('woff2');
font-display: swap;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}
3. Dinamik içeriği görünüm alanının üstüne enjekte etmeyin.
Çerez bandı, promosyon bildirimi veya reklam birimi gibi öğeler sayfa yüklendikten sonra mevcut içeriğin üstüne eklendiğinde tüm aşağıdaki içerik kayar. Bu öğeleri sabit pozisyonda (position: fixed) bindirme olarak sunmak ya da sayfanın alt bölümüne yerleştirmek, düzen akışını bozmadan kullanıcıya ulaşır. Reklam alanları için minimum yüksekliği önceden rezerve etmek de yaygın ve etkili bir çözümdür.
4. Düzen etkileyen animasyonları transform ile değiştirin.
top, left, margin veya width özelliklerini değiştiren CSS animasyonları, tarayıcının her karede yeniden düzen hesaplaması yapmasına neden olur ve CLS’ye katkıda bulunur. transform: translateX/Y() ve opacity tabanlı animasyonlar ise GPU compositor iş parçacığında çalışır, düzeni etkilemez ve CLS’ye dahil edilmez.
Core Web Vitals’ı Ölçme: Doğru Araçlar
Gerçek kullanıcı performansı (alan verisi) ile laboratuvar testleri arasındaki farkı anlamak, doğru aracı seçmenin temelidir. Google’ın değerlendirmesi her zaman alan verisi (CrUX) üzerinden yapılır; laboratuvar araçları ise sorun tespitinde kullanılır.
Alan verisi araçları: Google Search Console’daki Core Web Vitals raporu, son 28 güne ait gerçek kullanıcı verilerini URL grubu bazında gösterir. PageSpeed Insights ise hem CrUX verisini hem de anlık laboratuvar sonuçlarını aynı sayfada sunar.
Sorun tespiti araçları: Chrome DevTools Performans paneli, INP için etkileşim izleme, LCP için ağ şelalesi görünümü ve CLS için “Yerleşim Kaydırma Bölgeleri” katmanı sunar. Paneli kullanırken CPU’yu 4x yavaşlatmak, gerçek mobil cihaz koşullarını simüle etmek açısından kritik bir adımdır; geliştirici makinesindeki hız farkı, gerçek kullanıcılara yansıyan uzun görevleri gizleyebilir.
İzleme stratejisi: Metriklerin Google eşiklerinin %80’ine ulaştığı anda uyarı alacak şekilde yapılandırılmış izleme kurulmalıdır: INP > 160 ms, LCP > 2,0 sn, CLS > 0,08. Bu erken uyarı eşikleri, bir deployment sonrasındaki INP artışı ya da yeni bir reklam scriptinin tetiklediği CLS regresyonu gibi sorunların CrUX penceresini etkilemeden önce tespit edilmesini sağlar.
2026’da Core Web Vitals ve İş Etkisi
Core Web Vitals optimizasyonu salt teknik bir gereklilik olmaktan çıkmış, doğrudan ticari sonuçlara bağlanan bir yatırım kalemine dönüşmüştür. LCP eşiğinin aşıldığı her saniyede hemen çıkma oranı %32 artmaktadır. Aylık 100.000 dolar gelir üreten bir e-ticaret sitesi için 1 saniyelik yükleme gecikmesi, dönüşüm oranında %7 düşüş anlamına gelir; bu, yıllık 84.000 dolarlık kayba karşılık gelir. Tersine, üç metriğin tamamını geçen siteler dönüşüm oranında %15 ila %30 iyileşme kaydetmektedir.
Mobil cihazlar 2026’da Google aramalarının %60’ından fazlasını oluşturmakta ve Google sıralamayı belirlerken masaüstü değil, mobil performansı esas almaktadır. Fiber bağlantıyla çalışan bir dizüstü bilgisayarda üretilen test sonuçları, 4G üzerindeki orta segment bir Android cihazda gerçek kullanıcının yaşadığı deneyimi temsil etmez. Bu asimetri, mobil öncelikli test ve optimizasyonu zorunlu kılmaktadır.
2026 Core Web Vitals Öncelik Sırası
2026 optimizasyon stratejisi net bir öncelik hiyerarşisi gerektirir. INP, sitelerin %43’ünün başarısız olduğu ve derin JavaScript mimarisi değişiklikleri gerektiren en kritik metriktir; uzun görevlerin bölünmesi ve olay işleyicilerinin hafifletilmesi bu kategorideki en yüksek etkili müdahalelerdir. LCP için preload ve fetchpriority="high" kombinasyonu, LCP görseline lazy loading uygulanmaması ve kritik CSS’in inline sunulması, altyapı düzeyindeki en etkili çözümlerdir. CLS ise en yüksek geçiş oranına sahip metriktir ve açık boyut ataması ile font metrik eşlemesi gibi görece kolay düzeltmeler çoğu durumda “İyi” eşiğine ulaşmak için yeterlidir.
Üç metriğin tamamını geçen siteler, geçemeyenlere kıyasla %24 daha düşük hemen çıkma oranı, daha yüksek organik görünürlük ve ölçülebilir dönüşüm artışı elde etmektedir. Bu sonuçlar, Core Web Vitals optimizasyonunu 2026 dijital stratejisinin temel bir bileşeni konumuna taşımaktadır.
" Mastering LCP, INP, and CLS isn't about chasing perfect scores. It's about creating experiences that feel fast, responsive, and stable to real users. That foundation of excellent Core Web Vitals combined with E-E-A-T signals creates the sites that will thrive in 2026 and beyond. ("LCP, INP ve CLS'de mükemmel puan peşinde koşmak değil asıl mesele; kullanıcılara hızlı, duyarlı ve kararlı deneyimler sunmak. Güçlü Core Web Vitals ve E-E-A-T sinyallerinin birleşimi, 2026'da ve sonrasında öne çıkan siteleri yaratacak.") "
merak edilenler
Core Web Vitals 2026'da Google sıralamasını etkiliyor mu?
Evet. Core Web Vitals, Google’ın sayfa deneyimi sinyallerinin onaylanmış bir bileşenidir. İçerik kalitesi hâlâ birincil faktör olmakla birlikte, benzer kalitedeki sayfalar arasında Core Web Vitals belirleyici bir fark yaratır. Üç eşiği de karşılayan sitelerin organik performansında ölçülebilir bir artış gözlemlenmektedir.
INP nedir ve FID'den ne farkı var?
INP (Interaction to Next Paint), bir kullanıcının sayfayla gerçekleştirdiği her etkileşimin (tıklama, dokunma, klavye girişi) giriş noktasından tarayıcının bir sonraki görsel güncellemeyi boyamasına kadar geçen toplam süreyi ölçer. FID yalnızca ilk etkileşimdeki gecikmeyi ölçerken INP, sayfa ziyareti boyunca tüm etkileşimlerin 95. yüzdelik değerini dikkate alır. Bu nedenle INP çok daha gerçekçi bir duyarlılık göstergesidir.
CLS skoru 0.1'in altına nasıl indirilir?
CLS’yi 0.1’in altına indirmenin üç temel yolu vardır: tüm görsel ve medya öğelerine açık boyut (width/height) atanması, web fontları için font-display: swap ile birlikte yedek font metrikleri (ascent-override, descent-override) kullanılması, ve dinamik içeriklerin (reklam, çerez bandı, bildirim) başlangıç düzeninin üstüne enjekte edilmemesi. Bu üç düzeltmenin tümü birlikte uygulandığında çoğu sitede CLS’yi ‘İyi’ eşiğinin altına indirmek mümkündür.
Core Web Vitals hangi araçlarla ölçülür?
Alan verisi (gerçek kullanıcı performansı) için Google Search Console’daki Core Web Vitals raporu ve PageSpeed Insights kullanılır; bu veriler CrUX’un 28 günlük penceresini yansıtır. Sorun tespiti için Chrome DevTools Performans paneli tercih edilir: INP için etkileşim takibi, LCP için ağ şelalesi, CLS için Yerleşim Kaydırma Bölgeleri katmanı devreye alınır.
referanslar & kaynaklar
- Understanding Core Web Vitals and Google search results
- Optimize Interaction to Next Paint
- How the Core Web Vitals metrics thresholds were defined
- Core Web Vitals Explained: LCP, INP, and CLS After the December 2025 Update
- Core Web Vitals 2026: INP, LCP & CLS Optimization
- What Are the Core Web Vitals? LCP, INP & CLS Explained (2026)
