Sahadaki performansta hata ayıklama

Analizlerle gerçek kullanıcı sorunlarını belirleyip düzeltmenize yardımcı olması için performans verilerinizi hata ayıklama bilgileriyle nasıl ilişkilendireceğinizi öğrenin

Philip Walton

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

• Laboratuvar araçları: Sayfanızın, çeşitli koşulları (örneğin, 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'dan alınan gerçek kullanıcı verilerine dayanan Chrome User Experience Report (CrUX) gibi araçlar. (PageSpeed Insights ve Search Console gibi araçlar tarafından bildirilen alan verilerinin CraUX verilerinden alındığını unutmayın.)

Saha araçları daha doğru veriler (gerçek kullanıcıların deneyimini temsil eden veriler) sunsa da laboratuvar araçları sorunları tanımlamanıza ve düzeltmenize yardımcı olmada genellikle daha başarılıdır.

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.

Öte yandan Lighthouse, sorunları tanımlar ve nasıl iyileştirileceğine dair spesifik önerilerde bulunur. Ancak Lighthouse yalnızca sayfa yükleme sırasında keşfettiği performans sorunları için önerilerde bulunur. Yalnızca sayfada kaydırma veya düğmelerin tıklanması gibi kullanıcı etkileşimlerinin bir sonucu olarak ortaya çıkan sorunları algılamaz.

Bu, akıllara şu önemli soruyu getirir: Alandaki gerçek kullanıcılardan Core Web Vitals veya diğer performans metrikleriyle ilgili hata ayıklama bilgilerini nasıl yakalayabilirsiniz?

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 fikirler verilmektedir.

İlişkilendirme ve hata ayıklama için API'ler

Cumulative Layout Shift (CLS)

Tüm Core Web Vitals metrikleri arasında belki de alanda hata ayıklama bilgilerinin toplanmasının en önemli olduğu metrik CLS'dir. 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 bilseniz bile, sayfadaki hangi öğelerin kayarak 75.yüzdelik dilimde 0,28 puan elde ettiğini bilmeniz gerekir. LayoutShiftAttribution arayüzü ise 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.

Her bir düzen kaymasının yanı sıra kayan öğeleri günlüğe kaydeden bir örnek kodu burada bulabilirsiniz:

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 veri ölçüp analiz aracınıza veri göndermek muhtemelen pek pratik olmaz. Ancak tüm değişiklikleri izleyerek en kötü değişimleri takip edebilir ve sadece 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. Bu işlemi 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 kaymaların temel nedenini belirleyip düzelttikten sonra, analiz kodunuz daha küçük kaymaları sayfalarınız için "en kötü" kaymalar olarak raporlamaya başlar. nihayetinde, raporlanan tüm kaymalar, sayfalarınızın 0,1 olan "iyi" eşiğin içerisinde olmasına yetecek 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 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 en üste kaydırılan sayfaları 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, geçerli kullanıcıya göre kişiselleştirilebilir. Bu nedenle LCP aday öğesi, kullanıcıdan kullanıcıya büyük farklılıklar 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 geçerli 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, önce optimize edilmesi gereken en önemli öğeleri belirlemenize yardımcı olur.

LCP aday öğesine ek olarak LCP alt bölüm sürelerini ölçmek de faydalı olabilir. Bu, siteniz için hangi belirli optimizasyon adımlarının alakalı olduğunu belirlemede yararlı olabilir.

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, 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);
}

Hangi event girişinin INP girişi olduğunun nasıl belirleneceğinin bu mantık daha kapsamlı olduğundan, bu kodun gösterilmediğ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 eklenecek hata ayıklama bilgilerini yakalamak için bazı genel öneriler ve kod örnekleri sunulmaktadır.

Sürüm 3'ten itibaren web-önemli 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 belirlemeye yardımcı olacak bir hata ayıklama dizesi içeren ek bir etkinlik parametresini (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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Bu kod Google Analytics'e özgüdür, ancak genel fikir diğer analiz araçlarına da aktarılmalıdır.

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 yapısı, INP için aşağıdaki örnekte gösterildiği gibi ek ilişkilendirme bilgileri 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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Sunulan hata ayıklama sinyallerinin tam listesi için web önemli öğeleri 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ıpları ve trendleri aramaya başlamak için tüm kullanıcılarınız genelinde verileri toplamaktır.

Daha önce de belirtildiği gibi, kullanıcılarınızın karşılaştığı her bir sorunu ele almanız gerekmez. Özellikle en başta en yüksek sayıda kullanıcıyı etkileyen ve ayrıca Core Web Vitals puanlarınız üzerinde en büyük olumsuz etkiye sahip olan sorunlar da olan sorunları ele almak istersiniz.

GA4 için BigQuery kullanarak verileri sorgulama ve görselleştirme ile ilgili özel makaleyi inceleyin.

Özet

Bu yayının, sahadaki gerçek kullanıcı ziyaretlerine dayanarak performansı teşhis etmeye yardımcı olacak hata ayıklama bilgileri edinmek için mevcut performans API'lerini ve web-vitals kitaplığını belirli yöntemleri açıklamaya yardımcı olduğunu umuyoruz. Bu kılavuz, Core Web Vitals'a odaklanılsa da bu kavramlar JavaScript'te ölçülebilen tüm performans metriklerinde 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.