Analizlerle gerçek kullanıcı sorunlarını tespit edip düzeltmenize yardımcı olması için performans verilerinizi hata ayıklama bilgileriyle nasıl ilişkilendireceğinizi öğrenin
Google, performansı ölçmek ve hata ayıklamak için iki kategoride araç sunar:
- Laboratuvar araçları: Sayfanızın, çeşitli koşulları (ör. yavaş bir ağ ve düşük teknolojiye sahip bir mobil cihaz) taklit edebilecek simüle edilmiş bir ortamda yüklendiği Lighthouse gibi araçlar.
- Alan araçları: Chrome'daki gerçek kullanıcıların toplu verilerini temel alan Chrome Kullanıcı Deneyimi Raporu (CrUX) gibi araçlar. (PageSpeed Insights ve Search Console gibi araçlar tarafından raporlanan alan verilerinin CrUX verilerinden alındığını unutmayın.)
Alan araçları daha doğru veriler (gerçek kullanıcıların deneyimini gerçekten temsil eden veriler) sunarken laboratuvar araçları genellikle sorunları tespit etmenize ve düzeltmenize yardımcı olur.
CrUX verileri, sayfanızın gerçek performansını daha iyi yansıtır ancak CrUX puanlarınızı bilmenin, performansınızı nasıl artıracağınızı bulmanıza yardımcı olma olasılığı düşüktür.
Lighthouse ise sorunları tespit eder ve iyileştirmeyle ilgili belirli öneriler sunar. Ancak Lighthouse yalnızca sayfa yükleme sırasında tespit ettiği performans sorunlarıyla ilgili öneriler sunar. Yalnızca sayfada kaydırma veya düğmeleri tıklama gibi kullanıcı etkileşimlerinin bir sonucu olarak ortaya çıkan sorunları algılamaz.
Bu da önemli bir soruyu gündeme getiriyor: Core Web Vitals veya diğer performans metrikleri için sahadaki gerçek kullanıcılardan hata ayıklama bilgilerini nasıl toplayabilirsiniz?
Bu yayında, mevcut Core Web Vitals metriklerinin her biriyle ilgili ek hata ayıklama bilgileri toplamak için hangi API'leri kullanabileceğiniz ayrıntılı olarak açıklanmakta ve bu verileri mevcut analiz aracınızda nasıl yakalayacağınıza dair fikir edinebilirsiniz.
İlişkilendirme ve hata ayıklama için API'ler
Cumulative Layout Shift (CLS)
Tüm Core Web Vitals metriklerinden CLS, alanda hata ayıklama bilgilerinin toplanmasının en önemli olduğu metriktir. CLS, sayfanın kullanım ömrü boyunca ölçülür. Bu nedenle, kullanıcının sayfayla etkileşime geçme şekli (sayfada ne kadar kaydırma yaptıkları, neyi tıkladıkları vb.), düzen kaymalarının ve hangi öğelerin değişeceği üzerinde önemli bir etkiye sahip olabilir.
PageSpeed Insights'ın şu raporunu inceleyin:
Laboratuvarda (Lighthouse) CLS için bildirilen değer (CrUX verileri) oldukça farklıdır. Bu nedenle sayfanın Lighthouse'ta test edildiğinde kullanılmayan çok fazla etkileşimli içerik olabileceğini düşünüyorsanız bu mantıklıdır.
Ancak kullanıcı etkileşiminin alan verilerini etkilediğini anlasanız bile, 75. yüzdelik dilimde 0,28 puanla sonuçlanan sayfadaki öğelerin ne olduğunu bilmeniz gerekir. LayoutShiftAttribution arayüzü bunu mümkün kılar.
Düzen kayması ilişkilendirmesini al
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 Hata ayıklama düzen kaymaları bölümüne bakın. Bu gönderinin amaçları doğrultusunda, geliştirici olarak bilmeniz gereken en önemli şey, sayfada gerçekleşen her düzen kaymasının yanı sıra hangi öğelerin değiştiğini gözlemleyebilmenizdir.
Aşağıda, her düzen kaymasının yanı sıra kaydırılan öğ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 bir düzen değişikliği için ölçüm yapıp analiz aracınıza veri göndermek muhtemelen pratik değildir. Ancak tüm değişiklikleri izleyerek en kötü değişiklikleri takip edebilir ve yalnızca bunlarla ilgili bilgileri raporlayabilirsiniz.
Amaç, her kullanıcı için meydana gelen her bir düzen kaymasını tanımlayıp düzeltmek değildir. Amaç, en yüksek kullanıcı sayısını etkileyen ve böylece sayfanızın 75. yüzdelik dilimde CLS'sine en fazla katkıda bulunan kaymaları belirlemektir.
Ayrıca, her değişiklik 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 değişimdeki 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 sayfa için CLS'ye en çok katkıda bulunan öğe muhtemelen kullanıcıdan kullanıcıya değişiklik gösterecektir. Ancak, tüm kullanıcılar genelinde bu öğeleri toplarsanız, en fazla sayıda kullanıcıyı etkileyen öğelerin bir listesini oluşturabilirsiniz.
Bu öğelerdeki değişikliklerin temel nedenini tespit edip düzelttikten sonra, analiz kodunuz sayfalarınızdaki "en kötü" değişiklikler olarak daha küçük değişiklikleri bildirmeye başlar. Raporlanan tüm kaymalar, sonunda sayfalarınızın 0,1 olan "iyi" eşiğinin çok altında kalacak kadar küçük olacaktır.
En büyük değiştirme kaynağı öğesiyle birlikte yakalanması faydalı olabilecek diğer bazı meta veriler şunlardır:
- En büyük değişimin gerçekleştiği zaman
- En büyük değişim anındaki URL yolu (Tek Sayfalık Uygulamalar gibi URL'yi dinamik olarak güncelleyen siteler için).
Largest Contentful Paint (LCP)
Alandaki LCP'de hata ayıklamak için ihtiyacınız olan birincil bilgi, söz konusu sayfa yüklemesi için hangi öğenin en büyük öğe (LCP aday öğesi) olduğudur.
LCP aday öğesinin, tam olarak aynı sayfa için bile kullanıcıdan kullanıcıya farklı olmasının tamamen mümkün olduğunu unutmayın. Aslında bu çok yaygın bir durumdur.
Bu durumun oluşmasının birkaç nedeni vardır:
- Kullanıcı cihazları farklı ekran çözünürlüklerine sahiptir. Bu durum, farklı sayfa düzenlerine ve dolayısıyla görüntü alanında farklı öğelerin görünmesine neden olur.
- Kullanıcılar her zaman sayfaları en üste kaydırarak yüklemez. Bağlantılar çoğu zaman parça tanımlayıcıları, hatta metin parçaları içerir. Bu, sayfalarınızın sayfadaki herhangi bir kaydırma konumunda yüklenip görüntülenmesinin mümkün olduğu anlamına gelir.
- İçerik, mevcut kullanıcı için kişiselleştirilmiş olabilir. Bu nedenle, LCP aday öğesi kullanıcıdan kullanıcıya büyük ölçüde değişiklik gösterebilir.
Bu nedenle, hangi öğenin veya öğe kümesinin belirli bir sayfa için en yaygın LCP aday öğesi olacağına dair varsayımlarda bulunamazsınız. Gerçek kullanıcı davranışına göre ölçmeniz gerekir.
LCP aday öğesini tanımlayın
JavaScript'te LCP aday öğesini belirlemek için LCP zaman değerini belirlemek üzere kullandığınız API olan Largest Contentful Paint API'yi kullanabilirsiniz.
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, öncelikli olarak optimize edilmesi gereken öğeleri belirlemenize yardımcı olur.
LCP aday öğesine ek olarak LCP alt bölüm sürelerini ölçmek de yararlı olabilir. Bu, siteniz için hangi optimizasyon adımlarının alakalı olduğunu belirlemenize yardımcı olabilir.
Interaction to Next Paint (INP)
INP için alanda toplanması 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, JavaScript yüklenirken sık karşılaşılan bir durum olan engellenmiş bir ana iş parçacığıdır. En fazla yavaş etkileşimlerin sayfa yüklenirken mi gerçekleştiğini bilmek, bu sorunu çözmek için yapılması gerekenleri belirlemeye yardımcı olur.
INP metriği, bir etkileşimin tam gecikmesini göz önünde bulundurur. Bunlara, kayıtlı etkinlik işleyicileri çalıştırmak için gereken süre ve tüm etkinlik dinleyicileri çalıştırıldıktan sonra bir sonraki kareyi boyamak için gereken süre dahildir. Bu, INP için hangi hedef öğelerin yavaş etkileşimle sonuçlanma eğiliminin ve bunların ne tür etkileşimler olduğunun bilinmesinin gerçekten yararlı olduğu anlamına gelir.
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 mantık daha karmaşık olduğundan, bu kodun hangi event
girişinin INP girişi olduğunu nasıl belirleyeceğinizi göstermediğini unutmayın. Ancak aşağıdaki bölümde web-vitals JavaScript kitaplığını kullanarak bu bilgilere nasıl ulaşacağı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 sunulmaktadır.
Sürüm 3'ten itibaren, web-vitals JavaScript kitaplığı, tüm bu bilgileri gösteren bir ilişkilendirme derlemesi ve birkaç ek sinyal içerir.
Aşağıdaki kod örneğinde, performans sorunlarının temel nedenini belirlemenize yardımcı olacak bir hata ayıklama dizesi içeren ek bir etkinlik parametresi (veya özel boyut) nasıl ayarlayabileceğiniz 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 özgüdür ancak genel fikir diğer analiz araçlarında da geçerlidir.
Bu kod yalnızca tek bir hata ayıklama sinyali hakkında nasıl rapor oluşturulacağını da gösterir ancak metrik başına birden fazla farklı sinyali toplayıp raporlayabilmek yararlı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ı (Uzun Animasyon Karesi verileri gibi) toplamak isteyebilirsiniz.
web-vitals
ilişkilendirme derlemesi, INP için aşağıdaki örnekte gösterildiği gibi ek ilişkilendirme bilgilerini gösterir:
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);
Sunulan hata ayıklama sinyallerinin tam listesi için web kritik öneme sahip ilişkilendirme dokümanlarını inceleyin.
Verileri raporlama ve görselleştirme
Metrik değerleriyle birlikte hata ayıklama bilgilerini toplamaya başladıktan sonraki adım, kalıp ve trendler aramaya başlamak için tüm kullanıcılarınızdaki verileri toplamaktır.
Daha önce de belirtildiği gibi, kullanıcılarınızın karşılaştığı her sorunu gidermeniz gerekmez. Özellikle ilk başta, en fazla sayıda kullanıcıyı etkileyen sorunları gidermek istersiniz. Bu sorunlar, Core Web Vitals puanlarınızı en olumsuz şekilde etkileyen sorunlar da olmalıdır.
GA4 için BigQuery'yi kullanarak verileri sorgulama ve görselleştirme ile ilgili özel makaleyi inceleyin.
Özet
Bu makalenin, mevcut performans API'lerini ve web-vitals
kitaplığını kullanarak hata ayıklama bilgilerini elde etme ve performansı, sahada gerçek kullanıcı ziyaretlerine göre teşhis etme konusunda size yardımcı olduğunu umuyoruz. Bu kılavuzda Core Web Vitals'a odaklanılmış olsa da buradaki kavramlar, JavaScript'te ölçülebilir olan tüm performans metrikleriyle ilgili hata ayıklama için de geçerlidir.
Performansı ölçmeye yeni başlıyorsanız ve zaten Google Analytics kullanıcısıysanız Web Vitals Rapor aracı, Core Web Vitals metriklerine ilişkin hata ayıklama bilgilerinin raporlanmasını zaten desteklediğinden Web Verileri Raporu aracı iyi bir başlangıç noktası olabilir.
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 istiyorsanız burada açıklanan bazı teknikleri uygulayabilirsiniz. Ancak kendinizi yalnızca burada sunulan fikirlerle sınırlandırmayın. Bu gönderinin genel olarak tüm analiz araçları için geçerli olması amaçlanmıştır. Bununla birlikte, bağımsız analiz araçları daha da fazla hata ayıklama bilgisini yakalayıp raporlayabilir.
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.