Core Web Vitals açıklandı: LCP, INP ve CLS sade bir dille

Core Web Vitals web siteniz için bir kişilik testi değildir

Core Web Vitals çoğu zaman gizemli bir puan kartı gibi ele alınır. Bir sayfa kırmızı bir sayı alır, biri Slack’te ekran görüntüsü paylaşır ve ekip JavaScript framework’leri hakkında tartışmaya başlar.

Bu pek de faydalı değildir.

Core Web Vitals’ı düşünmenin daha iyi yolu daha basittir: Bunlar, bir sayfanın gerçek bir cihazdaki gerçek bir kişiye kullanılabilir hissettirip hissettirmediğine dair üç ölçümdür. Performansın, erişilebilirliğin veya kalitenin her yönünü kapsamazlar. Ancak üç yaygın hayal kırıklığı kaynağını yakalarlar:

• Ana içeriğin görünmesi çok uzun sürer.
• Kullanıcı bir şey yapmaya çalıştığında sayfa yavaş tepki verir.
• Kullanıcı okurken veya dokunurken düzen yer değiştirir.

Bunlar üç Core Web Vitals metriğidir: LCP, INP ve CLS.

Google bunları sayfa deneyimi sinyallerinin bir parçası olarak kullanır, ancak SEO açısından bakmak önemsemek için en iyi neden değildir. Daha iyi neden şudur: yavaş, zıplayan, yanıt vermeyen sayfalar kullanıcıların zamanını boşa harcar. Ayrıca genellikle daha kötü dönüşüm sağlar, daha kötü desteklenir ve kötü eskir.

Üç metrik, her biri tek cümlede

Ayrıntılara girmeden önce sade dille açıklama şöyle:

• LCP, yani Largest Contentful Paint, ana görünür içeriğin yüklenmesinin ne kadar sürdüğünü ölçer.
• INP, yani Interaction to Next Paint, sayfanın ziyaret boyunca kullanıcı etkileşimlerine ne kadar hızlı yanıt verdiğini ölçer.
• CLS, yani Cumulative Layout Shift, sayfanın beklenmedik şekilde ne kadar hareket ettiğini ölçer.

Yaygın eşikler şunlardır:

| Metrik | İyi | İyileştirme gerekiyor | Kötü | |---|---:|---:|---:| | LCP | 2.5s veya daha hızlı | 2.5s–4.0s | 4.0s üzeri | | INP | 200ms veya daha hızlı | 200ms–500ms | 500ms üzeri | | CLS | 0.1 veya daha düşük | 0.1–0.25 | 0.25 üzeri |

Bu sayılar normalde gerçek kullanıcı ziyaretlerinin 75. yüzdelik diliminde değerlendirilir. Bu önemlidir. Amaç tek bir kusursuz laboratuvar çalıştırması elde etmek değildir. Amaç, daha yavaş telefonlara ve daha karmaşık ağlara sahip kişiler de dahil olmak üzere kullanıcıların çoğu için deneyimi iyi hale getirmektir.

Otomatik bir rapora bakıyor ve nereden başlayacağınızdan emin olamıyorsanız, tanıyı panikten ayırmak yardımcı olur. Bu iş akışını daha ayrıntılı ele alan, paniğe kapılmadan Lighthouse raporu okumaya dair ayrı bir rehberimiz var.

LCP: sayfa ne zaman yüklenmiş hissedilir?

Largest Contentful Paint, viewport içindeki en büyük görünür içerik öğesinin render edilme süresini ölçer. Pratikte bu çoğu zaman şunlardan biridir:

• bir hero görseli,
• büyük bir başlık,
• öne çıkarılmış bir makale görseli,
• bir ürün görseli,
• büyük bir metin bloğu.

LCP, her script’in, izleme pikselinin ve ekranın altındaki görselin yüklenmesinin ne zaman bittiğini sormaz. Şunu sorar: kullanıcının görmeye geldiği ana şey ne zaman görünür oldu?

Bu, LCP’yi eski usul “sayfa yüklenme süresi”nden daha insani bir metrik yapar. Bir sayfa teknik olarak geç yüklenmeyi bitirebilir ama ana içerik hızlı görünüyorsa yine de hızlı hissedilebilir. Tersi de doğrudur: hero alanı hâlâ boş, bulanık veya bir render gecikmesiyle engellenmişken sayfa load event’ini tetikleyebilir.

