Core Web Vitals Nedir? 2026 Optimizasyon Rehberi

Core Web Vitals, yükleme, etkileşim ve görsel kararlılığı ayrı ölçen LCP, INP ve CLS metrikleridir. Aşağıda üç metriği birlikte değerlendirmeyi ve doğru düzeltmeyi seçmeyi anlatıyoruz; ayrıntılı etkileşim tanılaması ve kod uygulaması için INP ölçüm ve optimizasyon rehberini kullanın.

Eşikler ve doğru değerlendirme birimi

Metrik	İyi	İyileştirme gerekiyor	Zayıf
LCP	≤2,5 saniye	>2,5 ve ≤4 saniye	>4 saniye
INP	≤200 ms	>200 ve ≤500 ms	>500 ms
CLS	≤0,1	>0,1 ve ≤0,25	>0,25

Alan değerlendirmesinde mobil ve masaüstünü ayırın; ziyaretlerin 75. yüzdeliğini izleyin. Üç metriğin de iyi sınırını karşılaması gerekir. Lighthouse performans puanı bir laboratuvar ölçümüdür; bu üç metriğin geçip geçmediğini alan verisinden kontrol edin. Eşikler ve yöntem için web.dev Web Vitals kaynağına bakın.

Google’ın sistemleri Core Web Vitals’ı kullanır; iyi değerler üst sıralama garantisi veya aynı içerikte otomatik kazanan seçimi değildir. Sayfa deneyimi açıklaması, performansı faydalı içerik ve diğer deneyim unsurlarıyla birlikte ele alır. Bir performans düzeltmesine sabit dönüşüm artışı yüzdesi bağlamayın.

Alan verisi ile laboratuvarı birlikte kullanın

PageSpeed Insights hem CrUX alan verisi hem Lighthouse laboratuvar sonucunu gösterebilir. Ekrandaki verinin URL’ye mi origin’e mi ait olduğunu kaydedin. Alan verisi bulunmaması iyi veya kötü performans kanıtı değildir. Search Console raporu URL gruplarıyla çalışır; bir örnek URL’yi grubun tüm üyeleri için kesin sonuç saymayın.

Sorunuz	Kullanılacak kanıt	Kanıtın sınırı
Kullanıcıların çoğunda deneyim nasıl?	Alan verisi, cihaz ve dönem	Düşük trafik nedeniyle bulunmayabilir
Sorunu hangi kaynak tetikliyor?	DevTools kaydı ve waterfall	Tek test koşuluna bağlıdır
Değişiklik gerileme yarattı mı?	Aynı koşulda önce/sonra laboratuvar kaydı	Gerçek kullanıcı dağılımını temsil etmez
Değişiklik yayında etkili oldu mu?	Yayın tarihiyle birlikte sonraki alan dönemleri	Kayan dönem eski ziyaretleri de içerir

Standart Lighthouse yükleme testi kullanıcı etkileşimi yapmadığı için INP ölçmez; TBT tanılama için yardımcıdır. Menüyü açma, arama yapma, filtreleme veya form kullanma gibi gerçek akışları ayrıca kaydedin. Laboratuvarı alan verisinin yerine koymayın.

LCP: önce gerçek öğeyi ve gecikme kaynağını bulun

LCP’yi yalnız görsel dosya boyutuna indirgemeyin. Sunucu yanıtı, kaynağın keşfi, indirilmesi ve öğenin ekrana çizilmesi ayrı darboğazlar olabilir. LCP optimizasyon kaynağı bu ayrımı açıklıyor.

Önce mobil görünümde LCP öğesini kayıttan belirleyin. Görselse doğru boyutu ve formatı karşılaştırın; ilk ekrandaki LCP görselini lazy-load etmeyin. HTML’de keşfedilebilir olduğunda gereksiz preload eklemeyin; CSS veya JavaScript arkasında geç keşfediliyorsa preload gereğini ölçün. fetchpriority yüksek öncelik için bir ipucudur; bütün görsellere uygulamak önceliklendirmeyi anlamsızlaştırır.

Görsel hızlı inmesine rağmen geç çiziliyorsa CSS, font, ana iş parçacığı veya görünürlüğü geciktiren kodu inceleyin. CDN, SSR veya bir performans eklentisi ekledikten sonra da LCP’yi yeniden ölçün.

INP: yalnız yüklemeyi değil, kullanıcı akışını da test edin

Etkileşim gecikmesini giriş gecikmesi, olay işleme ve sonraki çizim olarak ayırın. Modül bölmek indirme maliyetini azaltabilir; çalışmakta olan uzun görevi kendiliğinden parçalamaz. Ağır işin bölünmesi, uygun işin worker’a taşınması veya daha az DOM güncellemesi ölçülen darboğaza göre seçilir.

