Core Web Vitals derinlemesine

Bu üç sayıdan her biri neyi ölçer

Core Web Vitals tek bir puan değil, üç metriktir. Adları hep birlikte anıldığı için birçok kişi onları aynı şeyin üç anlatımı sanır. Değildirler. Her biri ziyaretin başka bir anını yakalar ve her biri genelde başka bir nedenle bozulur.

LCP, yani Largest Contentful Paint, görüntü alanı içindeki en büyük içerik öğesinin çizildiği andır. Bu genelde büyük bir görsel ya da bir metin bloğudur. Google belgeleri, sitelerin 2,5 saniye veya daha az bir Largest Contentful Paint hedeflemesi gerektiğini söyler. Bu sayı "bir şey gördüm mü" sorusunu yanıtlar.

INP, yani Interaction to Next Paint, kullanıcının yaptığı şeyle tarayıcının bir sonraki kareyi çizdiği an arasındaki aralıktır. Google, bir sayfanın INP değerinin 200 milisaniye veya daha az olması gerektiğini, 500 milisaniyenin üstünün ise zayıf sayıldığını yazar. Bu sayı "dokunduğumda bir şey oldu mu" sorusunu yanıtlar.

Dil modellerinin de eski yazıların da yanıldığı yer tam burasıdır. INP, FID metriğinin ardılıdır ve Google'ın kendi sayfası bunu söyler. Fark küçük değil: FID yalnızca sayfadaki ilk etkileşimin giriş gecikmesini ölçüyordu, INP ise kullanıcı orada olduğu sürece bütün etkileşimleri izler; giriş gecikmesinden olay işleyicilerinin çalışmasına, oradan tarayıcının nihayet çizdiği kareye kadar. Bir yerde 100 milisaniye rakamını görürseniz, o rakam artık Core Web Vital olmayan bir metriğe aittir.

CLS, yani Cumulative Layout Shift, hiçbir zaman birimi taşımaz. Sayfa içeriğinin kullanıcı istemeden ne kadar yer değiştirdiğini söyleyen birimsiz bir sayıdır. Google, sitelerin 0,1 veya daha düşük bir CLS hedeflemesi gerektiğini yazar. Bu sayı "dokunmak üzere olduğum şey yerinde kaldı mı" sorusunu yanıtlar.

Üç farklı soru, üç farklı yanıt. Birinde mükemmel olan bir sayfa diğerinde berbat olabilir ve bu nadir değildir: LCP değeri çok iyi olan hafif bir metin sayfası, tek bir ağır sohbet betiğiyle kötü bir INP ve gayet iyi bir LCP taşır. Bu üçünün daha basit girişi onlar için yazdığımız başlangıç yazısında duruyor; bu ders oradan başlamıyor, oradan devam ediyor.

Sayınız neden Google'ın gördüğü sayı değil

Bu ayrımı yeni başlayanlar da yanlış anlar, dil modelleri de; hız üzerine yapılan sonuçsuz tartışmaların çoğu tam buradan başlar. İki tür veri var ve adlarını öğrenmeye değer.

Laboratuvar verisi simüle edilmiş bir çalıştırmadan gelir: varsayımsal bir cihaz, varsayımsal bir ağ, tek bir sayfa yüklemesi. Tekrarlanabilir, şu anda elinizin altında ve nedenleri bulmak için mükemmeldir. Ama gerçek kimsenin deneyimi değildir.

Saha verisi gerçek ziyaretçilerden toplanır. Chrome Kullanıcı Deneyimi Raporu tam olarak budur: üç metriğin her biri için gerçek kullanıcıların anonimleştirilmiş ölçümü. Google sizi bu veriyle değerlendirir.

Ve işte her şeyi değiştiren sayı. Google, kullanıcılarınızın çoğu için önerilen hedefe ulaştığınızdan emin olmak adına ölçülecek iyi eşiğin, mobil ve masaüstü ayrı ayrı olmak üzere sayfa yüklemelerinin 75. yüzdeliği olduğunu yazar. Yani geçip geçmediğinize kullanıcılarınızın en yavaş çeyreği karar verir ve Core Web Vitals değerlendiren bir araç, sayfayı ancak üç metrikte de 75. yüzdelikte hedefi tutturuyorsa geçmiş saymalıdır.

Bir İran sitesi için sonucu doğrudandır: iyi bir bağlantıyla dizüstünüzde yapılan test büyük olasılıkla en iyi durumu gösterir, oysa sizin 75. yüzdeliğiniz istikrarsız bir ağdaki bir telefondan gelir. Bu iki sayı arasındaki fark tahminle doldurulacak bir şey değildir.

Daha az konuşulan ikinci sorun: hiç saha veriniz olmayabilir. Google o veri kümesine giriş koşullarını yayımlar ve biri, sayfanın ya da kaynağın yeterince popüler olması, yani asgari bir ziyaretçi sayısına ulaşmasıdır. Google o asgari sayıyı yayımlamaz. Dolayısıyla sitenizin saha bölümü boşsa bozuk bir şey yok; bu, az trafikli bir sitenin olağan hâlidir ve tek yol bunu kabul edip laboratuvar verisini hüküm değil ipucu saymaktır.

LCP kötüyse zaman nereye gitti

