Ara
SEO

Core Web Vitals (LCP, INP, CLS) Nedir, Nasıl İyileştirilir?

Core Web Vitals nedir, sıralamayı etkiler mi? LCP, INP ve CLS eşikleri, Search Console ile ölçüm ve her metriği adım adım düzeltmenin yolları tek rehberde.

Güncellendi: 8 dk okuma

Core Web Vitals (LCP, INP, CLS) Nedir, Nasıl İyileştirilir?
İçindekiler
  1. Core Web Vitals neyi ölçer?
  2. Eşik değerleri: İyi, iyileştirilmeli, kötü
  3. Core Web Vitals sıralamayı ne kadar etkiler?
  4. Değerlerinizi nereden görürsünüz?
  5. LCP nasıl iyileştirilir?
  6. INP nasıl iyileştirilir?
  7. CLS nasıl iyileştirilir?
  8. Adım adım iyileştirme planı
  9. Yapay zeka aramaları açısından Core Web Vitals
  10. Sonuç

Core Web Vitals, Google’ın bir sayfadaki gerçek kullanıcı deneyimini ölçmek için kullandığı üç metriktir: yükleme hızı için LCP, tepki süresi için INP ve görsel kararlılık için CLS. İyi sayılmak için LCP 2,5 saniyenin, INP 200 milisaniyenin, CLS ise 0,1’in altında olmalı. Google bu metriklerin sıralama sistemlerinde kullanıldığını doğruluyor; ama alakalı içeriğin yerini tutmadıklarını da açıkça söylüyor.

Bu rehberde her metriğin ne ölçtüğünü, değerlerinizi nereden göreceğinizi ve kötü çıkan bir metriği hangi sırayla düzelteceğinizi anlatıyorum. Kaynaklarım Google Search Central, Search Console Yardım ve Chrome ekibinin web.dev belgeleri.

Core Web Vitals neyi ölçer?

Üç metrik, kullanıcının bir sayfayı açtığında sorduğu üç soruya karşılık gelir:

Reklam
  • Sayfa açılıyor mu? → LCP (Largest Contentful Paint): Ekranda görünen en büyük içerik öğesinin (genellikle kapak görseli veya ana başlık bloğu) ne zaman çizildiği.
  • Tıkladığımda tepki veriyor mu? → INP (Interaction to Next Paint): Kullanıcının tıklama, dokunma veya tuş basışından sonra sayfanın ekranda bir sonraki görsel değişikliği ne kadar sürede gösterdiği.
  • Okurken içerik kayıyor mu? → CLS (Cumulative Layout Shift): Sayfa yüklenirken ya da sonrasında öğelerin beklenmedik şekilde yer değiştirme miktarı.

INP, 12 Mart 2024’te First Input Delay’in (FID) yerini aldı. FID yalnızca ilk etkileşimin gecikmesine bakıyordu; INP ise ziyaret boyunca yapılan bütün etkileşimleri değerlendiriyor. Bu yüzden eski rehberlerde FID gördüğünüzde bilginin güncel olmadığını bilin.

Eşik değerleri: İyi, iyileştirilmeli, kötü

Search Console’daki Core Web Vitals raporu şu sınırları kullanıyor:

Metrik İyi İyileştirilmeli Kötü
LCP ≤ 2,5 sn ≤ 4 sn > 4 sn
INP ≤ 200 ms ≤ 500 ms > 500 ms
CLS ≤ 0,1 ≤ 0,25 > 0,25

İki ayrıntı önemli:

  1. 75. yüzdelik kuralı. Değerlendirme, ziyaretlerin ortalamasına değil 75. yüzdeliğe bakılarak yapılır. Yani ziyaretlerin en az %75’i eşiği karşılamalı. Hızlı bir bilgisayarda sayfanız uçuyor olabilir; yavaş telefonla bağlanan dörtte bir kullanıcı kötü deneyim yaşıyorsa sonuç “iyi” çıkmaz.
  2. En kötü metrik belirler. Search Console bir URL grubuna, üç metrikten en kötü olanının durumunu verir. LCP ve INP iyi, CLS kötüyse grup “Kötü” görünür. Mobil ve masaüstü ayrı ayrı değerlendirilir.

Tablo ne kadar zor? HTTP Archive’ın Ocak 2026’da yayımladığı Web Almanac 2025 raporuna göre (Temmuz 2025 verisi), web sitelerinin mobilde %48’i, masaüstünde %56’sı üç metriğin hepsini geçiyor. Mobilde en çok takılınan metrik LCP: sitelerin yalnızca %62’si mobilde iyi LCP’ye sahip. Yani üç metriği de geçen bir site, rakiplerinin yaklaşık yarısının önünde başlıyor.