INP rehberindeki çalıştırılabilir örnek algoritma davranışını gösterir. Kendi sitenizdeki etkiyi alan INP verisiyle ölçün.

CLS: yer ayırın ve kaymanın kaynağını izleyin

CLS boyutsuz bir skordur; 0-1 arasında sabitlenmiş bir puan değildir. Sayfanın tüm ömründeki beklenmeyen kaymalar tek toplam olarak eklenmez: her pencere, aralarında bir saniyeden az olan kaymaları toplar ve en uzun pencere beş saniyede kapanır; CLS bu pencereler içindeki en yüksek toplamdır. Örneğin tek bir penceredeki 0,04 + 0,03 + 0,05 kayma 0,12 eder; ayrı pencerelerdeki değerleri buna eklemeyin.

Tıklama, dokunma veya tuş basımı gibi ayrık kullanıcı girdisinden sonraki 500 ms içinde gerçekleşen ilişkili kaymalar, ölçüm API’sinde hadRecentInput ile işaretlenip CLS hesabından dışlanabilir. Sürekli kaydırma veya sürükleme aynı istisnaya girmez. Bu nedenle yalnızca “kullanıcı etkileşiminden sonra oldu” demek kaymayı otomatik olarak beklenen yapmaz. CLS tanımı pencere hesabını, API sınırlarını ve kullanıcı girdisi ayrımını açıklar.

Görsel ve iframe alanlarını gerçek en-boy oranıyla rezerve edin. Reklam, çerez bildirimi ve geç gelen içerik için yer ayırın. Font değişiminde, font-display: swap kullansanız bile metrik uyumunu kontrol edin. Mobilde kayma kaydından etkilenen öğeyi ve onu hareket ettiren öğeyi ayrı inceleyin.

Düzeltme kayıt şablonu

Her deneyde URL, cihaz, viewport, bağlantı/CPU koşulu, test zamanı, yayın sürümü, sorunlu öğe, metrik ve yapılan değişikliği kaydedin. Tek değişkeni değiştirmek neden-sonuç yorumunu kolaylaştırır. Aynı koşulda birkaç tekrar yapıp değişkenliği not edin; yalnız en iyi koşuyu raporlamayın.

Örneğin LCP görselinin geç keşfedildiği gözlenirse önce bu keşfi düzeltin. Sonra LCP’nin ve diğer metriklerin gerileyip gerilemediğini kontrol edin. Bu bir deney tasarımıdır; burada Seobify veya müşteri için ölçülmüş hız kazanımı iddia edilmiyor.

Deney kaydı kontrol listesi

Boş JSON deney kaydını indirin. Dosyada ölçüm sonucu yoktur; eksik değeri null, karar durumunu unknown bırakın.

• Bir hipotez ve tek bir değişiklik seçin; sayfanın tam adresini, değişiklik öncesi ve sonrası sürümü yazın.
• Laboratuvar testinde tarayıcıyı, ekran boyutunu, CPU ve ağ koşulunu, sayfada yapılan adımları kaydedin; tüm tekrarları metrik, birim, zaman ve kanıt bağlantısıyla before_runs ve after_runs listelerine ekleyin.
• Alan verisi varsa kaynağını, sayfaya mı site geneline mi ait olduğunu, cihaz türünü, dönemi ve p75 değerlerini field bölümüne yazın; yoksa bu bölümü boş bırakın.
• LCP ve INP’yi milisaniye, CLS’yi birimsiz skor olarak yazın.
• Sayfanın doğru çalışıp çalışmadığını ve diğer metriklerde gerileme olup olmadığını kontrol edin; kararınızı, gerekçesini ve geri dönülecek sürümü yazın.

Önce/sonra karşılaştırması için iki kaydı aynı cihaz, kapsam ve test koşulunda alın. Kayıtta kişisel veri içeren bir iz dosyası veya bağlantı varsa paylaşmadan önce çıkarın.

Sık sorulan sorular

Alan verisi yoksa ne yapmalıyım?

Gerçek akışları laboratuvarda test edin; uygunsa gizlilik ve veri toplama kapsamı belirlenmiş gerçek kullanıcı ölçümü kurun. Eksik CrUX verisini başarı diye işaretlemeyin.

İyileştirme ne zaman görünür?

Laboratuvar değişikliği yeniden testte görülebilir. CrUX’un kayan döneminde önceki ziyaretler de yer aldığı için alan etkisi kademeli görünür; 28 gün kesin başarı süresi değildir.

Framework değiştirmek gerekli mi?

Önce darboğazı ölçün. Statik çıktı, SSR veya daha az istemci JavaScript’i faydalı olabilir; framework adı performans sonucu yerine geçmez.

Tarama ve indeksleme ile birlikte değerlendirme için teknik SEO kontrol listesine geçin. Uygulama kapsamı için SEO danışmanlığı hizmetini inceleyebilirsiniz.