Core Web Vitals: LCP, INP ve CLS Nasıl Ölçülür ve Düzeltilir

Kısaca: Core Web Vitals, Google'ın gerçek kullanıcı deneyimini tanımlamak için kullandığı üç metriktir: Largest Contentful Paint (LCP, yükleme, 2,5 sn veya altı iyi), Interaction to Next Paint (INP, yanıt verme hızı, 200 ms veya altı iyi) ve Cumulative Layout Shift (CLS, görsel kararlılık, 0,1 veya altı iyi). Her biri, mobil ve masaüstü ayrı olmak üzere 28 gün boyunca gerçek Chrome ziyaretlerinin 75. yüzdelik diliminde değerlendirilir. Google, bunların sıralama sistemlerinde kullanıldığını söylüyor, ancak önce alaka düzeyi gelir. Düzeltmek için her metriği parçalarına ayırın ve önce en büyük parçayı giderin.

Core Web Vitals tavsiyelerinin çoğu elli maddelik bir listeden ibaret. Bu yüzden ekipler bir sprint boyunca "performans" işi yapıyor ve rakamlar neredeyse hiç kıpırdamıyor. Metrikler bundan daha yapısal: her biri ölçülebilir birkaç parçaya bölünebilir ve sorunun büyük kısmından genellikle tek bir parça sorumludur.

Bu rehber, üç metriğin neyi ölçtüğünü, Ekim 2026 itibarıyla eşikleri, hangi veri kaynağına güvenmeniz gerektiğini, Google'ın sıralama konusunda gerçekte ne dediğini ve her metrik için önce teşhis koyan bir düzeltme planını anlatıyor. Kaynak, Google'ın web.dev üzerindeki kendi dokümantasyonudur.

Core Web Vitals neyi ölçer

web.dev'in Web Vitals genel bakışına göre, güncel ve kararlı set üç metrikten oluşur:

Eşikler, About PageSpeed Insights sayfasındaki tabloyla örtüşür.

75. yüzdelik dilim kuralı

Google bir sayfayı ortalamasına ya da tek bir teste göre değerlendirmez. Web.dev, ölçülecek iyi eşiğin "mobil ve masaüstü cihazlara göre ayrıştırılmış sayfa yüklemelerinin 75. yüzdelik dilimi" olduğunu söyler. Yalın ifadeyle: gerçek ziyaretlerin en az dörtte üçü "iyi" eşiğini karşılamalıdır. Bir sayfanın geçmesi için üç metrikte de 75. yüzdelik diliminde iyi sonuç alması gerekir.

Bunun sık gözden kaçan iki sonucu var:

1. Mobil ve masaüstü ayrıdır. Bir sayfa masaüstünde iyi, mobilde zayıf olabilir. Telefonların işlemcileri ve ağ bağlantıları daha yavaş olduğu için mobil genellikle daha zordur.
2. Sonucu yavaş ziyaretçileriniz belirler. Ziyaretçilerinizin dörtte biri zayıf bağlantıda eski Android telefonlar kullanıyorsa, puanınız onların deneyimidir. Yeni bir dizüstü bilgisayarda ofis Wi-Fi'ı ile test yapmak size çok az şey söyler.

INP, 2024'te FID'in yerini aldı

Interaction to Next Paint, 12 Mart 2024 tarihinde First Input Delay'in (FID) yerine Core Web Vital oldu. FID yalnızca tarayıcının ilk etkileşimi işlemeye başlamadan önceki gecikmeyi ölçüyordu. INP ise ziyaret boyunca tüm tıklamaları, dokunuşları ve tuş basışlarını, ayrıca bir sonraki kare boyanana kadar geçen tüm süreyi kapsar. FID'i kolayca geçen birçok site INP'de başarısız olur, çünkü yavaş olan kısım hep ilk girdiden sonraki işlerdi ve FID bunları saymıyordu. Eski bir raporda veya eklentide hâlâ FID görüyorsanız yok sayın.

Web.dev ayrıca kararlı Core Web Vitals'ın "yılda bir defadan fazla değişmeyeceğini" ve yeni aday metriklerin önce en az altı ay beklemede kaldığını belirtir; yani kurallar değişmeden önce haberiniz olur.