Core Web Vitals sıralamayı ne kadar etkiler?

Google’ın sayfa deneyimi belgesi (son güncelleme 22 Eylül 2026) bu soruya dengeli bir yanıt veriyor:

  • Core Web Vitals sıralama sistemlerinde kullanılıyor.
  • Tek bir “sayfa deneyimi sinyali” yok; çekirdek sıralama sistemleri birden fazla sinyale bakıyor.
  • Google, sayfa deneyimi vasat olsa bile en alakalı içeriği göstermeye çalışıyor.
  • Aynı soruya yanıt veren çok sayıda yararlı sayfa varsa, iyi sayfa deneyimi başarıya katkı sağlayabiliyor.
  • İyi bir Search Console raporu ilk sırayı garanti etmiyor; yalnızca SEO için kusursuz puan kovalamak da Google’a göre zamanınızı kullanmanın en iyi yolu olmayabilir.

Benim pratik yorumum şu: Core Web Vitals bir eleme turu gibidir. İçeriğiniz rakiplerinizle aynı seviyedeyken yavaş, zıplayan bir sayfa sizi geride bırakır. Ama zayıf bir içeriği hızlı yaparak birinci sıraya taşıyamazsınız. Önce SEO uyumlu, yararlı içerik, sonra hız.

Hızın bir de doğrudan iş etkisi var: Sayfa ne kadar çabuk açılır ve ne kadar az kayarsa okur o kadar kalır, form doldurur, satın alır. Reklam gösteren sitelerde sabit duran bir sayfa, yanlışlıkla reklama tıklanmasını da önler.

Değerlerinizi nereden görürsünüz?

Ölçüm araçları iki gruba ayrılır ve bu ayrımı bilmek çoğu yanlış yorumu önler.

Saha verisi (gerçek kullanıcılar). Chrome kullanıcılarından anonim olarak toplanan Chrome UX Report (CrUX) verisidir. Google’ın değerlendirmede baktığı veri budur.

  • Search Console → Core Web Vitals raporu: Benzer sayfaları gruplar, sorunlu grupları ve örnek URL’leri gösterir. Yalnızca dizine eklenmiş URL’ler yer alır. Yeni veya az trafikli sitelerde rapor boş kalabilir. Kullanımı için Google Search Console rehberine bakabilirsiniz.
  • PageSpeed Insights’ın üst bölümü: Gerçek kullanıcı deneyimini gösteren bölüm, CrUX’tan gelen son 28 günlük saha verisidir.

Laboratuvar verisi (simülasyon). Tek bir cihazda, belirli koşullarda yapılan ölçümdür; hata ayıklamak için idealdir ama sıralamada kullanılmaz.

  • Lighthouse ve PageSpeed Insights’ın alt bölümü: 0-100 arası performans puanı buradan gelir. Lighthouse INP’yi ölçemez; onun yerine Toplam Engelleme Süresi’ni (TBT) gösterir.
  • Chrome Geliştirici Araçları → Performance paneli: LCP, INP ve CLS’yi canlı olarak gösterir; hangi öğenin LCP olduğunu, hangi etkileşimin yavaş kaldığını bulmak için en iyi araçtır.

Sık yapılan hata, Lighthouse puanı 95 olduğu hâlde Search Console’da “Kötü” görünen sayfaya şaşırmaktır. Lighthouse bir kez, sizin seçtiğiniz koşullarda ölçer; saha verisi ise binlerce gerçek ziyaretin 75. yüzdeliğidir. Karar verirken saha verisine güvenin.

Reklam

LCP nasıl iyileştirilir?

web.dev, LCP süresini dört parçaya ayırıyor. Sorunu bulmak için önce hangi parçanın uzun olduğuna bakın:

  1. Sunucu yanıt süresi (TTFB): Tarayıcının ilk baytı alana kadar geçen süre. Toplamın yaklaşık %40’ı olmalı.
  2. Kaynak yükleme gecikmesi: İlk bayttan LCP görselinin indirilmeye başlamasına kadar geçen süre. %10’un altında, mümkünse sıfıra yakın olmalı.
  3. Kaynak yükleme süresi: Görselin kendisinin inmesi. Yaklaşık %40.
  4. Öğe çizim gecikmesi: Görsel indikten sonra ekrana çizilmesine kadar geçen süre. %10’un altında olmalı.

