Core Web Vitals Nedir? LCP, INP ve CLS ile Web Sitesi Hız Optimizasyonu Rehberi

Onur Ertem
16 Eylül 2026
Güncellendi: 28 Eylül 2026

Kısaca: Core Web Vitals, Google’ın gerçek kullanıcı deneyimini üç metrikle değerlendirdiği settir: yükleme için LCP, etkileşime yanıt için INP ve görsel kararlılık için CLS. İyi bir deneyim için LCP’nin 2,5 saniye, INP’nin 200 milisaniye, CLS’nin 0,1 değerinde ya da altında kalması ve bu sınırların ziyaretlerin en az dörtte üçünde tutturulması önerilir. Hız optimizasyonu, hangi metriğin neden takıldığını bulmakla başlar.

Core Web Vitals, Google’ın bir web sayfasındaki gerçek kullanıcı deneyimini üç ölçüyle değerlendirdiği metrik setidir: yükleme için LCP, etkileşime yanıt için INP ve görsel kararlılık için CLS. İyi bir deneyim için LCP’nin 2,5 saniye, INP’nin 200 milisaniye, CLS’nin ise 0,1 değerinde ya da altında kalması ve bu sınırların ziyaretlerin en az dörtte üçünde tutturulması önerilir. “Core Web Vitals nedir” sorusunun pratik karşılığı şudur: bu üç metrik bir test puanı değil, sitenin gerçek ziyaretçilere nasıl hissettirdiğinin ölçüsüdür.

Web sitesi hız optimizasyonu da bu yüzden bir aracın verdiği puanı yükseltmekle değil, üç metrikten hangisinin neden takıldığını bulmakla başlar. Bu rehberde her metriğin neyi ölçtüğü, web.dev’in tanımladığı eşikler, PageSpeed Insights ile Search Console raporlarının okunuşu ve metrikleri en sık bozan nedenlerin çözümleri anlatılır. Anlatılanlar WordPress, hazır altyapı ya da özel yazılımla kurulmuş her site için geçerlidir; değişen sadece uygulama araçlarıdır.

Core Web Vitals Nedir ve Hangi Deneyimi Ölçer?

Core Web Vitals, Google’ın Web Vitals girişimi içinde tüm web sayfaları için geçerli saydığı ve yükleme, etkileşim ile görsel kararlılığı ölçen üç temel metriktir. Diğer Web Vitals metrikleri belirli araçlara ya da senaryolara özgü kalırken bu üçü Search Console, PageSpeed Insights ve Chrome geliştirici araçlarında ortak dil olarak kullanılır. Set kalıcı değildir; web.dev, tanım ve eşiklerdeki değişikliklerin önceden duyurulacağını ve yıllık bir düzene bağlı olacağını belirtir.

Setteki son büyük değişiklik 2024’te yaşandı: sadece ilk etkileşimin gecikmesine bakan FID emekliye ayrıldı, yerine sayfadaki tüm etkileşimleri izleyen INP kararlı metrik olarak geçti. Eski rehberlerde FID eşiklerinin hâlâ yer alması bu yüzden yanıltıcıdır. Güncel set üç kısaltmayla akılda tutulabilir:

LCP (Largest Contentful Paint): Ekranın ilk görünen bölümündeki en geniş içerik öğesinin yüklenip çizilme süresi; yükleme hızını temsil eder.
INP (Interaction to Next Paint): Tıklamaya, dokunmaya ya da tuşa basılmasına sayfanın görsel olarak cevap verme süresi; tepki hızını temsil eder.
CLS (Cumulative Layout Shift): Sayfadaki öğelerin beklenmedik biçimde yer değiştirme miktarı; görsel kararlılığı temsil eder.

LCP, INP ve CLS Eşikleri: İyi, İyileştirme Gerekli ve Zayıf

Üç metriğin “iyi” sayılması için web.dev’in Core Web Vitals sayfasında belirtilen sınırlar LCP’de 2,5 saniye, INP’de 200 milisaniye ve CLS’de 0,1’dir. Google Search Console da aynı sınırları üç kademeli bir tabloyla uygular:

Metrik	Ölçtüğü deneyim	İyi	İyileştirme gerekli	Zayıf
LCP	Ana içeriğin ekranda belirmesi	En fazla 2,5 saniye	2,5 ile 4 saniye arası	4 saniyeden uzun
INP	Etkileşimden sonraki ilk görsel güncelleme	En fazla 200 milisaniye	200 ile 500 milisaniye arası	500 milisaniyeden uzun
CLS	Öğelerin beklenmedik kayması	En fazla 0,1	0,1 ile 0,25 arası	0,25’ten yüksek

Eşikler tek bir ziyarete değil, sayfa yüklemelerinin 75. yüzdelik dilimine uygulanır ve mobil ile masaüstü ayrı ayrı değerlendirilir. Bunun pratik anlamı şudur: ziyaretlerin dörtte üçünde LCP 2,5 saniyenin altındaysa sayfa bu metrikten geçer, kalan yavaş ziyaretler sonucu tek başına bozmaz. Değerlendirmeyi geçmek için üç metriğin üçü de iyi aralıkta olmalıdır; ikisi iyi, biri zayıf olan bir sayfa geçmiş sayılmaz.

LCP Nedir? Ana İçeriğin Ekrana Gelme Süresi

LCP, sayfa açılmaya başladığı andan görünür alandaki en büyük görselin, videonun ya da metin bloğunun ekrana çizildiği ana kadar geçen süredir. Ziyaretçinin “sayfa geldi” hissine en yakın ölçü olduğu için yükleme performansının temsilcisi kabul edilir. Aday olabilen öğeler img etiketleri, SVG içindeki image öğeleri, videoların kapak görseli ya da ilk karesi, CSS’te url() ile yüklenen arka plan görselleri ve metin içeren blok öğelerdir. Tüm ekranı kaplayan, arka plan niteliğindeki öğeler hesaba katılmaz.

web.dev, LCP süresini toplandığında tam değeri veren dört alt parçaya ayırır. Hangi parçanın uzun sürdüğünü bilmek, hangi düzeltmenin gerçekten işe yarayacağını belirler:

İlk bayta kadar geçen süre (TTFB): Tarayıcının HTML belgesinin ilk baytını sunucudan alması.
Kaynak yükleme gecikmesi: HTML geldikten sonra LCP görselinin indirilmeye başlamasına kadar geçen boşluk.
Kaynak yükleme süresi: LCP görselinin ya da metin için gereken fontun indirilmesi.
Öğe oluşturma gecikmesi: Kaynak indikten sonra öğenin ekrana çizilmesine kadar geçen bekleme.

Adında “gecikme” geçen iki parçanın sıfıra yaklaşması hedeflenir. Darboğaz başka bir parçadaysa görseli sıkıştırmak LCP’yi düşürmez; kazanılan süre çoğu zaman oluşturma gecikmesine kayar.

INP Nedir? Sayfanın Etkileşime Tepki Hızı

INP, sayfadaki tıklama, dokunma ve klavye etkileşimlerinden sonra tarayıcının bir sonraki kareyi ekrana çizmesine kadar geçen süreyi ölçer ve ziyaret boyunca gözlenen en yavaş etkileşimi raporlar. Çok sayıda etkileşim içeren ziyaretlerde aykırı değerleri ayıklamak için her 50 etkileşimde en yüksek bir değer dışarıda bırakılır. Kaydırma ve fareyle bir öğenin üzerine gelme INP’ye dahil değildir; menü açmak, sepete ürün eklemek ya da form alanına yazmak ise dahildir.

Bir etkileşimin gecikmesi üç aşamadan oluşur ve her aşamanın kaynağı farklıdır. Giriş gecikmesi, ana iş parçacığı başka bir işle, çoğunlukla indirilen JavaScript’in çözümlenmesi ve çalıştırılmasıyla meşgulken yaşanır. İşleme süresi etkileşime bağlı kodun çalışmasıdır; sunum gecikmesi ise tarayıcının sonucu ekrana çizmesi için geçen zamandır. Sayfa yüklenirken yapılan etkileşimler ana iş parçacığının en yoğun anına denk geldiği için çoğu zaman en kötü INP değerlerini üretir.

CLS Nedir? İçerik Neden Yerinden Kayar?

