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-vitalskü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ı
| İyi | Geliştirilmeli | Zayıf |
|---|---|---|
| ≤ 2,5 sn | 2,5 – 4,0 sn | > 4,0 sn |
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:
| Baskın bileşen | Belirti | Yapılacak |
|---|---|---|
| Sunucu yanıtı | TTFB yüksek, görsel küçük | Önbellek, veritabanı, barındırma tarafı |
| Yükleme gecikmesi | Görsel geç keşfediliyor | preload, arka plan yerine gerçek görsel etiketi |
| İndirme süresi | Dosya boyutu büyük | Modern biçim, doğru ölçü, sıkıştırma |
| Çizim gecikmesi | Dosya indi ama ekranda yok | Engelleyen betik ve yazı tipini çözün |
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 vefetchpriority="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) vefont-display: swapkullanın.
INP — sonraki boyamayla etkileşim
| İyi | Geliştirilmeli | Zayıf |
|---|---|---|
| ≤ 200 ms | 200 – 500 ms | > 500 ms |
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ı
| İyi | Geliştirilmeli | Zayıf |
|---|---|---|
| ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
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.
widthveheightö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-adjustve 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.
LCP öğesini kendiniz bulun: tarayıcıda on satır
LCP değerini iyileştirmenin ilk adımı, o değeri hangi öğenin ürettiğini bilmektir. Çoğu kişi bunun sayfadaki büyük görsel olduğunu varsayar; çoğu zaman yanılır. Tarayıcının kendi ölçüm arayüzü cevabı doğrudan verir. Aşağıdaki kodu geliştirici araçlarının konsoluna yapıştırıp sayfayı yenileyin:
new PerformanceObserver((liste) => {
for (const e of liste.getEntries()) {
console.log('LCP', Math.round(e.startTime), 'ms', e.element, e.size);
}
}).observe({ type: 'largest-contentful-paint', buffered: true });
let cls = 0;
new PerformanceObserver((liste) => {
for (const e of liste.getEntries()) if (!e.hadRecentInput) cls += e.value;
console.log('CLS', cls.toFixed(3));
}).observe({ type: 'layout-shift', buffered: true });
Konsol önce birkaç aday yazar, sonuncusu kesin LCP öğesidir. buffered: true sayesinde kod sayfa yüklendikten sonra çalıştırılsa bile önceki kayıtları görür. Bu kodu kendi sitemizde mobil görünümle çalıştırdık: ana sayfada LCP öğesi bir görsel değil, giriş bölümündeki açıklama paragrafıydı ve 636 ms'de boyandı; CLS sıfırdı. Blog yazılarında da kapak görseline rağmen LCP öğesi yazının özet paragrafı çıktı, çünkü mobil ekranda özet metin kutusu görselden daha büyük alan kaplıyordu.
Bu bulgunun pratik sonucu önemlidir: LCP öğesi metinse görseli sıkıştırmak LCP'yi değiştirmez. Metin LCP'sinde belirleyici olan ilk bayt süresi, metni engelleyen CSS ve web yazı tipinin yüklenme biçimidir. Yazı tipi için font-display: swap ve kritik yazı tipinin önceden yüklenmesi, metin LCP'sini en çok kısaltan iki ayardır.
Laboratuvar ölçümünü alan verisine yaklaştırmak
Konsoldaki sonuç sizin cihazınızda, sizin bağlantınızla alınmış tek bir ölçümdür. Gerçek kullanıcıyı temsil etmesi için iki ayar yapın: geliştirici araçlarında ağ hızını "Fast 4G" ya da daha yavaşına, işlemciyi 4 kat yavaşlatmaya alın ve önbelleği devre dışı bırakın. Aynı ölçümü üç kez tekrarlayıp ortadaki değeri kullanın. Değerler alan verisinden yine farklı olacaktır; ama hangi öğenin LCP olduğu ve hangi değişikliğin onu kısalttığı sorusuna güvenilir cevap verir.
Gerçek kullanıcılardan veri toplamak isterseniz aynı ölçüm arayüzünü kullanan, Google'ın açık kaynaklı web-vitals kütüphanesi değerleri kendi analitik altyapınıza gönderebilir. Az ziyaretçili sitelerde arama motorunun alan verisi raporu çoğu zaman "yeterli veri yok" der; kendi topladığınız veri bu boşluğu doldurur.
Ö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.
Sık sorulan sorular
LCP öğesini nasıl bulurum?
Tarayıcının geliştirici araçlarında Performans panelinde LCP işaretine tıklayabilir ya da konsolda largest-contentful-paint türü için bir PerformanceObserver çalıştırabilirsiniz. Gözlemcinin yazdığı son kayıt LCP öğesidir; element alanı öğenin kendisini gösterir.
LCP öğesi metin olabilir mi?
Evet. Ekranın ilk görünen alanında en büyük alanı bir başlık ya da paragraf kaplıyorsa LCP öğesi odur; mobil ekranlarda bu sık görülür. Bu durumda görsel optimizasyonu LCP'yi değiştirmez; ilk bayt süresine, engelleyen CSS'e ve web yazı tipinin yüklenmesine bakın.
PageSpeed Insights'ta alan verisi neden görünmüyor?
Alan verisi gerçek Chrome kullanıcılarından toplanır ve bir sayfa ya da sitenin yeterli ziyaret alması gerekir. Az ziyaretçili sitelerde rapor yalnız laboratuvar ölçümünü gösterir. Bu durumda kendi sitenizde web-vitals gibi bir kütüphaneyle gerçek kullanıcı verisi toplayabilirsiniz.
- #core web vitals
- #lcp
- #inp
İlk bayt süresini altyapıdan kısaltmak mı istiyorsunuz? Hosting paketlerimiz İstanbul'daki sunucularımızda çalışır; TLS 1.3 ve HTTP/2 desteklidir.
Hosting paketlerine bakın