Bu parçalara göre en etkili düzeltmeler:

  • LCP görselini tembel yüklemeyin. web.dev bu konuda kesin: LCP görseline asla loading="lazy" vermeyin. WordPress ve birçok eklenti tembel yüklemeyi bütün görsellere uygular; kapak görselini hariç tutun.
  • Görseli HTML’de bulunur yapın ve önceliklendirin. Kapak görseli CSS arka planı veya JavaScript ile sonradan ekleniyorsa tarayıcı onu geç keşfeder. <img> etiketiyle HTML’e koyun ve fetchpriority="high" ekleyin. Bu özelliği bir veya iki görselden fazlasına vermek etkisini azaltır.
  • Görseli küçültün. WebP veya AVIF kullanın, ekran boyutuna uygun srcset verin. Ayrıntılar: SEO resim optimizasyonu rehberi.
  • TTFB’yi düşürün. Yönlendirme zincirlerini kaldırın, sayfa önbelleği ve CDN kullanın, önbelleği bozan gereksiz URL parametrelerinden kaçının.
  • Oluşturmayı engelleyen kaynakları azaltın. <head> içindeki eşzamanlı (senkron) betikleri defer ile erteleyin, kritik CSS’i küçük tutun.

INP nasıl iyileştirilir?

INP’yi oluşturan üç aşama vardır: giriş gecikmesi (tıklamadan sonra kodun çalışmaya başlamasına kadar geçen süre), işleme süresi (olay kodunun çalışması) ve sunum gecikmesi (kod bittikten sonra ekranın yeniden çizilmesi). Yavaş INP’nin neredeyse her zaman sebebi, tarayıcının ana iş parçacığını uzun süre meşgul eden JavaScript’tir.

  • Uzun görevleri bölün. Tıklamaya karşılık önce ekranda görünen değişikliği yapın, kaydetme ve analiz gönderme gibi acil olmayan işleri sonraki bir göreve erteleyin.
  • Daha az JavaScript gönderin. Kullanılmayan eklentileri, sayfada işe yaramayan sohbet balonlarını, aynı işi yapan iki analiz betiğini kaldırın. Tarayıcının kendi özellikleriyle yapılabilecek işler için kütüphane yüklemeyin.
  • DOM’u küçük tutun. Binlerce öğeli sayfalarda her etkileşim pahalıya patlar. Ekran dışındaki bölümler için CSS content-visibility kullanılabilir.
  • Üçüncü taraf betikleri denetleyin. Etiket yöneticisiyle yıllar içinde eklenmiş, kimsenin hatırlamadığı betikler INP’nin en sık gizli suçlusudur.

Web Almanac verisine göre masaüstünde sitelerin %97’si iyi INP’ye sahipken mobilde bu oran %77’ye düşüyor. Sebebi basit: Telefonların işlemcisi daha zayıf. INP’yi mutlaka mobil cihazda veya Geliştirici Araçları’nda işlemci yavaşlatması açıkken test edin.

CLS nasıl iyileştirilir?

CLS’nin dört klasik sebebi var: boyutu belirtilmemiş görsel ve iframe’ler, boşluğu ayrılmamış reklamlar, sonradan eklenen bantlar ve web fontları.

  • Görsellere width ve height verin veya CSS aspect-ratio ile yer ayırın. Tarayıcı görsel inmeden önce ne kadar yer bırakacağını bilir.
  • Reklam alanlarına önceden yer ayırın. web.dev, reklam ve gömülü içerikler için min-height veya aspect-ratio ile alan ayrılmasını ve reklam gelmediğinde alanın kapatılmayıp yer tutucu bırakılmasını öneriyor. AdSense kullanan bloglarda en sık CLS kaynağı budur.
  • Çerez bildirimi ve kampanya bantlarını içeriği itmeyecek şekilde gösterin. Sayfanın üstüne sonradan eklenen bir bant bütün içeriği aşağı kaydırır; bunun yerine sayfanın üzerinde (overlay) veya önceden ayrılmış alanda gösterin.
  • Font geçişini yumuşatın. Yedek fontu gerçek fonta yakın ölçülerle ayarlayın, kritik fontu önceden yükleyin veya font-display: optional kullanın.
  • Animasyonları transform ile yapın. top, left, height gibi özellikleri canlandırmak yerleşimi bozar.

Not: Kullanıcının tıklamasından sonraki 500 milisaniye içinde olan kaymalar CLS’ye sayılmaz. “Daha fazla göster” düğmesine basınca içeriğin açılması sorun değildir; sorun, kullanıcı hiçbir şey yapmadan içeriğin kaymasıdır.

