Sahadaki performansta hata ayıklama

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

Philip Walton

Google, performansı ölçmek ve hata ayıklamak için iki araç kategorisi sunar:

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:

Farklı CLS değerlerine sahip bir PageSpeed Insights Raporu
PageSpeed Insights, mümkün olduğunda hem alan hem de laboratuvar verilerini gösterir ve bunlar farklı olabilir

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 kaymalar 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ümesi hakkında 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:

  1. Hangi öğeyle etkileşimde bulunuldu?
  2. Etkileşimin türü
  3. 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'deki önemli kaynaklar 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 adresine e-posta gönderebilirsiniz.