"LCP kötü" bir teşhis değil, bir belirtidir. Google'ın kendisi LCP'yi dört parçaya ayırır ve işi tahminden okumaya çeviren de bu ayrımdır.

Birinci parça ilk bayta kadar geçen süredir: istekten, sunucunun yanıtın ilk baytını gönderdiği ana kadar. İkincisi kaynak yükleme gecikmesidir: o ilk bayt ile tarayıcının LCP kaynağını yüklemeye daha yeni başladığı an arasındaki süre. Üçüncüsü kaynak yükleme süresi, yani o görselin ya da yazı tipinin indirilmesidir. Dördüncüsü öğe çizim gecikmesidir: indirmenin bitişinden öğenin tam olarak çizilmesine kadar.

Google bu dördü için kabaca bir dağılım da yayımlar: ilk bayta kadar geçen süre LCP'nin yaklaşık %40'ı, kaynak yükleme gecikmesi %10'un altı, kaynak yükleme süresi yaklaşık %40 ve öğe çizim gecikmesi %10'un altı. Google hemen ardından bu dökümlerin katı kural değil yol gösterici olduğunu ekler ve bu yüzdeleri mutlak sayılara çevirmemeyi açıkça önerir.

Bu uyarıya rağmen ayrım bir şeyi netleştirir ve piyasa bunu çoğu zaman tersinden söyler: tipik bir sayfanın LCP'sinin kabaca yüzde sekseni, eklentilerinizle hiç ilgisi olmayan iki parçada durur. Biri sunucu yanıt süresi, öteki bir dosyanın indirilmesi. Kötü LCP'niz için ilk baytın ne zaman geldiğine bakmadan eklenti silmeyi öneren biri, işe ortadan başlıyor demektir. Hosting ile bu sayıların ilişkisini hostingin Core Web Vitals'ı nasıl oynattığına dair yazımızda ayrıca açtık.

INP ve CLS genelde nereden bozulur

INP neredeyse her zaman JavaScript yüzünden bozulur. Kullanıcı dokunur ve tarayıcı bir sonraki kareyi çizebilmek için o anda çalışan işin bitmesini beklemek zorunda kalır. Ana iş parçacığını meşgul eden her şey bu beklemeyi yaratır: bir sayaç betiği, bir sohbet bileşeni, bir kaydırıcı, bir reklam betiği ya da tıklama anında ağır iş yapan tema kodu. Raporlarda pek görünmeyen bir şey daha var: INP sayfanın yalnızca ilk saniyelerini değil, tüm ömrünü izler; yani sayfa açıldıktan üç saniye sonra yüklenen bir betik de onu bozabilir.

CLS iki aileden bozulur. Birincisi kendisine yer ayrılmamış şeyler: boyutu bildirilmemiş bir görsel, video ya da iframe, geldiğinde sayfanın geri kalanını aşağı iter. İkincisi geç gelen şeyler: bir afiş, bir bildirim çubuğu, JavaScript ile sayfanın üstüne enjekte edilen içerik ya da metni göründükten sonra yeniden dizen bir yazı tipi.

Ve şimdi hiçbir eğitimin neredeyse yazmadığı, onsuz CLS'yi yanlış okuyacağınız kural: kullanıcı girdisinden sonraki 500 milisaniye içinde gerçekleşen düzen kaymaları işaretlenir, böylece hesaplamadan çıkarılabilirler. Yani menü düğmesine kendiniz dokunup menü açıldığında, o kayma CLS'nize eklenmez. Bu bilinçlidir: tarayıcı "sayfa elimin altında zıpladı" ile "buna ben sebep oldum" arasını ayırır. Bunu bilmeyen kendi akordeonunu ve menüsünü CLS sorunu olarak raporlar ve zamanını yanlış yere harcar.

Bir sınır daha koyalım, çünkü onsuz bu üç sayı puta dönüşür: iyi bir CLS, sayfanın kullanıcının elinin altında zıplamadığı anlamına gelir, tasarımın iyi olduğu anlamına değil. CLS'si sıfır olan ve metnini kimsenin anlamadığı bir site yine de kötü bir sitedir.

Bu üç sayının size söylemediği

Üç metriğin yeşil olması, sayfanızın kullanıcının elinin altında kötü davranmadığı anlamına gelir. Anlamı bundan ibarettir. İçeriğinizin soruyu yanıtladığını söylemez, fiyatınızın makul olduğunu söylemez, sayfanın dizine eklendiğini de söylemez. Google'ın kendisi de sayfa deneyimi belgesinde iyi bir puanın üst sırayı garanti etmediğini yazar.

Bu sayıların hiç görmediği iki şey daha var. Biri sayfa yüklendikten sonrasının hızı: Core Web Vitals ziyarete odaklıdır ve INP sayfanın tüm ömrünü izlese de formunuzun gönderilmesinin ne kadar sürdüğü hakkında bir şey söylemez. Öteki, herhangi bir nedenle o veri kümesinde bulunmayan kullanıcıların deneyimidir.

Dolayısıyla doğru iş sırası şudur: önce hızlandırmak istediğiniz sayfanın birinin umurunda olup olmadığına bakın, sonra bu üç sayıya gelin. Bu rotanın bir sonraki dersi bu sayıları hangi araçla alacağınızı ve raporu nasıl okuyacağınızı gösteriyor; derslerin tam listesi bu rota sayfasında.