Kötü LCP’nin yaygın nedenleri

Çoğu kötü LCP sorunu birkaç öngörülebilir yerden kaynaklanır:

1. Yavaş sunucu yanıtı

HTML belgesi geç gelirse, diğer her şey de geç başlar.

1. Render’ı engelleyen CSS veya JavaScript

Tarayıcı içeriğe sahiptir ama henüz onu çizemiyordur.

1. Optimize edilmemiş hero görselleri

En büyük öğe çok büyüktür, yanlış formattadır, önceliklendirilmemiştir veya yanlışlıkla lazy-loaded yükleniyordur.

1. Metin render’ını geciktiren web fontları

Büyük bir başlık LCP öğesi olabilir ve font yüklenmesi bunu geciktirebilir veya görsel olarak değiştirebilir.

1. İstemci tarafı render gecikmeleri

Sayfanın anlamlı içerik gösterebilmesi için önce büyük bir JavaScript bundle’ına ihtiyacı varsa LCP zarar görür.

LCP nasıl iyileştirilir

Gerçek LCP öğesiyle başlayın. Tarayıcının neyi ölçtüğünü bilmeden rastgele varlıkları optimize etmeyin.

Pratik düzeltmeler şunları içerir:

• HTML’i hızlı sunun: uygun yerlerde cache kullanın, backend işini azaltın, yavaş yönlendirmelerden kaçının.
• LCP görselini optimize edin: doğru boyutları, sıkıştırmayı ve formatı kullanın.
• Ekranın üst kısmındaki hero görselini lazy-load yapmayın.
• Ana görsel gerçekten öncelikliyse fetchpriority="high" değerini dikkatli kullanın.
• Kritik CSS’i yalnızca render gecikmesini anlamlı biçimde azaltıyorsa inline edin.
• İlk anlamlı render’dan önce gereken JavaScript’i azaltın.
• font-display: swap veya bilinçli başka bir font stratejisi kullanın.

Görseller ve fontlar sık rastlanan suçlulardır. Görsellerde mesele yalnızca “küçük dosya iyidir” değildir. Format seçimi, kodlama çabası ve tarayıcı desteği de önemlidir; bu yüzden AVIF’in WebP’den ne zaman daha iyi olduğunu ve ne zaman olmadığını anlatan pratik bir karar ağacı tutuyoruz. Yazı ağırlıklı sayfalarda ise web fontları hâlâ en kolay performans kazanımlarından biridir, çünkü birçok site kullandığından daha fazla font dosyası gönderir.

INP: dokunulduğunda sayfa yanıt veriyor mu?

Interaction to Next Paint yanıt verebilirliği ölçer. Daha spesifik olarak, kullanıcının etkileşimi ile tarayıcının bu etkileşimi işledikten sonraki ilk görsel güncelleme arasındaki gecikmeye bakar.

Etkileşimler şunları içerebilir:

• bir düğmeye tıklamak,
• bir menüye dokunmak,
• bir checkbox seçmek,
• bir form alanına yazmak,
• bir accordion açmak.

INP, 2024’te Core Web Vital olarak First Input Delay’in yerini aldı. Bu iyi bir değişiklikti. First Input Delay yalnızca ilk etkileşime bakıyordu. INP daha geniştir: sayfa ziyareti boyunca etkileşimleri dikkate alır ve yüksek gecikmeli bir etkileşimi sayfanın yanıt verebilirlik puanı olarak raporlar.

Sade dille: INP, yüklenmiş görünen ama takılmış hissettiren sayfaları yakalar.

Muhtemelen böyle bir sayfa kullanmışsınızdır. Hazır görünür. Menüye dokunursunuz. Yarım saniye hiçbir şey olmaz. Tekrar dokunursunuz. Sonra iki şey aynı anda olur. Bu bir INP sorunudur.

Kötü INP’nin yaygın nedenleri

INP genellikle bir main thread sorunudur. Tarayıcı yanıt vermek ister, ancak JavaScript, render işi veya layout hesaplaması araya girmiştir.

