Core Web Vitals nedir? LCP, INP ve CLS nasıl ölçülür, nasıl iyileştirilir

Core Web Vitals (Türkçe arayüzde Önemli Web Verileri), Google'ın bir sayfanın gerçek kullanıcılar için ne kadar hızlı yüklendiğini, ne kadar hızlı tepki verdiğini ve görsel olarak ne kadar kararlı olduğunu ölçen üç metriktir: LCP, INP ve CLS. 2021'den beri sıralama sinyalleri arasındadır ve Search Console'da ayrı bir raporu vardır. Bu rehber üç metriğin anlamını, eşik değerlerini, ölçüm yöntemlerini ve en sık karşılaşılan sorunların çözümlerini anlatır.

Core Web Vitals nedir?

Google 2020'de Web Vitals adıyla bir dizi kullanıcı deneyimi metriği tanımladı ve bunların üçünü "core" (temel) olarak ayırdı. Fikir şuydu: sayfa hızı konuşulurken herkes farklı bir şeyi ölçüyordu; Google, kullanıcının gerçekten hissettiği üç şeyi standartlaştırdı. Sayfa ne zaman "yüklendi" görünüyor, tıkladığımda ne kadar sürede tepki veriyor ve yüklenirken içerik zıplıyor mu?

Metrikler gerçek Chrome kullanıcılarından anonim olarak toplanır (Chrome User Experience Report, CrUX) ve Search Console'un Önemli Web Verileri raporunda site bazında gösterilir. Google bir sayfayı "iyi" sayması için üç metriğin de kullanıcıların yüzde 75'inde eşik değerin altında kalmasını ister.

Üç metrik: LCP, INP, CLS

LCP kullanıcının "sayfa açıldı" dediği andır. Çoğu sitede bu öğe hero görseli, büyük bir başlık ya da bir video kapağıdır. Sunucu yavaşsa, görsel büyükse ya da CSS yüklenmeden içerik çizilemiyorsa LCP uzar.

INP, 2024'te FID'in (First Input Delay) yerini aldı. Kullanıcı bir menüye dokunduğunda, bir sekmeyi değiştirdiğinde, bir formu gönderdiğinde ekranın güncellenmesi ne kadar sürüyor? Ağır JavaScript, ana iş parçacığını kilitleyen üçüncü taraf betikler ve verimsiz olay işleyicileri INP'yi bozar.

CLS, okumaya başladığınız metnin aniden aşağı kayması, tıklayacağınız düğmenin yerinden oynaması gibi rahatsızlıkları ölçer. Boyutu belirtilmemiş görseller, sonradan yüklenen reklam ve banner'lar, geç yüklenen web fontları başlıca sebeplerdir.

Core Web Vitals nasıl ölçülür? Alan verisi ve laboratuvar verisi

İki tür veri vardır ve ikisini karıştırmak en yaygın kafa karışıklığıdır.

Alan verisi (field data, CrUX): Gerçek kullanıcıların gerçek cihaz ve bağlantılarında ölçülen değerler. Search Console'un Önemli Web Verileri raporu ve PageSpeed Insights'ın üst bölümü bu veriyi gösterir. Sıralama için geçerli olan budur. Dezavantajı: 28 günlük ortalama olduğu için yaptığınız düzeltme raporda bir ay sonra görünür ve az trafikli sitelerde veri oluşmaz.

Laboratuvar verisi (lab data, Lighthouse): Belirli bir cihaz ve bağlantı simülasyonunda, tek seferlik ölçüm. PageSpeed Insights'ın alt bölümü, Chrome DevTools'daki Lighthouse ve WebPageTest bu veriyi verir. Avantajı anında sonuç ve ayrıntılı teşhis; dezavantajı gerçek kullanıcıyı temsil etmemesi. INP laboratuvarda ölçülemez; yerine TBT (Total Blocking Time) kullanılır.

Pratik yöntem: Search Console'da hangi sayfa gruplarının "zayıf" olduğunu görün, o sayfaları PageSpeed Insights'ta açıp laboratuvar teşhisiyle sebebi bulun, düzeltin, Search Console'da "Düzeltmeyi doğrula" deyin ve 28 gün bekleyin.

Core Web Vitals sıralamayı ne kadar etkiler?

Dürüst cevap: az ama gerçek. Google, Core Web Vitals'ı sayfa deneyimi sinyalleri arasında sayar ve "iyi" eşiğini geçen sayfaların küçük bir avantajı olduğunu söyler. İçerik ve otorite çok daha ağırlıklıdır; CLS'si mükemmel ama içeriği zayıf bir sayfa, CLS'si kötü ama içeriği güçlü bir sayfayı geçmez.

Etkinin belirgin olduğu iki durum vardır. Birincisi, içerik ve otoritenin yakın olduğu rekabetçi sorgularda hız, eşitliği bozan unsur olur. İkincisi, "zayıf" bölgedeki sayfalar, özellikle mobilde, kullanıcının sayfayı terk etmesine yol açar; bu da dolaylı olarak etkileşim sinyallerini ve dönüşümü vurur. Yani hedef, "iyi" eşiğini geçmek ve orada kalmaktır; 100 puan peşinde koşmak değil. Hızın yapay zekâ görünürlüğüyle ilişkisi için ayrı bir yazı var.

