Yeşil bir hız puanı gördükten sonra “Core Web Vitals değerlendirmesi başarısız” diye aradıysanız önce her sonucun hangi veriyi anlattığını kontrol edin. PageSpeed Insights (PSI), gerçek ziyaretlerden gelen kanıtları ayrı bir kontrollü testle bir araya getirir. Bir araç satın almadan veya birinden siteyi yeniden yapmasını istemeden önce adresi, cihazı, veri kapsamını ve başarısız olan metriği kaydedin.
Bu kayıtla başlıyoruz; çünkü “puanı yeşile çevirin” talebi pek çok noktayı belirsiz bırakır. Geliştiricinin hangi deneyimin ilgi gerektirdiğini ve hangi kanıtın yararlı bir düzeltme sayılacağını bilmesi gerekir.
Core Web Vitals değerlendirmesi başarısız: rapor neyi ölçtü?
Değerlendirme, kaydedilmiş ziyaretçi deneyimlerini anlatırken Lighthouse bölümü bir tanılama testi çalıştırır. Google’ın PageSpeed Insights belgeleri, saha verilerinin Chrome User Experience Report’tan, yani CrUX’tan, geriye dönük 28 günlük veri toplama dönemi üzerinden geldiğini açıklar. Bu nedenle yeni bir tanılama çalıştırması ile bu geçmiş farklı sonuçlar gösterebilir.
Test koşulları farklıdır. Kontrollü bir çalıştırma, gerçek ziyaretlerdeki her cihazı, bağlantıyı ve eylemi kapsayamaz. Olası bir nedeni araştırmak için kullanın; neyin hâlâ çözülmediğine karar verirken ziyaretçi verilerini de yanında tutun.
Sonuç daha geniş bir alanı kapsayabilir. Tam olarak o sayfa için çok az veri varsa PSI kaynak düzeyindeki verilere dönebilir. Kaynak, kabaca protokol ve ana makine adı dâhil ortak site adresidir. Kaynak düzeyindeki bir sonuç, farklı sayfalardaki ziyaretleri birleştirir. Bunu belirli bir ürün veya hizmet sayfasına ilişkin kanıt saymadan önce ekranda gösterilen kapsamı okuyun.
Dönem eski ziyaretleri de içerir. Bugün yapılan bir değişiklik dünün gözlemlerini yeniden yazmaz. Düzeltmenin hemen yapılan kontrolü ile ziyaretçilerden daha sonra gelen kanıtları ayırabilmek için yayına alma tarihini kaydedin.
Bu ayrımlar raporlara farklı görevler verir: ziyaretçi kanıtları araştırılacak deneyimi belirler; kontrollü bir test ise bu deneyimi yeniden oluşturmaya ve incelemeye yardımcı olur.
Hangi metrik ilgi gerektiriyor?
Bir düzeltme seçmeden önce LCP, INP ve CLS’yi ayrı ayrı inceleyin. Google’ın Web Vitals rehberi yükleme, yanıt verme ve görsel kararlılığı birbirinden ayırır. Aşağıdaki tablo, ilgili cihaz grubunun 75. yüzdelik diliminde değerlendirilen Good hedeflerini bu rehberden aktarır. Google’ın eşik rehberi 75. yüzdelik dilimi şöyle açıklar: ölçülen sayfa görüntülemelerinin en az %75’i ilgili metrik için Good hedefini karşılamalıdır. Bu, ortalamadan veya genel Lighthouse puanından farklıdır.
| Metrik | Neyi anlatır | Good hedefi | Bakımdan sorumlu kişiye ne sormalı? |
|---|---|---|---|
| LCP, Largest Contentful Paint | Görünür en büyük içerik öğesinin ne zaman belirdiği | En fazla 2,5 saniye | Hangi öğe gecikiyor ve yükleme sürecinin hangi aşamasında? |
| INP, Interaction to Next Paint | Sayfanın etkileşimlere ne kadar hızlı yanıt verdiği | En fazla 200 milisaniye | Etkilenen koşullarda hangi dokunma, tıklama veya tuş eylemi yavaş? |
| CLS, Cumulative Layout Shift | Sayfa düzeninin beklenmedik biçimde kayması | En fazla 0,1 | Hangi öğe hareket ediyor ve ziyaretin hangi anında? |
Bu metriklerin hepsinde yeterli veri olduğunda PSI, değerlendirmeyi geçmek için 75. yüzdelik dilim değerlerinin Good kategorisinde olmasını gerektirir. INP verisi yetersizse Good kategorisindeki LCP ve CLS yine de geçer sonuç verebilir. LCP veya CLS verisinden herhangi biri yetersizse PSI o sayfayı ya da kaynağı değerlendiremez.
Eksik veriyi belirsizlik olarak ele alın. Google’ın CrUX metodolojisi, gerekli koşulları karşılayan ziyaretler ve yeterli popülerlik gerektirir; evrensel bir asgari ziyaretçi sayısı yayımlamaz. Sonucun olmaması siteyi kimsenin ziyaret etmediğini, deneyimin iyi olduğunu veya düzeltmenin başarısız olduğunu göstermez.
İş için ödeme yapmadan önce neyi kontrol edebilirsiniz?
Bir araç seçmeden önce başlangıç raporunu kaydedin ve aynı müşteri yolculuğunu telefonda izleyin. İhtiyacınız olan şey sorunun açık bir tarifidir: sayfa, uyarının dayandığı veriler ve yeniden oluşturabildiğiniz davranış. Davranışı yeniden oluşturamıyorsanız boşluğu tahminle doldurmak yerine bu sınırı kaydedin.
- İşletme açısından önemli olan tam sayfayı PSI’ta açın. Adresini ve rapor tarihini saklayın. İncelediğiniz talep veya satın alma için önemli olan açılış sayfasını ya da şablonu ekleyin.
- Mobil veya masaüstü seçimini ve veri kapsamını kaydedin. Saha bölümünün URL’yi mi, kaynağı mı, yoksa yetersiz veriyi mi temsil ettiğini aktarın. Sonraki karşılaştırmalarda aynı seçimi kullanın.
- İlgi gerektiren metriğin adını yazın. Ayrı Core Web Vitals sonuçlarını kullanın, ardından ipuçları için tanılama bölümünü okuyun. Eksik örneklemleri görünür tutun.
- Telefonda gerçek bir görevi izleyin. Menüyü açın, ilgili filtreyi kullanın veya ilgili formu doldurun. Neyin geç yüklendiğini, yavaş yanıt verdiğini veya beklenmedik biçimde kaydığını yazın.
- Bir ipucunu bir testle ilişkilendirin. Bakımdan sorumlu kişiden etkilenen eylemi veya yükleme gecikmesini yeniden oluşturmasını ve testin neyi ortaya koyabileceğini açıklamasını isteyin.
Görsel, widget, önbellek ve barındırma konusunda daha geniş kontroller için yavaş bir web sitesinin yaygın nedenleri rehberimizi kullanın. Mevcut görevi başarısız değerlendirme ve bir düzeltmeyi incelemek için gereken kanıtlarla sınırlı tutun.
Düzeltme neleri içermeli?
Tanının desteklediği en küçük değişikliği seçin, ardından nasıl kontrol edeceğiniz konusunda anlaşın. Elinizdeki raporlardan ve işlevlerden başlayın. Sorumlu kişi etkilenen sayfayı veya şablonu adlandırdığında, darboğazı açıkladığında ve öncesi ile sonrası koşullarını karşılaştırılabilir tuttuğunda teknik işi değerlendirmek kolaylaşır.
- Öneriyi metrikle eşleştirin. web.dev LCP rehberi, en büyük öğenin yanıt, keşif, yükleme ve ekrana çizilme aşamalarındaki gecikmeleri ayırır. INP rehberi araştırmayı yavaş etkileşimlere odaklar. CLS rehberi ilk yüklemeden sonra oluşan kaymaları da içerir. Hızı artırmaya yönelik genel bir vaat yerine ilgili kanıtları isteyin.
- Belirlenen nedeni değiştirin ve davranışı yeniden test edin. Bir kaynak veya şablona yönelik düzeltme, web sitesi geliştirme ve bakım işinin parçası olabilir. Neyin ne zaman değiştiğini kaydedin ve mümkün olduğunda nasıl geri alınabileceğini belirtin.
- Müşterinin görevinin hâlâ çalıştığını kontrol edin. Sayfayla ilgili gezinmeyi, formları ve satın alma adımlarını test edin. Rıza kontrollerini çalışır durumda tutun; hukuka uygun rızayı koruyarak davranışlarını ve yerleşimlerini inceleyin.
- Daha fazla kanıta ihtiyaç olup olmadığına karar verin. Mevcut raporlar etkilenen etkileşimi veya sayfayı belirleyemiyorsa ek ölçüm yardımcı olabilir. Ücretli bir hizmet eklemeden önce önerilen izlemenin hangi soruyu yanıtladığını sorun.
Teknik öncelik belirsizse teknik SEO çalışmaları tanılama ve inceleyebileceğiniz bir iş listesiyle başlayabilir. Yeniden tasarım veya optimizasyon paketi için ayrıca gerekçe gerekir.
Bu görev kartını kopyalayabilir ve bilinmeyen alanları boş bırakabilirsiniz:
Sayfa ve işletme açısından önemli görev:
Cihaz ve saha verisi kapsamı:
İlgi gerektiren metrik:
Gözlenen davranış ve test koşulları:
Önerilen neden ve değişiklik:
Yayına alma tarihi:
Değişiklikten sonra karşılaştırılabilir kontrol:
Daha sonraki saha gözlemi ve kalan belirsizlik:İşin fayda sağladığını nasıl kontrol edersiniz?
Önce değişen davranışı inceleyin, ardından sonraki saha kanıtlarını aynı kapsam içinde karşılaştırın. Belgelerine göre PSI, geriye dönük veri toplama penceresini koruyarak saha verilerini günlük günceller. Yayına alma tarihini kayıtla birlikte tutun. Bu pencere, değerlendirmeyi geçmek için vaat edilmiş bir geri sayım değildir.
Hedeflenen metriği ve müşteri görevini benzer test koşullarında karşılaştırın. Belirti sürüyorsa tanıyı yeniden ele alın. Test iyileşiyor ancak sonraki saha kanıtları değişikliği desteklemiyorsa etkilenen sayfaları ve ziyaretçi koşullarını yeniden araştırın. Eksik saha verisi açık bir sınırlama olarak kalmalıdır.
Biz nasıl yardımcı oluruz?
Raporla, önemli sayfalarla ve yeniden oluşturabileceğimiz bir görevle başlarız. Önerilen düzeltmeyi, o düzeltmenin kontrolünü ve ziyaretçilerden daha sonra gelen kanıtları ayrı ele alırız; böylece her kararın inceleyebileceğiniz bir dayanağı olur. Bir web sitesi performans brifi yukarıdaki görev kartıyla başlayabilir; bilinmeyen alanları görünür tutun.