Adım adım iyileştirme planı

  1. Search Console’da Core Web Vitals raporunu açın, önce mobil sekmesine bakın. “Kötü” ve “İyileştirilmeli” grupları not edin.
  2. Her gruptan bir örnek URL’yi PageSpeed Insights’ta test edin. Hangi metriğin sorunlu olduğunu ve LCP öğesinin ne olduğunu belirleyin.
  3. Şablon düzeyinde düzeltin. Sorunlar genellikle tek sayfada değil şablondadır (bütün blog yazıları, bütün ürün sayfaları). Bir şablonu düzeltmek yüzlerce URL’yi birden iyileştirir.
  4. Doğrulamayı başlatın. Search Console’da sorunun ayrıntı sayfasından izlemeyi başlattığınızda 28 günlük bir izleme dönemi başlar. Bu süre boyunca hiçbir URL’de sorun görülmezse düzeltme onaylanır. Saha verisi 28 günlük olduğu için iyileşmeyi hemen görmeyi beklemeyin.
  5. Gerçek kullanıcı ölçümü kurun. Google’ın web-vitals JavaScript kütüphanesiyle değerleri kendi analiz aracınıza gönderebilir, hangi sayfa türünün yavaş olduğunu GA4’te izleyebilirsiniz.

Hız, teknik SEO listesinin yalnızca bir maddesi. Mobil uyumluluk için de mobil öncelikli indeksleme rehberine göz atın; Google sitenizi artık mobil tarayıcıyla değerlendiriyor.

Yapay zeka aramaları açısından Core Web Vitals

Google’ın üretken yapay zeka özellikleri için yayımladığı optimizasyon rehberi, AI Overviews ve AI Mode’un Google’ın temel sıralama ve kalite sistemleri üzerine kurulu olduğunu söylüyor ve iyi sayfa deneyimini öneriler arasında sayıyor. Yani yapay zeka yanıtları için ayrı bir hız standardı yok; geçerli olan aynı Core Web Vitals.

Pratik bir fark da var: Yapay zeka özetinden sitenize tıklayan kullanıcı, genellikle özetin ötesinde bir ayrıntı arıyor. Sayfa geç açılır veya içerik kayarsa geri dönüp başka bir kaynağa geçmesi çok kolay. Yapay zeka aramasında görünürlük için ayrıntılar: AI SEO nedir?

Sonuç

Core Web Vitals’ı bir puan yarışı olarak değil, gerçek kullanıcıların sitenizde ne yaşadığını gösteren bir sağlık raporu olarak okuyun. Önce Search Console’daki saha verisine bakın, en kötü metrikten başlayın ve düzeltmeyi şablon düzeyinde yapın. LCP için kapak görselini önceliklendirin, INP için JavaScript’i azaltın, CLS için her öğeye önceden yer ayırın. Bu üçü yerine oturduğunda geriye kalan iş, sıralamayı asıl belirleyen şeyi yapmak: okurun sorusuna en iyi yanıtı vermek.

Sık sorulan sorular

Core Web Vitals bir sıralama faktörü mü?

Google, Core Web Vitals'ın sıralama sistemlerinde kullanıldığını söylüyor. Ancak aynı belgeye göre Google her zaman en alakalı içeriği göstermeye çalışır; sayfa deneyimi zayıf olsa bile en alakalı sayfa öne çıkabilir. İyi değerler, benzer kalitede çok sayıda sayfanın yarıştığı aramalarda fark yaratır.

PageSpeed Insights'ta 100 puan almam gerekiyor mu?

Hayır. Google, yalnızca SEO için kusursuz puan peşinde koşmanın zamanınızı kullanmanın en iyi yolu olmayabileceğini açıkça yazıyor. Önemli olan Lighthouse puanı değil, gerçek kullanıcı verisinde (Search Console ve PageSpeed Insights'ın üst bölümü) üç metriğin 'İyi' eşiğinde olması.

FID'ye ne oldu?

First Input Delay (FID), 12 Mart 2024'te yerini Interaction to Next Paint (INP) metriğine bıraktı. INP yalnızca ilk etkileşimi değil, sayfadaki bütün tıklama, dokunma ve klavye etkileşimlerini ölçtüğü için daha kapsamlıdır.

Search Console'daki Core Web Vitals raporu neden boş?

Rapor, Chrome kullanıcılarından toplanan gerçek veriye (CrUX) dayanır. Site yeniyse veya trafiği azsa yeterli veri oluşmaz ve rapor boş kalır. Bu durumda PageSpeed Insights'taki laboratuvar ölçümlerini ve Chrome Geliştirici Araçları'nı kullanabilirsiniz.

Kaynaklar

Sırada okunacaklar

Reklam