CLS, görünür alandaki öğelerin ziyaretçi beklemeden yer değiştirmesinin toplam etkisini gösteren, birimi olmayan bir puandır. Okunan satırın aniden aşağı itilmesi ya da tıklanmak üzere olan butonun yerine başka bir öğenin gelmesi CLS’nin yakaladığı deneyimdir. Kullanıcı girişinden sonraki 500 milisaniye içinde oluşan kaymalar beklenen değişiklik sayılıp hesaba katılmaz. Buna karşılık kaydırma sırasında sonradan yüklenen bir içeriğin metni itmesi beklenmedik kayma olarak sayılır.

web.dev’in listelediği en yaygın CLS nedenleri boyutu belirtilmemiş görseller, yer ayrılmamış reklam, gömülü içerik ve iframe’ler, sayfaya sonradan eklenen öğeler ve web fontlarıdır. Çözüm çoğu durumda aynı ilkeye dayanır: tarayıcıya öğenin kaplayacağı alanı içerik gelmeden önce bildirmek. Görsellere width ve height nitelikleri ya da CSS aspect-ratio tanımlamak bunun en basit örneğidir.

Saha Verisi ile Laboratuvar Verisi Arasındaki Fark

Saha verisi siteyi gerçekten ziyaret eden Chrome kullanıcılarından toplanan ölçümlerdir; laboratuvar verisi ise tek bir simüle cihaz ve ağ koşulunda yapılan testin sonucudur. Google’ın geçti-kaldı kararı gerçek kullanıcı ölçümlerinden çıkar, PageSpeed Insights’taki 0–100 arası performans puanı ise Lighthouse’un laboratuvar testinden hesaplanır. İki kaynağın aynı sayfa için farklı sonuç vermesi bir hata değil, ölçüm yönteminin doğal sonucudur. Farkın en sık görülen nedenleri şunlardır:

Cihaz ve bağlantı çeşitliliği: Laboratuvar tek bir orta seviye telefonu taklit eder; gerçek ziyaretçiler çok farklı cihaz ve bağlantılarla gelir.
Önbellek durumu: Test sayfayı boş önbellekle açar; geri dönen ziyaretçide kaynakların bir kısmı zaten tarayıcıda bulunur.
Geri-ileri önbelleği: Geri tuşuyla dönülen sayfalar neredeyse anında açılır; laboratuvar testi bu durumu hesaba katmaz.
Kişiselleştirilmiş içerik: Oturum açmış kullanıcıya, çerez onayına ya da ekran boyutuna göre değişen içerik farklı LCP öğeleri üretebilir.
INP’nin etkileşim gerektirmesi: Yükleme testi sayfaya tıklamadığı için INP ölçemez; yerine yükleme sırasındaki engellenme süresini gösteren TBT metriği bir ipucu olarak kullanılır.

Laboratuvar verisi sorunu yeniden üretmek ve düzeltmeyi anında denemek için değerlidir; başarının ölçüsü ise saha verisidir. PageSpeed Insights belgeleri de yeşil laboratuvar puanının gerçek kullanıcı deneyiminin iyi olduğu anlamına gelmediğini açıkça vurgular.

PageSpeed Insights ve Search Console Raporu Nasıl Okunur?

PageSpeed Insights tek bir URL’yi hem saha hem laboratuvar verisiyle inceler; Search Console tarafındaki rapor ise benzer sayfaları gruplayarak site genelindeki tabloyu gösterir. Bir sayfanın durumu şu sırayla değerlendirildiğinde yanlış yorumların önüne geçilir:

PageSpeed Insights üzerinde önce mobil sekmesi açılır ve üst bölümdeki gerçek kullanıcı verisinde üç metriğin geçip geçmediğine bakılır. Bu veri önceki 28 günü kapsar.
Sayfanın kendi verisi yetersizse araç kaynak düzeyine, yani alan adının tüm sayfalarına ait veriye geçer; bu durumda sonuç o sayfaya özgü değildir.
Laboratuvar bölümünde LCP öğesinin hangi görsel ya da metin olduğu ve ilk ekranı bekleten dosyalar not edilir.
Search Console’da Core Web Vitals raporu açılır; URL grupları mobil ve masaüstü için ayrı ayrı “Zayıf”, “İyileştirme gerekli” ve “İyi” olarak listelenir.
Düzeltme yayına alındıktan sonra raporda doğrulama başlatılır; Google sorunu 28 günlük bir izleme süresince takip eder.

