Analizlerle gerçek kullanıcı sorunlarını belirlemenize ve düzeltmenize yardımcı olması için performans verilerinizi hata ayıklama bilgileriyle ilişkilendirmeyi öğrenin.
Google, performansı ölçmek ve hatalarını ayıklamak için iki kategori araç sunar:
- Laboratuvar araçları: Sayfanızın çeşitli koşulları (örneğin, yavaş bir ağ ve düşük seviyeli bir mobil cihaz) taklit edebilen simüle edilmiş bir ortamda yüklendiği Lighthouse gibi araçlar.
- Alan araçları: Chrome'dan alınan toplu, gerçek kullanıcı verilerine dayanan Chrome Kullanıcı Deneyimi Raporu (CrUX) gibi araçlar. (PageSpeed Insights ve Search Console gibi araçlar tarafından bildirilen alan verilerinin CrUX verilerinden alındığını unutmayın.)
Alan araçları daha doğru veriler (gerçek kullanıcıların deneyimlerini gerçekten temsil eden veriler) sunarken laboratuvar araçları genellikle sorunları belirlemenize ve düzeltmenize yardımcı olma konusunda daha iyidir.
CrUX verileri, sayfanızın gerçek performansını daha iyi temsil eder ancak CrUX puanlarınızı bilmek, performansınızı nasıl iyileştireceğinizi anlamanıza yardımcı olmaz.
Diğer yandan Lighthouse, sorunları belirleyip iyileştirme konusunda belirli önerilerde bulunur. Ancak Lighthouse yalnızca sayfa yükleme sırasında tespit ettiği performans sorunları için önerilerde bulunur. Yalnızca kullanıcı etkileşimi (ör. sayfayı kaydırma veya sayfadaki düğmeleri tıklama) sonucunda ortaya çıkan sorunları algılamaz.
Bu durum önemli bir soruyu gündeme getiriyor: Core Web Vitals veya diğer performans metrikleri için hata ayıklama bilgilerini sahada gerçek kullanıcılardan nasıl yakalayabilirsiniz?
Bu yayında, mevcut Core Web Vitals metriklerinin her biri için ek hata ayıklama bilgileri toplamak üzere hangi API'leri kullanabileceğiniz ayrıntılı olarak açıklanacak ve bu verileri mevcut analiz aracınızda nasıl yakalayabileceğinize dair fikirler verilecektir.
İ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 bilgilerinin toplanmasının en önemli olduğu metriktir. CLS, sayfanın tüm kullanım ömrü boyunca ölçülür. Bu nedenle, kullanıcının sayfayla etkileşim kurma şekli (ne kadar kaydırdığı, neyi tıkladığı vb.) düzen kaymalarının olup olmayacağı ve hangi öğelerin kayacağı konusunda önemli bir etkiye sahip olabilir.
PageSpeed Insights'tan alınan aşağıdaki raporu inceleyin:
CLS için laboratuvardan (Lighthouse) bildirilen değer ile CLS için alandan (CrUX verileri) bildirilen değer arasında büyük fark var. Bu durum, sayfanın Lighthouse'ta test edilirken kullanılmayan çok sayıda etkileşimli içeriğe sahip olabileceği göz önünde bulundurulduğunda mantıklıdır.
Ancak kullanıcı etkileşiminin alan verilerini etkilediğini anlasanız bile, yine de sayfadaki hangi öğelerin kaydığını bilmeniz gerekir. Bu sayede 75. yüzdelik dilimde 0,28 puan elde edebilirsiniz. LayoutShiftAttribution arayüzü bunu mümkün kılar.
Düzen kayması ilişkilendirmesini alma
LayoutShiftAttribution
arayüzü, Layout Instability API'nin
yayınladığı her layout-shift girişinde gösterilir.
Bu arayüzlerin her ikisiyle ilgili ayrıntılı açıklama için Düzen kaymalarında hata ayıklama başlıklı makaleyi inceleyin. Bu yayının amacı doğrultusunda bilmeniz gereken en önemli şey, bir geliştirici olarak sayfada gerçekleşen her düzen kaymasını ve hangi öğelerin kaydığını gözlemleyebileceğinizdir.
Aşağıda, her düzen kaymasını ve kayan öğeleri günlüğe kaydeden örnek bir kod verilmiştir:
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});
Gerçekleşen her düzen kayması için verileri ölçüp analiz aracınıza göndermek muhtemelen pratik değildir. Ancak tüm kaymaları izleyerek en kötü kaymaları takip edebilir ve yalnızca bu kaymalarla ilgili bilgileri raporlayabilirsiniz.
Amaç, her kullanıcı için gerçekleşen her düzen kaymasını belirleyip düzeltmek değil, en fazla sayıda kullanıcıyı etkileyen ve bu nedenle sayfanızın 75. yüzdelik dilimdeki CLS'sine en fazla katkıda bulunan kaymaları belirlemektir.
Ayrıca, her kayma olduğunda en büyük kaynak öğeyi hesaplamanız gerekmez. Bunu yalnızca CLS değerini analiz aracınıza göndermeye hazır olduğunuzda yapmanız gerekir.
Aşağıdaki kod, CLS'ye katkıda bulunan layout-shift girişlerinin listesini alır ve en büyük kaymadan en büyük kaynak öğesini 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 öğeyi belirledikten sonra bunu analiz aracınıza bildirebilirsiniz.
Belirli bir sayfanın CLS'sine en çok katkıda bulunan öğe, kullanıcıdan kullanıcıya değişebilir. Ancak bu öğeleri tüm kullanıcılar arasında toplarsanız en çok sayıda kullanıcıyı etkileyen kayan öğelerin bir listesini oluşturabilirsiniz.
Bu öğelerdeki kaymaların temel nedenini belirleyip düzelttikten sonra, analiz kodunuz sayfalarınızdaki "en kötü" kaymalar olarak daha küçük kaymaları raporlamaya başlar. Sonuç olarak, bildirilen tüm kaymalar yeterince küçük olacak ve sayfalarınız 0,1 olan "iyi" eşiğinin çok altında kalacak.
En büyük kaymayla birlikte yakalamanın yararlı olabileceği diğer bazı meta veriler şunlardır:
- En büyük değişimin zamanı
- En büyük değişiklik sırasında URL yolu (URL'yi dinamik olarak güncelleyen siteler için, örneğin tek sayfalık uygulamalar).
Largest Contentful Paint (LCP)
LCP'yi sahada hata ayıklamak için ihtiyacınız olan temel bilgi, söz konusu sayfa yüklemesi için hangi öğenin en büyük öğe (LCP aday öğesi) olduğudur.
LCP aday öğesinin, aynı sayfa için bile kullanıcıdan kullanıcıya farklılık gösterebileceğini (hatta bunun oldukça yaygın olduğunu) unutmayın.
Bu durumun oluşmasının birkaç nedeni vardır:
- Kullanıcı cihazlarının ekran çözünürlükleri farklıdır. Bu nedenle, sayfa düzenleri farklı olur ve görüntü alanında farklı öğeler görünür.
- Kullanıcılar, en üste kaydırılan sayfaları her zaman yüklemez. Bağlantılar genellikle parça tanımlayıcılar veya hatta metin parçaları içerir. Bu da sayfalarınızın, sayfadaki herhangi bir kaydırma konumunda yüklenip gösterilebileceği anlamına gelir.
- İçerik, mevcut kullanıcı için kişiselleştirilebilir. Bu nedenle, LCP aday öğesi kullanıcıdan kullanıcıya büyük ölçüde değişebilir.
Bu nedenle, belirli bir sayfa için hangi öğenin veya öğe grubunun en yaygın LCP adayı öğesi olacağı konusunda varsayımlarda bulunamazsınız. Gerçek kullanıcı davranışına göre ölçmeniz gerekir.
LCP aday öğesini belirleyin
JavaScript'te LCP aday öğesini belirlemek için Largest Contentful Paint API'yi kullanabilirsiniz. Bu API, LCP zaman değerini belirlemek için kullandığınız API ile aynıdır.
largest-contentful-paint girişlerini gözlemlerken son girişin element özelliğine bakarak mevcut LCP aday öğesini belirleyebilirsiniz:
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 metrik değeriyle birlikte analiz aracınıza gönderebilirsiniz. CLS'de olduğu gibi, bu metrik de hangi öğelerin önce optimize edilmesinin en önemli olduğunu belirlemenize yardımcı olur.
LCP aday öğesine ek olarak, LCP alt bölüm sürelerini ölçmek de faydalı olabilir. Bu süreler, siteniz için hangi optimizasyon adımlarının alakalı olduğunu belirlemede yardımcı olabilir.
Interaction to Next Paint (INP)
INP için alanda yakalanması gereken en önemli bilgiler şunlardır:
- Hangi öğeyle etkileşimde bulunuldu?
- Etkileşimin türü
- Etkileşimin gerçekleştiği zaman
Yavaş etkileşimlerin önemli bir nedeni, ana iş parçacığının engellenmesidir. Bu durum, JavaScript yüklenirken yaygın olarak görülebilir. Yavaş etkileşimlerin çoğunun sayfa yükleme sırasında gerçekleşip gerçekleşmediğini bilmek, sorunu düzeltmek için ne yapılması gerektiğini belirlemeye yardımcı olur.
INP metriği, bir etkileşimin tam gecikme süresini (kayıtlı etkinlik dinleyicilerinin çalıştırılması için geçen süre ve tüm etkinlik dinleyicileri çalıştırıldıktan sonraki karenin boyanması için geçen süre dahil) dikkate alır. Bu nedenle, INP için hangi hedef öğelerin yavaş etkileşimlere yol açtığını ve bu etkileşimlerin türlerini bilmek gerçekten faydalıdır.
Aşağıdaki kod, hedef öğeyi ve INP girişinin 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 girişi olduğunu belirleme yöntemini göstermediğini unutmayın. Bu mantık daha karmaşıktır. Ancak aşağıdaki bölümde, web-vitals JavaScript kitaplığını kullanarak bu bilgileri nasıl alacağınız açıklanmaktadır.
web-vitals JavaScript kitaplığıyla kullanım
Önceki bölümlerde, analiz aracınıza gönderdiğiniz verilere dahil edilecek hata ayıklama bilgilerini yakalamak için bazı genel öneriler ve kod örnekleri verilmiştir.
3. sürümden itibaren web-vitals JavaScript kitaplığı, tüm bu bilgilerin yanı sıra birkaç ek sinyali de ortaya çıkaran bir ilişkilendirme derlemesi içerir.
Aşağıdaki kod örneğinde, performans sorunlarının temel nedenini belirlemeye yardımcı olan bir hata ayıklama dizesi içeren ek bir etkinlik parametresinin (veya özel boyutun) nasıl ayarlanabileceği gösterilmektedir.
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);
onINP(sendToGoogleAnalytics);
Bu kod Google Analytics'e özeldir ancak genel fikir diğer analiz araçları için de geçerlidir.
Bu kod yalnızca tek bir hata ayıklama sinyali hakkında nasıl rapor oluşturulacağını gösterir. Ancak metrik başına birden fazla farklı sinyali toplayıp raporlayabilmek faydalıdır.
Örneğin, INP'de hata ayıklamak için etkileşimde bulunulan öğeyi, etkileşim türünü, zamanı, loadState'i, etkileşim aşamalarını ve daha fazlasını (ör. işlenmesi uzun süren animasyon çerçevesi verileri) toplamak isteyebilirsiniz.
web-vitals ilişkilendirme derlemesi, aşağıdaki INP örneğinde gösterildiği gibi ek ilişkilendirme bilgilerini ortaya çıkarır:
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);
onINP(sendToGoogleAnalytics);
Gösterilen hata ayıklama sinyallerinin tam listesi için web-vitals ilişkilendirme dokümanlarına bakın.
Verileri raporlama ve görselleştirme
Metrik değerleriyle birlikte hata ayıklama bilgilerini toplamaya başladıktan sonraki adım, kalıpları ve trendleri aramaya başlamak için verileri tüm kullanıcılarınızda toplamaktır.
Daha önce de belirtildiği gibi, kullanıcılarınızın karşılaştığı her sorunu ele almanız gerekmez. Özellikle ilk başta, en fazla sayıda kullanıcıyı etkileyen sorunları ele almanız gerekir. Bu sorunlar, Core Web Vitals puanlarınız üzerinde en büyük olumsuz etkiye sahip olan sorunlar da olmalıdır.
GA4 için BigQuery'yi kullanarak verileri sorgulama ve görselleştirme başlıklı makaleyi inceleyin.
Özet
Bu yayının, mevcut performans API'lerini ve web-vitals kitaplığını kullanarak gerçek kullanıcıların ziyaretlerine dayalı performansı teşhis etmenize yardımcı olacak hata ayıklama bilgilerini elde edebileceğiniz belirli yöntemleri özetlemenize yardımcı olduğunu umuyoruz. Bu kılavuz Core Web Vitals'a odaklanmış olsa da kavramlar, JavaScript'te ölçülebilen tüm performans metriklerinin hata ayıklaması için de geçerlidir.
Bir analiz sağlayıcısıysanız ve ürünlerinizi iyileştirip kullanıcılarınıza daha fazla hata ayıklama bilgisi sunmak istiyorsanız burada açıklanan tekniklerden bazılarını kullanabilirsiniz ancak kendinizi yalnızca burada sunulan fikirlerle sınırlamayın. Bu gönderi, genel olarak tüm analiz araçları için geçerli olacak şekilde hazırlanmıştır. Ancak, tek tek analiz araçları daha fazla hata ayıklama bilgisi yakalayabilir ve raporlayabilir (ve bunu yapmalıdır).
Son olarak, API'lerdeki eksik özellikler veya bilgiler nedeniyle bu metriklerde hata ayıklama konusunda eksiklikler olduğunu düşünüyorsanız geri bildiriminizi web-vitals-feedback@googlegroups.com adresine gönderin.