Tipik nedenler şunlardır:

• büyük JavaScript bundle’ları,
• pahalı event handler’lar,
• istemci tarafında render edilen uygulamalarda hydration işi,
• main thread için rekabet eden üçüncü taraf script’ler,
• sayfa yüklendikten sonra uzun süren görevler,
• küçük etkileşimlerle tetiklenen karmaşık DOM güncellemeleri,
• kodun layout değerlerini tekrar tekrar okuyup yazdığı layout thrashing.

Pazarlama tag’leri, analytics, chat widget’ları ve consent banner’ları bunların hepsi katkıda bulunabilir. Bu, “her şeyi kaldırın” anlamına gelmez. Sayfadaki her script’in bir maliyeti olduğu ve bu maliyetin çoğu zaman etkileşim gecikmesinde görünür hale geldiği anlamına gelir.

INP nasıl iyileştirilir

INP’yi iyileştirmek tek bir sihirli attribute’tan çok main thread çekişmesini azaltmakla ilgilidir.

Faydalı yaklaşımlar şunlardır:

• Uzun JavaScript görevlerini daha küçük parçalara bölün.
• Zorunlu olmayan işleri sayfa kullanılabilir hale gelene kadar erteleyin.
• Kullanılmayan JavaScript’i yalnızca minify etmek yerine kaldırın.
• Event handler’ları küçük ve öngörülebilir tutun.
• Küçük durum değişiklikleri için arayüzün büyük bölümlerini yeniden render etmekten kaçının.
• Mümkün olduğunda basit görsel durumlar için CSS kullanın.
• Üçüncü taraf script’leri denetleyin ve yalnızca gerektiği yerde yükleyin.

Etkileşim tasarımına da bakın. Bir düğme anında görsel geri bildirim veriyorsa, devamındaki iş daha uzun sürse bile daha duyarlı hissedilebilir. Bu performansın yerine geçmez, ama iyi arayüz mühendisliğinin bir parçasıdır. Erişilebilir web düğmeleri için hazırladığımız kontrol listesi bununla örtüşür: net durumlar, doğru semantik ve öngörülebilir davranış hem kullanıcılara hem tarayıcılara yardımcı olur.

CLS: sayfa kullanıcının beklediği yerde kalıyor mu?

Cumulative Layout Shift, görünür öğelerin beklenmedik hareketini ölçer. Kullanıcı bir paragrafı okumaya başlamışken üstte bir reklam, görsel veya banner yüklenip metni aşağı itiyorsa bu CLS’ye katkıda bulunur.

CLS saniye cinsinden ölçülmez. Ne kadar içeriğin ne kadar uzağa hareket ettiğine dayalı bir puandır. Daha düşük daha iyidir.

Anahtar kelime beklenmediktir. Bir kullanıcı eyleminin neden olduğu layout değişiklikleri genellikle aynı şekilde sayılmaz. Bir kişi “daha fazla göster”e dokunur ve içerik genişlerse bu beklenir. Bir newsletter banner’ı üç saniye sonra üstte belirip her şeyi aşağı itiyorsa bu beklenmez.

Kötü CLS’nin yaygın nedenleri

CLS hataları çoğu zaman sıradandır:

• width ve height attribute’ları olmayan görseller,
• ayrılmış alanı olmayan reklamlar veya embed’ler,
• içeriğin üstüne eklenen cookie banner’ları,
• farklı metriklerle devreye giren web fontları,
• geç yüklenen promosyon barları,
• sayfanın üst kısmına yakın dinamik olarak enjekte edilen içerik.

Çözüm genellikle içerik gelmeden önce alan ayırmaktır. Tarayıcı sayfanın şeklini mümkün olduğunca erken bilmelidir.

CLS nasıl iyileştirilir

Görünür kaymalarla başlayın. Hangi öğelerin hareket ettiğini belirlemek için bir kayıt izleyin veya tarayıcı araçlarını kullanın.

Sonra sıkıcı düzeltmeleri uygulayın:

• Görsellere açık width ve height attribute’ları ekleyin.
• Responsive media container’ları için CSS aspect-ratio kullanın.
• Reklamlar, embed’ler ve iframe’ler için sabit veya minimum alan ayırın.
• Yüklemeden sonra mevcut içeriğin üstüne banner enjekte etmekten kaçının.
• Son fonta benzer metriklere sahip font fallback’leri seçin.
• top, left, width veya height gibi layout özelliklerini değiştiren animasyonlardan kaçının; transform’ları tercih edin.

CLS, zekâdan çok disiplinin kazandığı az sayıdaki performans metriğinden biridir. Sayfada kararlı kutular varsa genellikle iyi puan alır.

Field data ve lab data ikisi de faydalıdır, ama farklı sorulara yanıt verirler

Yaygın bir kafa karışıklığı kaynağı, farklı araçların farklı sayılar göstermesidir. Bu normaldir.

Field data gerçek kullanıcılardan gelir. Gerçek cihazları, ağları, konumları ve tarayıcı koşullarını yansıtır. Google’ın Chrome User Experience Report’u field data örneğidir.

Lab data kontrollü bir test ortamından gelir. Lighthouse tanıdık örnektir. Tekrarlanabilir ve debugging için faydalıdır, ancak kullanıcılarınızın yaşadığı deneyimle aynı şey değildir.

Kullanıcıların gerçek bir sorunu olup olmadığına karar vermek için field data kullanın. Bu sorunu yeniden üretmek ve debug etmek için lab data kullanın.

Ayrıca Core Web Vitals’ın genellikle markanızın tek bir soyut özelliği olarak değil, URL veya URL grubu başına değerlendirildiğini unutmayın. Ana sayfanız, blog yazınız, fiyatlandırma sayfanız ve checkout akışınız çok farklı darboğazlara sahip olabilir.

Mantıklı bir çalışma sırası

Üç metrik de kötüyse, her yerden başlama eğilimi doğar. Buna direnin.

Pratik bir sıra şöyledir:

1. Önce belirgin CLS sorunlarını düzeltin

Eksik görsel boyutları ve kararsız banner’lar çoğu zaman hızlı kazanımlardır.

1. Önemli şablonlar için LCP’yi iyileştirin

Önemli sayfalara odaklanın: ürün sayfaları, landing page’ler, makaleler, kayıt akışları.

1. INP’yi gerçek etkileşimlerle inceleyin

Kullanıcıların gerçekten tıkladığı şeylere tıklayın. Menüler, filtreler, formlar ve checkout kontrolleri çoğu zaman ilk yükleme izinden daha fazlasını ortaya çıkarır.

1. Üçüncü taraf script’leri denetleyin

Maliyetini haklı çıkaranları tutun. Haklı çıkarmayanları kaldırın veya geciktirin.

1. Bir performans bütçesi belirleyin

Bütçe olmadan performans iyileştirmeleri aşınır. Yeni script’ler, görseller ve tasarım bileşenleri sessizce yapılan işi geri alır.

Önemli nokta: bir rozet için optimize etmeyin. Kullanıcı yolculuğu için optimize edin. Düşük trafikli bir sayfadaki marjinal puan iyileştirmesi, biraz kusurlu ama çok daha hızlı bir checkout etkileşiminden daha az önemli olabilir.

<!-- tool-cta:start -->

💡 Bunu deneyin: LCP genellikle bir görsel sorunu olduğundan, ilk ve kolay bir kazanım olarak hero varlığınızı Image Compressor ile küçültün.

<!-- tool-cta:end -->

Core Web Vitals size ne söylemez?

Core Web Vitals faydalıdır, ama eksiktir.

İçeriğinizin iyi olup olmadığını söylemez. Navigasyonunuzun mantıklı olup olmadığını söylemez. Erişilebilirliği garanti etmez. Gizliliği, güvenliği, güveni, okunabilirliği veya sayfanın kullanıcının sorusunu yanıtlayıp yanıtlamadığını ölçmez.

Ayrıca yargının yerini almaz. Bir sayfa Core Web Vitals’tan geçebilir ve yine de rahatsız edici olabilir. Karmaşık bir uygulama, kendi kısıtları içinde sorumlu biçimde tasarlanmış olsa bile bir eşiği kaçırabilir.

LCP, INP ve CLS’yi duman alarmları gibi ele alın. Çaldıklarında araştırın. Sessiz olduklarında binanın bakımını sürdürün.