Search Console’da bir URL grubunun durumunu en kötü metriği belirler; CLS’si iyi ama INP’si zayıf olan grup zayıf görünür. Rapor sadece dizine eklenmiş ve yeterli ziyaret verisi olan sayfaları içerir, bu yüzden az trafik alan yeni sitelerde “Veri yok” ekranı olağandır. Raporun tüm ayrıntıları Google’ın Core Web Vitals raporu yardım sayfasında yer alır. Hız sorunu dizine ekleme ve tarama hatalarıyla birlikte görülüyorsa konu teknik SEO kapsamında bütün olarak ele alınır.

Ölçüm Sonuçlarını Birlikte Yorumlayalım

PageSpeed Insights bağlantısı ya da Search Console’daki Core Web Vitals ekranının görüntüsü WhatsApp’tan iletildiğinde hangi metriğin, hangi sayfa grubunda ve hangi nedenle takıldığını birlikte değerlendirelim.

WhatsApp 0532 690 9924

Metrikleri Bozan Yaygın Nedenler ve Çözümleri

Core Web Vitals sorunlarının büyük kısmı birkaç tekrar eden nedene dayanır ve her neden belirli bir metriği etkiler. Aşağıdaki tablo nedeni, etkilediği metriği ve platformdan bağımsız çözüm yönünü eşleştirir:

Neden	Etkilediği metrik	Çözüm yönü
Yavaş sunucu yanıtı, art arda yönlendirmeler	LCP (TTFB)	Sayfa önbelleği, yönlendirme zincirini kısaltma, ziyaretçiye yakın sunucu veya CDN
LCP görselinin geç keşfedilmesi (CSS arka planı, JavaScript ile ekleme)	LCP (yükleme gecikmesi)	Görseli HTML içinde img olarak vermek ya da preload ile önceden bildirmek
İlk ekrandaki ana görselin tembel yüklenmesi	LCP	Bu görselden loading=”lazy” kaldırılır, gerekirse fetchpriority=”high” eklenir
Büyük ölçülü, eski formatlı görseller	LCP (yükleme süresi)	Ekrana uygun ölçü, WebP veya AVIF, srcset ile cihaza göre sürüm
Oluşturmayı engelleyen CSS ve JavaScript	LCP	Kritik CSS’i öne almak, kullanılmayan kodu ayıklamak, script’leri ertelemek
Uzun JavaScript görevleri, ağır üçüncü taraf kodlar	INP	Görevleri parçalara bölmek, gereksiz takip ve sohbet kodlarını azaltmak
Çok büyük DOM, iç içe geçmiş sayfa oluşturucu katmanları	INP	Daha sade şablon, gereksiz sarmalayıcı öğeleri kaldırmak
Boyutsuz görsel, reklam ve iframe alanları	CLS	width/height ya da aspect-ratio ile yer ayırmak
Web fontunun geç gelmesi	CLS, LCP	Kritik fontu önceden yüklemek, uygun yedek font ve font-display ayarı
Sonradan beliren duyuru ve çerez çubukları	CLS	Alanı baştan ayırmak ya da içeriği itmeyen katman olarak göstermek

Tablodaki çözümlerin bazıları dikkatli uygulanmazsa ters etki yapar. web.dev’e göre LCP görseli hiçbir koşulda tembel yüklenmemeli, fetchpriority=”high” ise en fazla bir iki görselde kullanılmalıdır; her görsele yüksek öncelik vermek önceliklendirmeyi anlamsız kılar.

Platformdan Bağımsız Web Sitesi Hız Optimizasyonu Adımları

Etkili bir web sitesi hız optimizasyonu, altyapı ne olursa olsun ölçüm, önceliklendirme, düzeltme ve doğrulama döngüsüyle ilerler. Aşağıdaki sıra en çok kazanç getiren işlerden başlayacak şekilde kurgulanmıştır:

Takılan metriği belirlemek: Saha verisinde hangi metriğin ve hangi cihaz türünün geride kaldığı bulunur; en çok ziyaret alan şablonlar (ana sayfa, hizmet, ürün, blog) önce ele alınır.
Sunucu yanıtını hızlandırmak: web.dev, çoğu site için TTFB’nin 0,8 saniye veya altında olmasını kaba bir hedef olarak gösterir. Sayfa önbelleği, güncel sunucu yazılımı ve gereksiz yönlendirmelerin kaldırılması bu adımın parçasıdır.
LCP öğesini erkenden yüklemek: Ana görsel HTML’de keşfedilebilir hâle getirilir, tembel yüklemeden çıkarılır ve yüksek öncelik verilir.
Görselleri hafifletmek: Her görsel gösterileceği ölçüde ve modern formatta sunulur; ilk ekran dışındakiler tembel yüklenir.
Oluşturmayı engelleyen dosyaları azaltmak: İlk ekran için gereken CSS öne alınır, geri kalan CSS ve JavaScript ertelenir ya da ayıklanır.
Üçüncü taraf kodları gözden geçirmek: Takip, sohbet, harita ve video gömme kodlarının her biri ana iş parçacığına yük bindirir; kullanılmayanlar kaldırılır, kalanlar ihtiyaç anına ertelenir.
Kayan öğelere yer ayırmak: Görsel, reklam, iframe ve font kaynaklı kaymalar boyut tanımlarıyla önlenir.
Doğrulamak: Değişiklik laboratuvarda hemen yeniden ölçülür; saha verisindeki etki 28 günlük pencere doldukça görünür hâle gelir.

WordPress sitelerde bu adımlar tema, eklenti, sayfa oluşturucu ve sunucu ayarları üzerinden uygulanır; önbellek katmanları ve eklenti yükü gibi WordPress’e özgü başlıklar WordPress site hızlandırma sayfasında ayrıca anlatılır. Barındırma tercihinin sunucu yanıt süresine etkisi ise hosting seçimi rehberinde ele alınır.

Core Web Vitals Google Sıralamasını Etkiler mi?

Google, Core Web Vitals’ın sıralama sistemleri tarafından kullanıldığını belirtir; ancak bu metrikleri tek başına belirleyici bir sinyal olarak değil, iyi sayfa deneyiminin bir parçası olarak tanımlar. Google’ın sayfa deneyimi belgesine göre sıralamada kullanılan tek bir “sayfa deneyimi sinyali” yoktur ve Search Console raporunda iyi sonuç almak üst sıralarda yer almanın garantisi değildir. Aynı belge, sırf SEO için kusursuz puan peşinde koşmanın zaman kaybı olabileceği uyarısını da içerir.

Core Web Vitals nedir sorusu çoğu zaman sıralama sorusuyla birlikte sorulur ve Google’ın tutumu öncelik sırasını netleştirir: sayfa aranan sorunun cevabını vermiyorsa hız tek başına sıralama kazandırmaz. Hızın etkisi çoğu zaman önce ziyaretçide görülür; menünün, formun ve sepetin gecikmeden çalışması doğrudan iletişim ve satış deneyimini belirler. Hızın SEO uyumunun yalnızca bir katmanı olduğunu gösteren diğer başlıklar için SEO uyumlu site kontrol listesi yazısına bakılabilir.

Hız Çalışmasında Sık Yapılan Hatalar

En yaygın hata, laboratuvar puanını hedef, saha verisini ise ayrıntı saymaktır. Pratikte sık karşılaşılan diğer yanlışlar şunlardır:

Sadece masaüstünde test etmek: Eşikler mobil ve masaüstünde ayrı değerlendirilir; sorun çoğunlukla daha zayıf cihazların olduğu mobil tarafta ortaya çıkar.
Tek ölçümle karar vermek: Laboratuvar sonucu ağ ve donanım koşullarına göre her testte değişebilir; birkaç ölçüm ve saha verisi birlikte okunur.
Tüm görselleri tembel yüklemek: İlk ekrandaki ana görsel de bu kapsama girince LCP gecikir.
Aynı işi yapan araçları üst üste eklemek: Birden fazla önbellek veya küçültme aracı birbirini bozabilir ve sayfaya yeni JavaScript yükü getirebilir.
Tek URL sonucunu grup sonucuyla karıştırmak: Search Console benzer URL’leri gruplar; PageSpeed Insights’taki tek sayfanın değeri grupla birebir örtüşmeyebilir.
Düzeltmenin ertesi günü saha verisinde sonuç beklemek: Gerçek kullanıcı verisi 28 günlük pencereyle güncellenir.
Puan için işlevden vazgeçmek: İletişim formu, harita ya da video gibi gerekli öğeleri silmek yerine ihtiyaç anında yüklemek daha doğru bir yoldur.

Sitenin Hız Önceliklerini Birlikte Belirleyelim

Hangi sayfanın, hangi metrikte ve hangi nedenle geride kaldığı netleşmeden yapılan hız çalışması çoğu zaman puanı oynatır ama ziyaretçinin yaşadığı gecikmeyi değiştirmez. Site adresi WhatsApp’tan iletildiğinde saha verisi üzerinden öncelik sırasını birlikte çıkaralım.

WhatsApp 0532 690 9924

Sıkça Sorulan Sorular

LCP, INP ve CLS için iyi değerler kaç olmalı?

İyi sınırlar LCP için 2,5 saniye, INP için 200 milisaniye ve CLS için 0,1’dir. Bu değerlerin ziyaretlerin en az dörtte üçünde, telefon ve bilgisayar için ayrı ayrı tutturulması önerilir.

Core Web Vitals nedir?

Core Web Vitals; yükleme hızı (LCP), etkileşime tepki (INP) ve görsel kararlılık (CLS) olmak üzere üç metrikten oluşan ve sayfa deneyimini gerçek ziyaretçi verisiyle ölçen settir. Değerler siteyi ziyaret eden Chrome kullanıcılarından toplanır ve Search Console ile PageSpeed Insights’ta raporlanır.

PageSpeed Insights puanı 100 olmadan site hızlı sayılmaz mı?

Sayılabilir; 0–100 arası puan tek bir simüle testten hesaplanan laboratuvar sonucudur. Core Web Vitals değerlendirmesi ise gerçek kullanıcı verisine dayanır ve puanı 100 olmayan bir sayfa saha verisinde üç metriği de geçebilir.

INP ile FID arasındaki fark nedir?

FID sadece ilk etkileşimin başlama gecikmesini ölçüyordu, INP ise ziyaret boyunca tüm tıklama, dokunma ve tuş etkileşimlerini ekran güncellenene kadar izler. 2024’ten bu yana Core Web Vitals setinde FID’in yerini INP almıştır.

Search Console'da Core Web Vitals bölümü neden "Veri yok" gösteriyor?

Rapor, Chrome kullanıcılarından yeterli miktarda gerçek ziyaret verisi toplanmış ve dizine eklenmiş sayfaları gösterir. Yeni ya da az trafik alan sitelerde bu eşik aşılmadığı için rapor boş kalabilir; bu durumda tek tek URL’ler PageSpeed Insights ile test edilir.

Hız düzeltmesinin etkisi ne zaman görülür?

Laboratuvar testinde etki yayından hemen sonra görülür. Saha verisi ise son 28 günü kapsadığı için gerçek kullanıcı değerlerinin tamamen yenilenmesi yaklaşık bu süre kadar zaman alır.

Core Web Vitals'ı geçen site Google'da üst sıraya çıkar mı?

Hayır, bunun bir garantisi yoktur. Google, Core Web Vitals’ın sıralama sistemlerinde kullanıldığını ancak iyi raporların üst sıra garantisi olmadığını belirtir; içeriğin aranan soruya verdiği cevap belirleyici olmaya devam eder.

Mobil sonuçlar neden masaüstünden daha kötü çıkar?

Mobil ziyaretçilerin önemli bir kısmı daha düşük işlem gücüne sahip cihazlar ve değişken bağlantılarla gelir; laboratuvar testi de mobilde orta seviye bir telefonu ve yavaş ağı taklit eder. Ağır JavaScript ve büyük görseller bu koşullarda masaüstüne göre çok daha belirgin gecikme yaratır.