Performans verilerinizi hata ayıklama bilgileriyle nasıl ilişkilendireceğinizi öğrenin analizleri kullanarak gerçek kullanıcı sorunlarını belirleyip düzeltmenize yardımcı olur
Google, performansı ölçmek ve hata ayıklamak için iki araç kategorisi sunar:
- Laboratuvar araçları: Sayfanızın bir çeşitli koşulları taklit edebilen (örneğin, yavaş bir ağ ve düşük teknoloji mobil cihaz).
- Alan araçları: Chrome User Experience gibi araçlar Bildir (CrUX) gibi Google Cloud Platform'u kullanıma sunuyoruz. ( PageSpeed gibi araçlar tarafından bildirilen alan verileri Analizler ve Arama Console'un kaynağı: CrUX verileri.)
Alan araçları daha doğru veriler sunarken, gerçek kullanıcı deneyimi sunar. Laboratuvar araçları, sorunları tespit edip sorunları giderme konusunda genellikle daha başarılıdır. sorunları.
CrUX verileri, sayfanızın gerçek performansını daha iyi yansıtır ancak CrUX puanlarınızın, performansınızı nasıl iyileştireceğinizi bazı yolları da görmüştük.
Öte yandan Lighthouse, sorunları tespit eder ve ve iyileştirmenin yolları arasındadır. Ancak Lighthouse yalnızca önerilerde bulunur. performans sorunlarına yönelik performansı gösterir. Sorunları algılamaz yalnızca kaydırma veya tıklama gibi kullanıcı etkileşiminin bir sonucu olarak görünen düğmesini tıklayın.
Bu da akıllarda şu önemli bir soru var: Bir kullanıcı için hata ayıklama bilgilerini Sahadaki gerçek kullanıcılardan alınan Core Web Vitals veya diğer performans metrikleri mi?
Bu yayında, ek veri toplamak için hangi API'leri kullanabileceğiniz ve yeni Core Web Vitals metriklerinin her biri için hata ayıklama bilgilerini Bu verileri mevcut analiz aracınızda nasıl yakalayabileceğinizle ilgili olarak size fikir verebilir.
İlişkilendirme ve hata ayıklama için API'ler
Cumulative Layout Shift (CLS)
Tüm Core Web Vitals metrikleri arasında CLS belki de alanda hata ayıklama bilgisi toplamak en önemli adımdır. CLS ölçülür (ör. bir kullanıcının sayfayla etkileşime geçme şekli) tüm sayfa ömrü boyunca sayfa içeriği, ne kadar kaydırıldıkları, ne tıkladıkları vb. olup olmadığı ve hangi öğelerin kaydığı üzerindeki etkisini görebilirsiniz.
PageSpeed Insights'ın şu raporunu inceleyin:
Lab'de (Lighthouse) CLS için bildirilen değer ile alanı (CrUX verileri) oldukça farklı ve göz önünde bulundurduğunuzda, sayfada çok sayıda etkileşimli içerik olabileceğini emin olun.
Ancak, kullanıcı etkileşiminin alan verilerini etkilediğini bilseniz bile, 0,28 puana ulaşmak için sayfadaki hangi öğelerin kaydığını öğrenmeniz gerekir. 75. yüzdelik dilimde. LayoutShiftAttribution arayüzü bunu mümkün kılıyor.
Düzen kayması ilişkilendirmesini al
LayoutShiftAttribution
Düzen Kararsızlığı'nı içeren her layout-shift
girişinde
API yayar.
Bu arayüzlerin her ikisiyle ilgili ayrıntılı açıklama için Hata ayıklama düzenine vardiyalar. Şu amaçlara yönelik olarak: bilmeniz gereken en önemli konu, bir geliştirici olarak herkesin sayfada meydana gelen her düzen kaymasını ve hangi öğelerin değişmektedir.
Burada, öğelerin yanı sıra her düzen kaymasını günlüğe kaydeden örnek bir kod verilmiştir. şu kadar değişti:
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
Büyük olasılıkla, projeniz için yeni yöntemler gerçekleşen her düzen kayması; Ancak tüm değişimleri izleyerek en kötü değişimleri takip edebilir ve sadece bunlarla ilgili bilgi raporlayabilir.
Hedef, ekibinizin kullandığı her bir düzen kaymasını tanımlayıp düzeltmek her kullanıcı; Ancak hedef, mümkün olan en fazla tıklamayı etkileyen kaymaları ve böylece sayfanızın CLS'sine en fazla 75. yüzdelik dilimde katkıda bulunur.
Ayrıca, bir çift değer olduğunda en büyük kaynak Bunu yalnızca CLS değerini web sitenize gönderilmeye hazır olduğunuzda analiz aracımıza erişim sağlar.
Aşağıdaki kod katkıda bulunan layout-shift
girişin listesini alır
değerini CLS'ye dönüştürür ve en büyük değişimden en büyük kaynak öğeyi döndürür:
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
En büyük değişime katkıda bulunan en büyük elementi belirledikten sonra bunu analiz aracınıza bildirebilirsiniz.
Belirli bir sayfa için CLS'ye en fazla katkıda bulunan öğe ancak bu öğeleri tüm kullanıcılardan toplarsanız en fazla sayıda kullanıcıyı etkileyen kayan öğelerin bir listesini oluşturabilirsiniz.
Bu metriklerdeki kaymaların temel nedenini belirleyip düzelttikten sonra varsa, analiz kodunuz daha küçük değişimleri "en kötü" saptarsınız. nihayetinde, raporlanan tüm değişimler sayfalarınızın "iyi" kategorisinde eşiği 0,1!
En büyük değişimle birlikte yakalanması faydalı olabilecek bazı diğer meta veriler kaynak öğedir:
- En büyük değişimin zamanı
- En büyük değişim anındaki URL yolu (dinamik olarak dönüşüm gerçekleştiren siteler için URL'yi güncelleyin (örneğin, Tek Sayfalık Uygulamalar).
Largest Contentful Paint (LCP)
Alandaki LCP'de hata ayıklamak için, ihtiyacınız olan temel bilgi, öğesi, söz konusu belirli öğe için en büyük öğedir (LCP aday öğesi) yardımcı olabilir.
LCP değerinin, aslında çok sık karşılaşılan bir durum olsa da, Aday öğesi, tam olarak aynı kullanıcı grubu için bile sayfasını ziyaret edin.
Bu durumun oluşmasının birkaç nedeni vardır:
- Kullanıcı cihazlarının ekran çözünürlükleri farklı olduğundan sayfa düzenleri ve dolayısıyla farklı öğelerin görüntü alanında görünür olmasını sağlar.
- Kullanıcılar her zaman en üste kaydırılan sayfaları yüklemez. Çoğu zaman bağlantılar parça tanımlayıcıları, hatta metin parçaları oluşturur; bu, öğelerin .
- İçerik, mevcut kullanıcı için kişiselleştirilebilir. Bu nedenle LCP aday öğesi kullanıcıdan kullanıcıya büyük farklılıklar gösterebilir.
Bu, hangi öğe veya öğe kümesiyle ilgili varsayımlarda bulunamayacağınız anlamına gelir belirli bir sayfa için en yaygın LCP aday öğesi olur. Şunları yapmanız gerekir: gerçek kullanıcı davranışına dayalı olarak ölçmelerini sağlar.
LCP aday öğesini tanımlayın
JavaScript'te LCP aday öğesini belirlemek için En büyük Contentful Paint API, LCP zaman değerini belirlemek için kullandığınız API'nin aynısını kullanın.
largest-contentful-paint
girişlerini gözlemlerken, her bir
son girişin element
özelliğine bakarak mevcut LCP aday öğesi:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
.
LCP aday öğesini öğrendikten sonra analiz aracınıza gönderebilirsiniz metriğiyle birlikte gösterilir. CLS'de olduğu gibi bu, hangi anahtar kelimelerin ele alınması gerekiyor.
LCP aday öğesine ek olarak LCP alt bölüm süreleri: Bu yararlı olabilir belirlemekte daha etkilidir.
Sonraki Boyamayla Etkileşim (INP)
INP için sahada yakalanması gereken en önemli bilgiler şunlardır:
- Hangi öğeyle etkileşimde bulunuldu?
- Etkileşimin türü
- Etkileşimin ne zaman gerçekleştiği
Yavaş etkileşimlerin önemli bir nedeni, engellenen bir ana iş parçacığıdır. yaygın olarak kullanılmamalıdır. En yavaş etkileşimin olup olmadığını öğrenme veya sayfa yükleme sırasında meydana gelen sorunlar, bu sorunu çözmek için yapılması gerekenleri düşünmeye başlamışsınızdır.
INP metriği, bir değerin tam gecikmesini etkileşimi; kayıtlı etkinlik işleyicileri otomatik olarak ve tüm etkinlik dinleyicilerinden sonra bir sonraki kareyi boyamak için gereken süreyi belirler. Bu, INP için hangi hedefin hedeflendiğini bilmek, öğeler genellikle yavaş etkileşimlere neden olur ve ne tür öğreneceğiz.
Aşağıdaki kod, INP girişinin hedef öğesini ve zamanını günlüğe kaydeder.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
Bu kodun, hangi event
girişinin INP olduğunun nasıl belirleneceğini göstermediğini unutmayın.
çünkü bu mantık daha karmaşıktır. Ancak aşağıdaki bölümde
web-vitals JavaScript kitaplığıdır.
Web-vitals JavaScript kitaplığıyla kullanım
Önceki bölümlerde, fikir edinmenize yardımcı olacak bazı genel öneriler ve hata ayıklama bilgilerinden yararlanabilirsiniz.
Sürüm 3'ten itibaren web-vitals JavaScript kitaplığında bir atıf geliştirmenin tüm bu bilgileri ve birkaç ilaveyi sinyalleri de kullanabilirsiniz.
Aşağıdaki kod örneğinde, ek bir etkinliği nasıl ayarlayabileceğiniz gösterilmektedir parametresi (veya özel boyut) içeren bir performansın temel nedenini belirlemeye yardımcı olmak için yararlı olan hata ayıklama dizesi sorunları.
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Bu kod Google Analytics'e özeldir, ancak genel yaklaşım diğer analiz araçlarıyla da uyumlu.
Bu kod yalnızca tek bir hata ayıklama sinyali hakkında nasıl rapor oluşturulacağını gösterir ancak her birinde birden fazla farklı sinyali toplayıp raporlamak için metriğine karşılık gelir.
Örneğin, INP hatalarını ayıklamak için etkileşim türü, zaman, loadState, etkileşim aşama ve daha fazlasından (Uzun Animasyon Karesi verileri gibi) oluşur.
web-vitals
ilişkilendirme derlemesi, ilişkilendirmeyle ilgili ek bilgiler sunar.
INP için aşağıdaki örnekte gösterildiği gibi:
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Web kritik önemdeki içerikler ilişkilendirmesine belgeleri hata ayıklama sinyallerinin tam listesi
Verileri raporlama ve görselleştirme
Metrik değerleriyle birlikte hata ayıklama bilgilerini toplamaya başladıktan sonra bir sonraki adım, kullanıcılarınızı aramaya başlamak için ve trendleri takip edebilirsiniz.
Daha önce de belirtildiği gibi, her bir sorunu tek tek ele almanız gerekmez. bağlantı kurmak isterseniz (özellikle de başlangıçta) veya en fazla sayıda kullanıcıyı etkileyenler; bunlar da Core Web Vitals puanlarınız üzerinde en büyük olumsuz etkiye sahip olan
GA4 için "Google Analytics 4" ile verileri sorgulama ve görselleştirme BigQuery.
Özet
Umarız bu gönderinin amacı
hata ayıklama bilgilerini almak için mevcut performans API'lerini ve web-vitals
kitaplığını kullanın
alandaki gerçek kullanıcı ziyaretlerine dayanarak performansı teşhis etmeye yardımcı olabilir. Bu
kılavuz, Core Web Vitals'a odaklanmıştır. Kavramlar hata ayıklama için de geçerlidir
JavaScript'te ölçülebilen herhangi bir performans metriğine karşılık gelir.
Performansı ölçmeye yeni başlıyorsanız ve Google Analytics kullanıcısıysanız Web Verileri Raporu aracı iyi bir başlangıç noktası olabilir çünkü Core Web sitesi için hata ayıklama bilgilerinin raporlanmasını zaten Vitals metrikleri.
Bir analiz tedarikçi firmasıysanız ve ürünlerinizi iyileştirmek ve kullanıcılarınıza daha fazla hata ayıklama bilgisi sağlamak için, teknikler burada anlatılmıştır, ancak kendinizi yalnızca sunulan fikirlerle sınırlamayın burayı tıklayın. Bu yayının amacı, genel olarak tüm analiz araçları için geçerlidir; ancak bağımsız analiz araçları, verileri analiz edip daha fazla hata ayıklama bilgisi içeriyor.
Son olarak, 2023'te raporlama nedeniyle bu metriklerde hata ayıklama konusunda kendisinde eksik özellik veya bilgi olup olmadığını sorun. web-vitals-feedback@googlegroups.com.