Core Web Vitals: LCP, INP ve CLS neyi ölçer?

Core Web Vitals, sayfa deneyimini üç soruya indirger: içerik ne zaman göründü, tıkladığımda ne kadar sürede tepki verdi, sayfa gözümüzün önünde zıpladı mı? Üçü de gerçek kullanıcı verisiyle ölçülür ve üçünün de somut karşılığı vardır.

Laboratuvar verisi ile alan verisi farkı

Sayfa hızı araçlarında iki ayrı bölüm görürsünüz. Laboratuvar verisi, belirli bir cihaz ve ağ benzetimiyle o an yapılan tek bir ölçümdür; hata ayıklamak için iyidir. Alan verisi, son 28 günde sitenizi gerçekten ziyaret eden kullanıcılardan toplanır ve değerlendirmede esas alınan budur. İkisi çeliştiğinde alan verisine güvenin.

Eşik, ziyaretlerin %75'inin "iyi" aralıkta olmasıdır. Ortalama değil, yüzdelik dilim kullanılır.

Veriyi nereden alırsınız

• Arama konsolundaki Core Web Vitals raporu. URL'leri benzer şablonlara göre gruplar; bir grubu düzelttiğinizde onlarca sayfa birlikte iyileşir. İşe başlanacak yer burasıdır.
• Sayfa hızı analiz araçları. Tek URL için hem alan hem laboratuvar verisini yan yana gösterir.
• Tarayıcının performans paneli. LCP öğesinin hangi düğüm olduğunu ve zamanın nerede geçtiğini adım adım gösteren tek araç budur.
• Kendi gerçek kullanıcı ölçümünüz. web-vitals kütüphanesiyle üç metriği kendi sunucunuza toplayabilirsiniz: onLCP(gonder); onINP(gonder); onCLS(gonder); Böylece 28 günlük pencereyi beklemeden, yaptığınız değişikliğin etkisini ertesi gün görürsünüz.

Alan verisi olmayan sayfalar için rapor "yetersiz veri" der. Bu bir hata değil, örneklemin küçük olması demektir; o durumda laboratuvar ölçümü ve site genelindeki toplu değer tek dayanağınızdır.

LCP — en büyük içerik boyaması

LCP, ekranın ilk görünen bölgesindeki en büyük öğenin çizilme anını ölçer; genellikle kapak görseli ya da başlık bloğudur. Dört bileşene ayrılır: sunucu yanıt süresi, kaynak yükleme gecikmesi, kaynak indirme süresi, çizim süresi.

Hangi bileşenin baskın olduğunu bulmadan düzeltmeye başlamayın; her birinin çaresi farklıdır:

Etkili düzeltmeler:

• Sunucu yanıtını düşürün. TTFB 800 ms ise LCP hiçbir zaman iyi olmaz; önce sunucu tarafını düzeltin.
• Kapak görselini loading="lazy" yapmayın ve fetchpriority="high" verin.
• Görseli WebP/AVIF biçiminde ve gösterileceği ölçüde sunun.
• LCP öğesini CSS arka planı olarak değil <img> etiketiyle verin; tarayıcı arka plan görselini geç keşfeder.
• Yazı tipi dosyalarını önden yükleyin (preload) ve font-display: swap kullanın.

INP — sonraki boyamayla etkileşim

INP, 2024'te FID'in yerini aldı ve çok daha zorlu bir ölçüdür. Yalnız ilk etkileşimi değil, ziyaret boyunca yapılan tüm tıklama ve tuş girişlerini ölçer; en kötüye yakın olanı raporlar. Yani menü açılışı hızlı ama filtre uygulaması yavaşsa INP kötü çıkar.

Etkili düzeltmeler:

• Uzun süren JavaScript görevlerini bölün. 50 ms'i aşan her görev ana iş parçacığını kilitler.
• Üçüncü taraf betiklerini sayın ve gerekmeyenleri kaldırın. Canlı destek, ısı haritası ve reklam betikleri INP'yi en çok bozan üçlüdür.
• Etkileşim sonrası ağır işi bir sonraki çerçeveye erteleyin; kullanıcıya önce görsel geri bildirim verin.
• Gereksiz olay dinleyicilerini kaldırın; her tuş vuruşunda çalışan pahalı bir işleyici tipik suçludur.

