# Core Web Vitals nedir? LCP, INP ve CLS rehberi

> Core Web Vitals, Google’ın sayfa deneyimini ölçtüğü üç göstergedir. Tek başına ilk sıraya çıkarmazlar ama eşit güçteki iki site arasında ayırt edici olurlar.

Kaynak: https://flatinium.com/blog/core-web-vitals-nedir-detayli-rehber  
Yazar: Deniz Işık, Flatinium (https://flatinium.com/yazar/deniz-isik)  
Yayın: 2026-08-04

## Kısaca

- Core Web Vitals üç göstergeden oluşur: LCP (en büyük içeriğin görünme süresi), INP (etkileşime yanıt gecikmesi) ve CLS (yükleme sırasındaki kayma).
- İyi kabul edilen değerler: LCP 2,5 saniyenin altı, INP 200 milisaniyenin altı, CLS 0,1’in altı.
- INP, Mart 2024’te FID’in yerini aldı ve sayfanın tüm etkileşimlerine verdiği yanıtı ölçtüğü için daha zorlayıcıdır.
- Google bu ölçümleri gerçek kullanıcı verisinden (CrUX) alır; laboratuvar testi yön gösterir ama sıralamada kullanılan veri saha verisidir.
- Core Web Vitals tek başına sıralama getirmez; eşit güçteki iki sayfa arasında ayırt edici bir sinyal olarak çalışır.

## Üç ölçüt, tek amaç

Core Web Vitals, Google’ın sayfa deneyimini ölçmek için seçtiği üç metrik. Hepsi tek bir soruyu farklı açıdan soruyor: bu sayfa kullanıcıya hızlı ve düzgün mü davranıyor?

| Metrik | Ne ölçüyor | İyi | Geliştirilmeli | Kötü |
|---|---|---|---|---|
| LCP | En büyük içeriğin görünme süresi | 2,5 sn altı | 2,5–4 sn | 4 sn üstü |
| INP | Etkileşime cevap süresi | 200 ms altı | 200–500 ms | 500 ms üstü |
| CLS | Görsel kayma miktarı | 0,1 altı | 0,1–0,25 | 0,25 üstü |

Eşik değerler **75. yüzdelik** üzerinden hesaplanıyor. Yani kullanıcılarınızın dörtte üçü iyi deneyim yaşıyorsa geçer not alıyorsunuz. Ortalamaya değil dağılıma bakılıyor — bu önemli, çünkü yavaş cihazlardaki azınlık kullanıcı ortalamada kayboluyor ama 75. yüzdelikte görünüyor.

## LCP — en büyük içerik boyaması

Sayfadaki en büyük görsel veya metin bloğunun ekranda belirme süresi. Kullanıcının "sayfa açıldı" hissi genelde buna denk geliyor.

Yavaşlatan başlıca sebepler:

1. **Sunucu cevap süresi.** Her şeyin başı. Sunucu 800 ms'de cevap veriyorsa LCP'yi 2,5 sn altına indirmek çok zorlaşıyor.
2. **Büyük görseller.** Sıkıştırılmamış veya boyutu ekrandan büyük görseller.
3. **Render engelleyen kaynaklar.** Baştaki CSS ve senkron JavaScript.
4. **İstemci tarafı render.** İçerik JavaScript ile geliyorsa LCP gecikiyor.

En etkili düzeltmeler sırayla: görselleri modern biçime (WebP/AVIF) çevirmek, hero görseline yükleme önceliği vermek, sunucu tarafı render kullanmak, önbellek katmanı eklemek.

## INP — etkileşim sonrası boyama

2024'te FID'nin yerini aldı ve daha zorlayıcı bir ölçüt. Kullanıcı bir şeye tıkladığında ekranda değişikliğin görünmesine kadar geçen süre.

FID sadece ilk etkileşimin **gecikmesini** ölçüyordu. INP tüm etkileşimleri ve **tamamlanma** süresini ölçüyor. Bu yüzden birçok site FID'de iyiyken INP'de kötü çıktı.

INP'yi bozan şey neredeyse her zaman aynı: ana iş parçacığını uzun süre meşgul eden JavaScript. Tipik kaynaklar:

- Ağır üçüncü taraf betikleri (sohbet aracı, ısı haritası, reklam)
- Büyük React bileşen ağaçlarının yeniden render'ı
- Etkileşim anında yapılan senkron hesaplama

Çözüm yönü: gereksiz betiği kaldırmak, kalanını ertelemek, uzun işleri parçalara bölmek.

## CLS — kümülatif düzen kayması

Sayfa yüklenirken içeriğin yer değiştirmesi. Bir yazıyı okurken metnin aşağı kayması veya butona basacakken başka bir şeye basmanız.

Neredeyse tamamı dört sebepten geliyor:

| Sebep | Çözüm |
|---|---|
| Boyutsuz görsel | width ve height özniteliği vermek |
| Sonradan yüklenen yazı tipi | font-display ayarı ve ön yükleme |
| Üstten giren banner veya reklam | Yerini baştan ayırmak |
| Dinamik içerik enjeksiyonu | Yer tutucu koymak |

CLS düzeltmesi diğer ikisine göre çok daha kolay ve kalıcı. Genelde bir günlük iş.

## Saha verisi ve laboratuvar verisi

Ölçütlerin tanımı ve eşik değerleri [web.dev üzerindeki resmi belgede](https://web.dev/articles/vitals) duruyor; kendi sayfanızı ölçmek içinse [PageSpeed Insights](https://pagespeed.web.dev/) yeterli. Aynı sayfanın iki farklı sonuç vermesi hata değil: biri gerçek kullanıcı verisi, diğeri denetimli bir test.

En sık karışan konu bu. İki farklı veri kaynağı var ve farklı şeyler söylüyorlar:

**Saha verisi (CrUX).** Gerçek Chrome kullanıcılarından toplanıyor, 28 günlük kayan pencere. Search Console’daki Core Web Vitals raporu ve PageSpeed Insights’ın üst kısmı bunu gösteriyor. **Sıralamaya etki eden veri bu.**

**Laboratuvar verisi (Lighthouse).** Tek bir simüle edilmiş cihazda tek seferlik ölçüm. PageSpeed Insights’ın alt kısmı ve tarayıcıdaki Lighthouse sekmesi.

Aradaki farkın pratik sonucu: Lighthouse'ta 100 puan almış olabilirsiniz ama saha verisinde kötü görünebilirsiniz. Sebebi genelde gerçek kullanıcıların daha yavaş cihaz ve bağlantı kullanması.

Ayrıca saha verisi 28 gün geriden geliyor. Bugün yaptığınız düzeltme raporda haftalar sonra görünüyor — bu, "düzelttim ama değişmedi" paniğinin en yaygın sebebi.

## Sıralamaya etkisi ne kadar?

Dürüst cevap: sanıldığından az. Core Web Vitals bir sıralama sinyali ama içerik uygunluğunun yanında ağırlığı düşük. Google bunu açıkça söylüyor — eşit kalitedeki iki sayfa arasında ayrım yapıyor, kötü içeriği iyi yapmıyor.

Yine de üzerinde çalışmaya değer, çünkü:

- Dönüşüm oranını doğrudan etkiliyor. Yavaş sayfa satmıyor.
- Mobil kullanıcılarda terk oranını düşürüyor.
- Rekabetin sıkı olduğu kelimelerde ayrım noktası olabiliyor.

Yani asıl kazanç SEO’dan çok kullanıcı tarafında.

> **Örnek senaryo** — LCP değeri 6 saniyenin üzerinde olan bir kurumsal site düşünün. Tek sebep ana sayfadaki hero görseli: 2,8 MB’lık bir PNG. Görsel WebP’ye çevrilip doğru boyutta sunulursa LCP çoğu zaman belirgin şekilde düşer. Tek dosya, yarım saatlik iş; üç metrikten biri yeşile dönebilir.

> **İpucu** — Üç ölçütten hangisine önce bakılacağını saha verisi söylüyor. Search Console'daki Core Web Vitals raporunda kırmızı olan tek ölçüt varsa önce o; üçü de yeşilse laboratuvar skoruyla uğraşmak zaman kaybı.

## En sık karşılaştığımız beş sebep

Onlarca site denetledikten sonra oluşan liste. Sıralama, düzeltme başına kazanca göre:

**1. Optimize edilmemiş hero görseli.** Ana sayfanın üstündeki büyük görsel çoğu zaman 1–3 MB. WebP'ye çevirip doğru boyutta sunmak tek başına LCP'yi yarıya indirebiliyor. En ucuz kazanç bu.

**2. Yazı tipi yükleme sırası.** Google Fonts'un varsayılan yerleştirmesi hem LCP'yi geciktiriyor hem CLS üretiyor. Yazı tipini kendi sunucunuzdan servis edip ön yükleme etiketi vermek ikisini birden çözüyor.

**3. Üçüncü taraf betikleri.** Sohbet aracı, ısı haritası, sosyal medya gömüsü, piksel. Her biri ana iş parçacığını meşgul ediyor ve INP'yi bozuyor. Gerçekten kullanılmayanları kaldırmak, kalanları ertelemek gerekiyor.

**4. Sunucu cevap süresi.** Paylaşımlı barındırmada 800–1500 ms cevap süresi sık görülüyor. Bu, diğer tüm optimizasyonların üstüne binen sabit bir gecikme. Önbellek katmanı veya daha iyi barındırma tek çözüm.

**5. Boyutsuz görsel ve gömü.** width/height olmayan her görsel potansiyel CLS kaynağı. YouTube gömüleri ve reklam alanları da aynı sorunu yaratıyor.

Bu beşi düzeltmek çoğu sitede üç metriği de yeşile çeviriyor. Geri kalanı ince ayar.

## Ölçüm araçları

| Araç | Veri tipi | Ne için |
|---|---|---|
| Search Console | Saha | Site geneli durum, sorunlu sayfa grupları |
| PageSpeed Insights | İkisi de | Tek sayfa teşhisi |
| Chrome DevTools | Laboratuvar | Geliştirme sırasında |
| CrUX Dashboard | Saha | Zaman içindeki değişim |
| web-vitals kütüphanesi | Saha | Kendi analitiğinize kaydetmek |

Son satır en az bilinen ama en faydalısı. Kendi kullanıcılarınızın gerçek verisini topluyorsunuz ve 28 gün beklemiyorsunuz.

## Nereden başlamalı?

Sırayla:

1. Search Console'da hangi sayfa gruplarının kötü olduğunu görün.
2. En çok trafik alan kötü grubu seçin.
3. O gruptan bir temsilci sayfayı PageSpeed Insights'ta inceleyin.
4. Önce CLS'yi düzeltin — en ucuz kazanç.
5. Sonra LCP'ye geçin — genelde görsel ve sunucu işi.
6. INP'yi en sona bırakın — en zoru, çoğu zaman betik temizliği gerektiriyor.

> **Dikkat** — Lighthouse'ta 100 puan almış olmak saha verisinde iyi olduğunuz anlamına gelmiyor. Lighthouse tek bir simüle cihazda ölçüyor; sıralamaya etki eden veri ise gerçek kullanıcılardan geliyor ve 28 gün geriden takip ediyor.

## Ne zaman uğraşmayın?

Sitenizin hiç trafiği yoksa Core Web Vitals sizin sorununuz değil. Önce indekslenme ve içerik tarafını çözmek gerekiyor — hızlı ama görünmeyen sayfa kimseye fayda sağlamıyor.

Aynı şekilde, üç metrik de yeşilse daha da hızlandırmaya çalışmak getiri sağlamıyor. 2,4 saniyeyi 1,9'a düşürmek ölçülebilir bir kazanç getirmiyor.

Sitenizin hız tarafını bizim ele almamızı isterseniz [teknik SEO](https://flatinium.com/teknik-seo) hizmetimiz ölçüm, teşhis ve uygulamayı kapsıyor.

## Bu konuyla ilgili

- [web sitesi geliştirme](https://flatinium.com/web-sitesi-gelistirme) — Hız, sonradan eklenen değil mimaride kurulan bir şey.
- [Googlebot ne iş yapar?](https://flatinium.com/blog/googlebot-ne-is-yapar) — Yavaş sunucunun tarama tarafındaki bedeli.
- [Screaming Frog](https://flatinium.com/blog/screaming-frog-nedir) — Hız sorunlarının hangi sayfa gruplarında toplandığını bulmak.
- [site hızı testi](https://flatinium.com/araclar/site-hizi-testi) — Bu üç ölçütü kendi sayfanızda ölçün — gerçek kullanıcı verisiyle birlikte.

## Sık sorulan sorular

### Core Web Vitals sıralamayı ne kadar etkiliyor?

Google bunu bir sıralama sinyali olarak kullandığını doğruladı ama ağırlığının içerik kalitesine göre düşük olduğunu da belirtti. Pratikte şöyle düşünün: içerik eşitse hızlı olan kazanır; içerik zayıfsa hız tek başına kurtarmaz.

### PageSpeed puanı 100 olmalı mı?

Hayır. PageSpeed Insights’ın verdiği puan laboratuvar simülasyonudur; Google sıralamada gerçek kullanıcı verisini (CrUX) kullanıyor. 100 puan kovalamak yerine üç göstergenin de "iyi" bandında olmasını hedefleyin.

### En hızlı kazanç nerede?

Çoğu sitede LCP tarafında: en büyük görselin boyutunu düşürmek, modern format kullanmak, sunucu yanıt süresini kısaltmak ve yazı tiplerini kendi sunucunuzdan servis etmek. Bu dördü genellikle en büyük sıçramayı sağlıyor.

### Düzelttim ama raporda değişmedi, neden?

Search Console’daki Core Web Vitals verisi gerçek kullanıcılardan toplanıyor ve kayan bir zaman penceresi kullanıyor. Bugün yaptığınız düzeltme raporda haftalar sonra görünüyor. Bu, en yaygın panik sebebi. Anlık kontrol için PageSpeed Insights’ın laboratuvar ölçümüne bakabilirsiniz ama sıralamaya etki eden veri saha verisi.