LCP nasıl iyileştirilir?

1. Sunucu yanıt süresini (TTFB) düşürün. 600 ms üstü TTFB ile 2,5 sn LCP neredeyse imkânsızdır. Sunucu tarafı önbellek, hızlı hosting, CDN kullanın.
2. LCP öğesini erken yükleyin. Hero görseline fetchpriority="high" verin, loading="lazy" koymayın. Görsel CSS arka planıysa HTML'e <link rel="preload"> ekleyin.
3. Görseli küçültün. WebP veya AVIF biçimi, görüntülendiği boyuta uygun çözünürlük, srcset ile cihaza göre sürüm. Mobilde 1920 piksellik hero görseli göndermek LCP'yi tek başına bozar.
4. Render engelleyen CSS ve JS'i azaltın. Kritik CSS'i satır içine alın, gerisini erteleyin; JS'e defer verin.
5. Web fontlarını yönetin. font-display: swap ve preload ile fontun metni geciktirmesini önleyin.

INP nasıl iyileştirilir?

1. Üçüncü taraf betikleri gözden geçirin. Sohbet widget'ı, pazarlama pikselleri, A/B test araçları ana iş parçacığını kilitler. Her birinin gerçekten gerekli olup olmadığını sorun; gerekli olanları geç yükleyin.
2. Uzun görevleri bölün. 50 ms'den uzun süren JavaScript görevleri etkileşimi bloke eder. Büyük işleri parçalayın, requestIdleCallback veya setTimeout ile sıraya alın.
3. Olay işleyicilerini hafifletin. Tıklama anında ağır hesap yapmak yerine önce görsel geri bildirim verin, hesabı sonra yapın.
4. DOM boyutunu küçültün. Binlerce düğüm içeren sayfalarda her etkileşim pahalı render tetikler.
5. Chrome DevTools Performance panelinde uzun görevleri kaydedip hangi betiğin sorumlu olduğunu bulun; tahmin yerine ölçüm.

CLS nasıl iyileştirilir?

1. Görsel ve videolara boyut verin. width ve height özniteliği ya da CSS aspect-ratio, tarayıcının yükleme öncesi yer ayırmasını sağlar. En yaygın ve en kolay düzeltme.
2. Dinamik içeriğe yer ayırın. Reklam, banner, çerez bildirimi ve sonradan yüklenen bileşenler için sabit yükseklikli bir kap bırakın.
3. Fontların kaymasını önleyin. Yedek font ile asıl font arasındaki boyut farkı metni zıplatır; size-adjust ve preload ile azaltın.
4. Mevcut içeriğin üstüne ekleme yapmayın. Kullanıcı etkileşimi olmadan sayfanın üstüne eklenen her şey (bildirim çubuğu, "uygulamayı indir" banner'ı) CLS üretir.
5. Animasyonlarda transform kullanın. top, height gibi düzen değiştiren özellikler yerine transform ile hareket ettirin.

Nereden başlamalı: öncelik sırası

Her şeyi aynı anda düzeltmeye çalışmak yerine şu sırayı izleyin. Birincisi, Search Console'da hangi metriğin "zayıf" olduğuna bakın; çoğu sitede tek bir metrik sorunludur. İkincisi, o metrik için en çok sayfayı etkileyen tek sebebi bulun; genellikle şablon düzeyinde bir sorundur (ör. tüm blog yazılarındaki boyutsuz görseller) ve tek düzeltme yüzlerce sayfayı iyileştirir. Üçüncüsü, düzeltmeyi laboratuvar verisiyle doğrulayın, sonra alan verisinin güncellenmesini bekleyin.

Yeni bir site tasarlarken bu metrikleri sonradan düzeltmek yerine baştan hesaba katmak çok daha ucuzdur. Web tasarım projelerinde hız bütçesi, görsel boyut kuralları ve üçüncü taraf betik politikası ilk günden tanımlanmalıdır.

Sık sorulan sorular

PageSpeed puanım 90 ama Search Console "zayıf" diyor, neden?

PageSpeed puanı laboratuvar ölçümüdür; Search Console gerçek kullanıcı verisine dayanır. Kullanıcılarınız yavaş cihaz ve bağlantı kullanıyorsa alan verisi laboratuvardan kötü çıkar. Sıralama için geçerli olan alan verisidir.

Core Web Vitals raporu neden boş?

Alan verisi yeterli trafik olmadan oluşmaz. Yeni veya az trafikli sitelerde rapor boş kalır; PageSpeed Insights'ın laboratuvar verisiyle çalışın.

FID ne oldu?

First Input Delay, Mart 2024'te INP ile değiştirildi. INP sayfa boyunca tüm etkileşimleri ölçtüğü için daha gerçekçidir.

Mobil ve masaüstü ayrı mı değerlendirilir?

Evet. Search Console iki ayrı rapor sunar ve Google mobil öncelikli indeksleme kullandığı için mobil değerler daha belirleyicidir. Masaüstünde "iyi" olup mobilde "zayıf" olmak yaygındır; önce mobile odaklanın.