CLS — kümülatif düzen kayması

CLS, sayfa yüklenirken içeriğin ne kadar zıpladığını ölçer. Kullanıcının tam tıklayacağı anda düğmenin kayması bu metriğin ölçtüğü rahatsızlıktır. Sebepleri neredeyse her zaman aynıdır:

• Boyutu belirtilmemiş görseller. width ve height özniteliklerini verin; tarayıcı yeri baştan ayırır.
• Sonradan yüklenen reklam ve gömülü içerik. Kapsayıcıya sabit yükseklik verin.
• Geç yüklenen yazı tipi. size-adjust ve yedek yazı tipi eşleştirmesiyle metin sıçraması azaltılır.
• Sayfanın üstüne sonradan eklenen çerez veya duyuru çubuğu. Yerini baştan ayırın ya da içeriği aşağı itmeyen bir konumda gösterin.

Hangisiyle başlamalı?

Arama konsolundaki Core Web Vitals raporunda hangi metriğin başarısız URL sayısı en yüksekse ondan başlayın. Genellikle sıralama şöyledir: CLS düzeltmeleri en ucuz ve en hızlı sonuç verenidir, LCP orta zorluktadır, INP ise çoğu zaman ön yüz kodunda gerçek bir temizlik gerektirir.

Sık yapılan dört hata

• Masaüstünde ölçüp mobili unutmak. Değerlendirme mobil ve masaüstü için ayrı yapılır ve zorlanan taraf neredeyse her zaman mobildir. Ölçümü yavaş bir telefon ve kısıtlı ağ benzetimiyle yapın.
• Puanı metrik sanmak. Analiz araçlarındaki tek rakamlık genel puan laboratuvar ölçümünden türer; değerlendirmede kullanılan üç metrik ise alan verisinden gelir. Puanı 100'e çıkarmak, alan verisi kötüyken hiçbir şey değiştirmez.
• Tek URL düzeltip rahatlamak. Rapor URL gruplarıyla çalışır. Ana sayfayı düzeltmek, aynı şablonu paylaşan yüzlerce ürün sayfasını iyileştirmez.
• CLS'i yalnız sayfa açılışında aramak. Metrik ziyaret boyunca birikir; sonsuz kaydırma, sekme değişimi ve sonradan açılan bildirim çubuğu gibi açılış sonrası kaymalar da sayılır. Sayfayı gerçek bir kullanıcı gibi gezerek ölçün.

Bu yaklaşım ne zaman yanlış olur

Üç metriği kovalamak her sitede en yüksek getirili iş değildir. Oturum açtıktan sonra kullanılan bir yönetim paneli arama sonuçlarında görünmez; orada asıl önemli olan kullanıcının günde yüzlerce kez yaptığı etkileşimin gecikmesidir, ki bu zaten INP'nin ölçtüğü şeydir. Çok düşük trafikli bir kurumsal tanıtım sitesinde alan verisi hiç oluşmayabilir; aylarca laboratuvar puanı optimize etmek yerine içerik ve dönüşüm tarafına bakmak daha akıllıcadır. Metrikler kötü ama sunucu yanıtı zaten iyi ise, sorun barındırmada değil ön yüzdedir; sunucu büyütmek para harcayıp hiçbir metriği oynatmaz. Sunucu tarafının gerçekten pay sahibi olduğu durumlar için konum ve gecikme yazısına, statik varlıkların dağıtımı için CDN yazısına bakın.

Ölçüm alışkanlığı

Her değişiklikten önce ve sonra ölçün, tek seferde tek şey değiştirin. Alan verisi 28 günlük pencerede toplandığı için iyileşmenin raporlara yansıması birkaç hafta alır; bu arada laboratuvar ölçümüyle yönünüzü kontrol edin. Sabırsızlıkla arka arkaya yapılan değişiklikler, hangisinin işe yaradığını anlamayı imkânsız kılar.