Saha verisi ve laboratuvar verisi

İki tür performans verisi vardır ve ekiplerin yanlış şeyi düzeltmesinin en yaygın nedeni bunları karıştırmaktır.

Google dokümantasyonundan birkaç ayrıntı:

• CrUX, 28 günlük kayan ortalamadır ve CrUX API dokümantasyonuna göre her gün güncellenir. Tüm origin için ya da tek bir URL için sorgulanabilir; telefon, masaüstü veya tablete göre filtrelenebilir.
• PageSpeed Insights ikisini de gösterir. Saha bölümü, CrUX'un önceki 28 günlük verisini kullanır. Bir URL'nin ziyareti çok azsa tüm origin verisine döner; origin de çok küçükse hiç saha verisi gösterilmez (About PageSpeed Insights). Laboratuvar bölümü ve 0-100 arası puan Lighthouse'tan gelir.
• Lighthouse INP'yi ölçemez. Web.dev, sayfaları "kullanıcı olmayan simüle bir ortamda" yükleyen araçların INP'yi ölçemeyeceğini belirtir ve laboratuvar vekili olarak Total Blocking Time'ı (TBT) önerir.
• Search Console'un Core Web Vitals raporu, benzer deneyime sahip sayfaları gruplar ve her gruba, o cihaz türü için en yavaş metriğin durumunu verir. Son 28 günün CrUX verisini kullanır (Core Web Vitals raporu yardımı).

Pratik kural: sorununuz olup olmadığına saha verisi karar verir, nedenini bulmanıza laboratuvar verisi yardım eder. Saha LCP'si zayıfken Lighthouse puanının 98 olması, gerçek kullanıcılarınızın simülasyondan daha kötü bir deneyim yaşadığı anlamına gelir; bunun nedeni çoğunlukla yavaş cihazlar, reklamlar, kişiselleştirme veya laboratuvar testinin tetiklemediği üçüncü taraf betikleridir.

Core Web Vitals sıralamada ne kadar önemli

Google'ın sayfa deneyimi dokümantasyonu her iki yönü de net biçimde ortaya koyuyor:

• "Core Web Vitals sıralama sistemlerimiz tarafından kullanılır" ve Google, "Arama'da başarı için" iyi Core Web Vitals değerleri elde etmeyi önerir.
• Sayfa deneyimi için "tek bir sinyal yoktur"; temel sıralama sistemleri çeşitli sinyallere bakar.
• "Google Arama, sayfa deneyimi zayıf olsa bile her zaman en alakalı içeriği göstermeye çalışır."
• Search Console'da veya üçüncü taraf araçlarda iyi sonuç almak, sayfalarınızın en üstte sıralanacağını garanti etmez.
• "Yalnızca SEO nedenleriyle kusursuz puan peşinde koşmak zamanınızı değerlendirmenin en iyi yolu olmayabilir."

Bizim yorumumuz: Core Web Vitals alakasız bir sayfayı alakalı bir sayfanın önüne geçirmez, ancak benzer kalitedeki sayfalar arasında fark yaratabilir ve kullanıcılar için doğrudan önemlidir. Fotoğrafını beş saniyede gösteren bir ürün sayfası ya da yarım saniye donan bir "Satın al" düğmesi, sıralamadan bağımsız olarak müşteri kaybettirir. Üçünde de "iyi" seviyesini hedefleyin, sonra puan kovalamayı bırakıp içeriğe dönün.

1. Adım: Hangi metriğin nerede başarısız olduğunu bulun

Kodu değiştirmeden önce:

1. Search Console'un Core Web Vitals raporunu açın, önce mobile bakın. Hangi metriğin başarısız olduğunu ve hangi URL gruplarının etkilendiğini (ürün sayfaları, blog yazıları, ana sayfa) not edin.
2. Başarısız olan her grup için temsili bir URL seçip PageSpeed Insights'ta çalıştırın. Saha verisinin o URL'ye mi yoksa origin'e mi ait olduğunu kontrol edin.
3. Her seferinde tek bir şablonu düzeltin. Core Web Vitals sorunları neredeyse her zaman şablon sorunudur: tüm ürün sayfaları aynı görsel bileşenini, aynı betikleri ve aynı yerleşimi paylaşır.

Ücretsiz Core Web Vitals checker aracımız hesap açmadan hızlı bir ilk okuma sağlar: telefon ziyaretçileri için 75. yüzdelik dilimdeki LCP, INP ve CLS değerlerini CrUX'tan çeker (girdiğiniz sayfa için Chrome'da yeterli veri varsa o sayfa, yoksa tüm origin'iniz için) ve sunucu yanıt süresini, HTML boyutunu, sıkıştırmayı, sayfa head bölümündeki render'ı engelleyen betikleri ve o sayfadaki görsel formatlarını ölçer; varsayılan olarak ana sayfanızı kullanır.

2. Adım: LCP'yi dört alt parçasına göre düzeltin

LCP, görünüm alanındaki en büyük görsel veya metin bloğunun render edilmesine kadar geçen süredir. Uygun öğeler arasında <img>, <video>, CSS url() arka plan görseli olan öğeler ve blok seviyesindeki metinler bulunur (web.dev'de LCP). Çoğu ürün ve açılış sayfasında bu, ana görseldir.

Optimize LCP, LCP'yi toplamı oluşturan dört parçaya böler:

Web.dev bu oranlara "katı kurallar değil, yönergeler" der, ancak teşhis için çok faydalıdırlar. Chrome DevTools'un Performance paneli, kaydedilmiş bir yükleme için bu dökümü gösterir. Payının çok üzerinde kalan parça, başlayacağınız yerdir.

Yüksek TTFB

TTFB; yönlendirmeleri, bağlantı kurulumunu ve sunucu işlemeyi içerir. Web.dev'in TTFB rehberi yaklaşık hedef olarak 0,8 saniye veya altını önerir, ancak TTFB'nin kendisinin bir Core Web Vital olmadığını da belirtir.

• HTML'i bir CDN'den sunun ve kısa süreli de olsa uçta (edge) önbelleğe alın. Core Web Vitals'ı iyileştirmenin en etkili yolları yazısı, TTFB'yi düşürmenin en iyi yolu olarak CDN'i gösterir.
• Reklam ve kısaltılmış bağlantılardan gelenler dahil yönlendirme zincirlerini kaldırın.
• Analitik veya kampanyalardan gelen benzersiz URL parametrelerine dikkat edin; bunlar her isteği önbellek ıskalamasına çevirir.
• Sayfa şablonundaki yavaş veritabanı sorgularını ve sunucu tarafı render'ı profilleyin.

Yüksek kaynak yükleme gecikmesi

Bu genellikle en büyük alt parçadır ve çoğunlukla düzeltmesi en ucuz olanıdır. Tarayıcı görselin indirmesini daha erken başlatabilirdi ama görselden haberi yoktu.

• LCP görselini ilk HTML'e normal bir <img src> veya srcset ile koyun. JavaScript ile eklenen veya tembel yükleme kütüphanesi için data-src kullanan görseller geç keşfedilir.
• LCP görselini asla tembel yüklemeyin (lazy-load). Ana görselden loading="lazy" özniteliğini kaldırın; web.dev açıkça "LCP görselinizi asla tembel yüklemeyin" der.
• LCP görseline fetchpriority="high" ekleyin ve bunu en fazla bir iki görselle sınırlayın.
• Görsel bir CSS arka planıysa <link rel="preload"> ile ve yüksek getirme önceliğiyle önceden yükleyin ya da bir <img>'e geçin.
• Bağlantıyı yeniden kullanmak için kritik görselleri mümkünse HTML ile aynı origin'den sunun.

Yüksek kaynak yükleme süresi

• Görseli, telefonların masaüstü görseli indirmemesi için srcset ve sizes ile gösterildiği boyutta sunun.
• AVIF veya WebP gibi modern formatlar kullanın ve düzgün sıkıştırın.
• Görselleri otomatik yeniden boyutlandıran ve dönüştüren bir görsel CDN'i kullanın.
• Aynı anda bant genişliği için yarışan diğer yüksek öncelikli indirmeleri azaltın.

Yüksek öğe render gecikmesi

Görsel gelmiştir ama bir şey tarayıcının onu boyamasını engellemektedir:

• Render'ı engelleyen CSS: azaltın, kritik olmayan stilleri erteleyin, yalnızca çok küçük kritik CSS'i satır içine alın.
• <head> içindeki senkron betikler: async veya defer ekleyin.
• İstemci tarafı render: sayfa içeriği yalnızca bir JavaScript framework'ü çalıştıktan sonra görünüyorsa sunucu tarafı render veya prerendering tercih edin.
• Hangi varyantı göstereceğine karar verene kadar sayfayı gizleyen A/B testi veya kişiselleştirme betikleri.
• Görselin hazır olduğu anda çalışan uzun JavaScript görevleri.

LCP bir görsel değil de metin bloğuysa kaynak yükleme gecikmesi ve süresi sıfırdır; sorun TTFB, render'ı engelleyen kaynaklar veya web fontlarıdır.

3. Adım: INP'yi üç aşamasına göre düzeltin

INP, ziyaret boyunca tıklamaları, dokunuşları ve tuş basışlarını (kaydırma veya üzerine gelme değil) kaydeder ve her 50 etkileşimde bir aykırı değeri yok sayarak en yavaş etkileşimi raporlar (web.dev'de INP). Her etkileşimin üç aşaması vardır:

Altta yatan sorun neredeyse her zaman uzun görevlerdir (long tasks): ana iş parçacığında 50 milisaniyeden uzun süren herhangi bir görev. Uzun bir görev çalışırken tarayıcı kullanıcıya yanıt veremez.

Girdi gecikmesini azaltın

• Başlangıçta daha az JavaScript yükleyin; betik değerlendirmesi, kullanıcıların ilk kez dokunmaya çalıştığı anda uzun görevler yaratır.
• Etiket yöneticinizi (tag manager) denetleyin. Web.dev, "kullanılmayan kod içeren eski etiketlerin kaldırılabileceğini" belirtir. Sohbet widget'ları, ısı haritaları, A/B testleri ve reklam betikleri çoğunlukla ana iş parçacığında ağır iş yapar.
• Sayfanın kullanmadığı kodu göndermeyi bırakmak için Chrome'un Coverage aracını ve kod bölmeyi (code splitting) kullanın.

İşleme süresini azaltın

• Olay işleyicisinde daha az iş yapın. Önce kullanıcının görmesi gerekeni güncelleyin, gerisini (analitik çağrıları, durum kaydetme, önerileri yeniden hesaplama) erteleyin.
• İş parçaları arasında ana iş parçacığına yol verin (yield). await scheduler.yield(), kalan işi yeni ve öncelikli bir görevde sürdürür. Her tarayıcıda desteklenmez; bu yüzden web.dev, bir Promise içine sarılmış setTimeout'a geri dönmeyi önerir (Optimize long tasks).
• Layout thrashing'den kaçının: aynı görevde stilleri değiştirdikten hemen sonra yerleşim değerlerini (örneğin offsetHeight) okumak, tarayıcıyı yerleşimi eşzamanlı hesaplamaya zorlar. Okuma ve yazmaları gruplayın.

Sunum gecikmesini azaltın

• DOM'u küçük tutun. Optimize INP, render işinin DOM boyutuyla birlikte arttığını açıklar.
• Uzun yorum listeleri veya alt bilgi gibi ekran dışı bölümlerin render'ını atlamak için content-visibility kullanın.
• Bir tıklamaya karşılık JavaScript'te büyük HTML parçaları render etmekten kaçının; yalnızca gerekeni render edin.

Yavaş etkileşimi bulmak için önce gerçek kullanıcı verisine bakın (hangi sayfalar başarısız), sonra Chrome DevTools'ta yeniden üretin: CPU kısıtlıyken şüpheli öğeye tıklarken bir Performance kaydı alın ve tıklamadan sonraki uzun görevlere bakın.

4. Adım: CLS'yi neden neden düzeltin

CLS, beklenmedik yerleşim kaymalarını toplar. Her kayma, görünüm alanının kayan kısmının oranı çarpı kayma mesafesi olarak puanlanır; kaymalar en fazla beş saniyelik pencerelerde gruplanır ve CLS en kötü penceredir (web.dev'de CLS). Bir tıklama, dokunuş veya tuş basışından sonraki 500 ms içindeki kaymalar, kullanıcı bunları beklediği için hariç tutulur. Kaydırma girdi sayılmaz; dolayısıyla biri kaydırırken kayan içerik yine de sayılır.

Optimize CLS uyarınca olağan nedenler ve çözümler:

Deneyimden iki not:

• Çöken boşluk da kayma yaratır. Web.dev, ayrılmış alanı kaldırmanın "içerik eklemek kadar CLS'ye yol açabileceği" konusunda uyarır. Bir reklam alanı boş kalıyorsa yer tutucuyu koruyun.
• Çerez bannerları ve promosyon çubukları sık görülen suçlulardır. Sayfayı aşağı itmek yerine içeriğin üzerine bindirin.

Geri/ileri önbelleğini unutmayın

Kullanıcılar Geri'ye bastığında bfcache'ten geri yüklenen sayfa anında görünür ve yeni yükleme kayması olmaz. Web.dev, bfcache uygunluğunu CLS'yi düşük tutmak için son derece etkili bir teknik olarak tanımlar. web.dev'in bfcache rehberine göre en yaygın iki engel: unload olay dinleyicileri (bunun yerine pagehide kullanın) ve hassas veri içermeyen sayfalardaki Cache-Control: no-store başlığı. Chrome DevTools'ta Application › Back/forward cache altında bir test bulunur.

Örnek bir uygulama (varsayımsal sayılar)

Aşağıdaki örnek varsayımsaldır, gerçek veri değildir. Uydurma bir online mobilya mağazası olan Fernwood Home'un ürün sayfası şablonu, mobilde Core Web Vitals değerlendirmesinden geçemiyor. 75. yüzdelik dilimdeki saha değerleri:

LCP: 4,6 sn

Kısıtlanmış bir telefon profilinde alınan DevTools kaydı, LCP öğesinin ana ürün fotoğrafı olduğunu gösteriyor. Döküm:

Kaynak yükleme gecikmesi hedef payının üç katından fazla olduğu için ilk o ele alınıyor. Çözümler: ilk fotoğrafı sunucu HTML'inde düz bir <img> olarak render etmek, üzerindeki loading="lazy" özniteliğini kaldırmak, fetchpriority="high" eklemek, srcset ile telefon boyutlarında AVIF ve WebP sunmak, takip parametrelerini önbellek anahtarında yok sayarak HTML'i CDN'de önbelleğe almak ve A/B betiğini defer ile yüklemek.

Yayından sonraki laboratuvar sonucu: TTFB 0,7 sn, yükleme gecikmesi 0,2 sn, yükleme süresi 0,6 sn, render gecikmesi 0,3 sn; LCP 1,8 sn.

INP: 340 ms

Saha verisi ürün sayfasını işaret ediyor; DevTools'ta yeniden üretince yavaş etkileşimin "Sepete ekle" düğmesi olduğu görülüyor. Kayıtta yaklaşık 90 ms girdi gecikmesi (aynı anda çalışan bir sohbet widget'ı ve iki takip etiketi), 190 ms işleme (işleyici tüm sepet çekmecesini yeniden render ediyor ve üç analitik çağrısını eşzamanlı gönderiyor) ve 60 ms sunum gecikmesi var.

Çözümler: sohbet widget'ını yalnızca ilk kullanıcı etkileşiminden sonra yüklemek, önce sepet çekmecesi güncellemesini göstermek, ardından analitik ve öneri güncellemelerinden önce yol vermek. Aynı kısıtlı profilde laboratuvar ölçümü: yaklaşık 150 ms.

CLS: 0,21

Üç neden var: yüklemeden sonra fiyatın üstüne eklenen bir yorum yıldızı widget'ı, ürün başlığını yeniden saran bir web fontu değişimi ve boyutsuz küçük resimler. Çözümler: yorum widget'ının yüksekliğine yer ayırmak, başlık fontunu önceden yüklemek ve yedek fontu size-adjust ile ayarlamak, her küçük resme width ve height eklemek. Laboratuvar CLS: 0,04.

Sonucu okumak

Laboratuvar rakamları düzeltmelerin işe yaradığını doğrular. Değerlendirmeye karar veren saha rakamları ise 28 günlük pencerede yeni ziyaretler eskilerin yerini aldıkça hareket eder. Fernwood yaklaşık dört hafta boyunca kademeli bir değişim beklemeli, ardından Search Console raporunda Start tracking'e tıklayarak yine 28 gün süren doğrulamayı başlatmalıdır. Saha LCP'si 1,8 sn yerine örneğin 2,3 sn çıkarsa bu normaldir: gerçek telefonlar ve ağlar hiçbir laboratuvar profilinden hızlı değildir.

Sık yapılan hatalar

• Lighthouse puanının peşinden koşmak. 0-100 arası puan bir laboratuvar özetidir. Google'ın değerlendirmesi 75. yüzdelik dilimdeki saha verisini kullanır.
• Yalnızca masaüstünde test etmek. Mobil ayrı değerlendirilir ve genellikle ilk o başarısız olur.
• Her şeyi tembel yüklemek. Ekranın altındaki görselleri tembel yüklemek iyidir; ana görseli tembel yüklemek ise zayıf LCP'nin en yaygın nedenlerinden biridir.
• Yalnızca ana sayfayı düzeltmek. Trafiğin çoğu genellikle ürün, kategori veya makale şablonlarına düşer. En çok başarısız URL'si olan şablonları düzeltin.
• Bir betik daha eklemek. Her etiket, widget ve test betiği ana iş parçacığı için yarışır. Eklediğiniz her biri için bir tane çıkarın.
• Anında sonuç beklemek. Saha verisinin bir yayını tam yansıtması yaklaşık 28 gün sürer.
• Mobil temelleri göz ardı etmek. Viewport etiketi olmayan veya aşırı büyük görseller içeren bir sayfa, hiçbir optimizasyon yapılmadan önce telefonlarda yavaştır. Ücretsiz mobil uyumluluk testi bu temelleri kontrol eder.

Bir saatlik başlangıç kontrol listesi

1. Alan adınızı ücretsiz Core Web Vitals checker ile çalıştırarak telefonlardaki gerçek kullanıcı LCP, INP ve CLS değerlerini; ayrıca sunucu yanıt süresini, sıkıştırmayı ve engelleyen betikleri görün.
2. Search Console'un mobil Core Web Vitals raporunu açın ve başarısız URL gruplarını listeleyin.
3. Başarısız her grup için bir URL'yi PageSpeed Insights'ta çalıştırın ve sahada hangi metriğin başarısız olduğunu not edin.
4. LCP için bir DevTools kaydı alın ve dört alt parçayı yazın. Önce en büyüğünü düzeltin.
5. INP için yavaş etkileşimi ve ardından gelen uzun görevleri bulun.
6. CLS için boyutsuz görselleri, geç eklenen içeriği ve fontları kontrol edin.
7. Yayınlayın, laboratuvarda doğrulayın, ardından iki ve dört hafta sonra saha verisine bakın.

Core Web Vitals, teknik sağlığın yalnızca bir parçasıdır. Teknik SEO denetimi rehberimiz, bunları tarama, indeksleme, yönlendirmeler ve yapılandırılmış veriyle birlikte bağlamına oturtur.

Searvia, Core Web Vitals'ta nasıl yardımcı olur

Ücretsiz Core Web Vitals checker hesap gerektirmez ve sitenizin gerçek kullanıcı tablosunu bir dakikadan kısa sürede verir. Searvia içinde, bir web sitesi projesinin Page speed sekmesi en çok ziyaret edilen sayfalarınızda her hafta PageSpeed Insights çalıştırır ve LCP, INP ve CLS için hem laboratuvar puanlarını hem de son 28 günün gerçek Chrome kullanıcı verisini gösterir. Düzeltmeler kazandırdıkları süreye göre sıralanır ve Write a fix plan for my files with AI en üstteki maddeleri teknoloji yığınınıza göre adım adım değişikliklere dönüştürür (3 kredi). Hız verisinin yanında tıklamaları ve konumları görmek için Search Console bağlantısını kurun; böylece daha hızlı bir şablonun gerçekten daha fazla trafik getirip getirmediğini anlayabilirsiniz. Sayfa hızı yardım rehberi kurulumu yaklaşık iki dakikada anlatır.