Sahadaki performansta hata ayıklama

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

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

• Laboratuvar araçları: Sayfanızın çeşitli koşulları (örneğin, yavaş ağ ve düşük teknolojili mobil cihaz) taklit edebilen simüle edilmiş bir ortamda yüklendiği Lighthouse gibi araçlar.
• Saha araçları: Chrome'daki toplu, gerçek kullanıcı 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 CraUX verilerinden elde edildiğini unutmayın.)

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

CrUX verileri, sayfanızın gerçek performansını daha iyi temsil eder. Ancak CrUX puanlarınızı bilmek, performansınızı nasıl artıracağınızı bulmanıza yardımcı olma olasılığı düşüktür.

Öte yandan Lighthouse, sorunları belirleyecek ve iyileştirme yapılması için belirli önerilerde bulunacaktır. Ancak Lighthouse yalnızca sayfa yükleme sırasında bulduğu performans sorunları için önerilerde bulunur. Yalnızca sayfadaki kaydırma veya düğmeleri tıklama gibi kullanıcı etkileşimlerinin sonucu olarak ortaya çıkan sorunları tespit etmez.

Bu durumda akla gelen önemli bir soru şudur: Sahadaki gerçek kullanıcılardan Önemli Web Verileri için hata ayıklama bilgilerini veya diğer performans metriklerini 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 açıklanacak ve bu verileri mevcut analiz aracınızda nasıl yakalayacağınız konusunda fikirler vereceğiz.

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

CLS

Tüm Önemli Web Verileri metrikleri arasında CLS belki de alanda hata ayıklama bilgilerini toplamak için en önemli unsurdur. CLS, sayfanın tüm ömrü boyunca ölçülür. Bu nedenle, kullanıcının sayfayla etkileşim kurma şekli (ne kadar kaydırdıkları, neyi tıkladıkları vb.), düzende kaymalar olup olmadığı ve hangi öğelerin kayıyor olması üzerinde önemli bir etki yaratabilir.

PageSpeed Insights'ın aşağıdaki raporunu inceleyin:

Laboratuvarda (Lighthouse) CLS için bildirilen değer ile sahadaki CLS değeri (CrUX verileri) oldukça farklıdır. Bu nedenle, sayfanın Lighthouse'da test edildiğinde kullanılmayan çok sayıda etkileşimli içerik barındırabileceğini göz önünde bulundurursanız bu durum mantıklı olacaktır.

Ancak kullanıcı etkileşiminin alan verilerini etkilediğini bilseniz bile, sayfada hangi öğelerin 75.yüzdelik dilimde 0,3'lük bir puan elde etmek için kaydığını bilmeniz gerekir.

LayoutShiftAttribution arayüzü, bunu mümkün kılar.

Düzen kayması ilişkilendirmesi alma

LayoutShiftAttribution arayüzü, Layout Instability API'nin yayınladığı her layout-shift girişinde gösterilir.

Bu iki arayüzün de ayrıntılı açıklaması için Düzen kaydırmalarında hata ayıklama bölümünü inceleyin. Bu yayının amaçları doğrultusunda, bir geliştirici olarak sayfada gerçekleşen her düzen kaymasını ve hangi öğelerin değişeceğini gözlemleyebilmeniz gerekir.

Aşağıda, her düzen kaymasını ve kayan öğeleri günlüğe kaydeden bazı örnek 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 değişikliği için ölçüm yapmak ve analiz aracınıza veri göndermek muhtemelen pratik değildir. Ancak tüm vardiyaları izleyerek en kötü değişimleri takip edebilir ve sadece bunlarla ilgili bilgileri raporlayabilirsiniz.

Amaç, her kullanıcı için gerçekleşen her düzen kaymasını tanımlamak ve düzeltmek değildir. Amaç, en fazla kullanıcıyı etkileyen ve böylece 75. yüzdelik dilimde sayfanızın CLS'sine en fazla katkıda bulunan kaymaları tanımlamaktır.

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 bir listesini alır ve en büyük değişiklikteki 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 öğeyi belirledikten sonra, bunu analiz aracınıza raporlayabilirsiniz.

Belirli bir sayfa için CLS'ye en fazla katkıda bulunan öğe kullanıcıdan kullanıcıya farklılık gösterebilir ancak bu öğeleri tüm kullanıcılar genelinde toplarsanız en fazla kullanıcıyı etkileyen değişen öğelerin bir listesini oluşturabilirsiniz.

Bu öğelerdeki kaymaların temel nedenini belirleyip düzelttikten sonra Analytics kodunuz, sayfalarınızda "en kötü" değişimler olarak daha küçük değişimleri raporlamaya başlar. Sonuç olarak, bildirilen tüm kaymalar, sayfalarınızın 0,1 olan "iyi" eşiğinin altında kalmasını sağlayacak kadar küçük olacaktır!

En büyük kayma kaynak öğesiyle birlikte yakalanması yararlı olabilecek diğer meta veriler şunlardır:

• En büyük değişimin zamanı
• En büyük değişim sırasındaki URL yolu (Tek Sayfalık Uygulamalar gibi URL'yi dinamik olarak güncelleyen siteler için).

LCP

Sahada LCP'de hata ayıklamak için ihtiyacınız olan birincil bilgi, söz konusu sayfa yüklemesinde hangi öğenin en büyük öğe (LCP aday öğesi) olduğudur.

LCP aday öğesinin, tamamen aynı sayfa için bile, kullanıcıdan kullanıcıya farklılık göstermesi tamamen mümkün, aslında oldukça 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 da farklı sayfa düzenlerine, dolayısıyla da farklı öğelerin görüntü alanında görünmesine yol açar.
• 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 da, sayfalarınızın sayfadaki herhangi bir kaydırma konumunda yüklenmesi ve görüntülenmesinin mümkün olduğu 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 farklılık gösterebilir.

Bu, hangi öğenin veya öğe kümesinin belirli bir sayfa için en yaygın LCP aday öğesi olacağı hakkında varsayımda bulunamayacağınız anlamına gelir. Bunu gerçek kullanıcı davranışına göre ölçmeniz gerekir.

LCP aday öğesini tanımlama

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'nin aynısı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, ö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 yararlı olabilir. Bu, siteniz için hangi optimizasyon adımlarının alakalı olduğunu belirlemede yararlı olabilir.

FID

Alanda FID hatası ayıklamak için FID'nin, genel ilk giriş etkinliği gecikmesinin yalnızca gecikme kısmını ölçtüğünü unutmamak önemlidir. Yani, kullanıcının etkileşimde bulunduğu şey, etkileşimde bulunulduğu sırada ana iş parçacığında olan diğer öğeler kadar önemli değildir.

Örneğin, sunucu tarafı oluşturmayı (SSR) destekleyen birçok JavaScript uygulaması, kullanıcı girişiyle etkileşim kurmadan, yani içeriği etkileşimli hale getirmek için gereken JavaScript yüklenmeden önce ekranda oluşturulabilecek statik HTML sunar.

Bu tür uygulamalarda, ilk girişin hidrasyondan önce mi yoksa sonra mı yapıldığını bilmek çok önemli olabilir. Sıvı alımı tamamlanmadan sayfayla çok sayıda kişinin etkileşimde bulunmaya çalıştığı ortaya çıkarsa sayfalarınızı etkileşimli görünen bir durum yerine devre dışı veya yükleme durumunda oluşturmayı düşünün.

Uygulama çerçeveniz sulama zaman damgasını açığa çıkarıyorsa bu zaman damgasını first-input girişinin zaman damgasıyla karşılaştırarak ilk girişin hidrasyondan önce mi sonra mı olduğunu belirleyebilirsiniz. Çerçeveniz bu zaman damgasını göstermiyorsa veya hiç hidrasyon kullanmıyorsa girişin JavaScript yüklemeyi tamamlamasından önce mi yoksa sonra mı oluştuğu başka bir yararlı sinyal olabilir.

DOMContentLoaded etkinliği, sayfanın HTML'si tamamen yüklendikten ve ayrıştırıldıktan sonra tetiklenir. Eşzamanlı, ertelenmiş veya modül komut dosyalarının (statik olarak içe aktarılan tüm modüller dahil) yüklenmesini beklemek de buna dahildir. Dolayısıyla, bu etkinliğin zamanlamasını kullanıp FID'in gerçekleştiği zamanla karşılaştırabilirsiniz.

Aşağıdaki kod, first-input girişlerini gözlemler ve ilk girişin DOMContentLoaded etkinliği sona ermeden önce gerçekleşip gerçekleşmediğini günlüğe kaydeder:

new PerformanceObserver((list) => {
  const fidEntry = list.getEntries()[0];
  const navEntry = performance.getEntriesByType('navigation')[0];
  const wasFIDBeforeDCL =
    fidEntry.startTime < navEntry.domContentLoadedEventStart;

  console.log('FID occurred before DOMContentLoaded:', wasFIDBeforeDCL);
}).observe({type: 'first-input', buffered: true});

FID hedef öğesini ve etkinlik türünü tanımlama

Faydalı olabilecek ek hata ayıklama sinyalleri, etkileşimde bulunulan öğenin yanı sıra etkileşim türünü (mousedown, keydown ve pointerdown gibi) içerir. Öğenin kendisi ile olan etkileşim FID'ye katkıda bulunmasa da (FID'nin yalnızca toplam etkinlik gecikmesinin gecikme kısmı olduğunu unutmayın). Kullanıcılarınızın hangi öğelerle etkileşim kurduğunu bilmek, FID'yi en iyi şekilde nasıl iyileştirebileceğinizi belirlemek için faydalı olabilir.

Örneğin, kullanıcınızın ilk etkileşimlerinin büyük çoğunluğu belirli bir öğeyle gerçekleştiriliyorsa bu öğe için gerekli JavaScript kodunu HTML'de satır içine almayı ve geri kalanını geç yüklemeyi düşünebilirsiniz.

İlk giriş etkinliğiyle ilişkilendirilmiş etkileşim türünü ve öğeyi almak için first-input girişinin target ve name özelliklerine başvurabilirsiniz:

new PerformanceObserver((list) => {
  const fidEntry = list.getEntries()[0];

  console.log('FID target element:', fidEntry.target);
  console.log('FID interaction type:', fidEntry.name);
}).observe({type: 'first-input', buffered: true});

INP

INP, alanda yakalanacak en yararlı bilgi parçalarının olması açısından FID'ye çok benzer:

1. Hangi öğeyle etkileşimde bulunuldu?
2. Görüşmenin türü neden
3. Bu etkileşimin ne zaman gerçekleştiği

FID gibi yavaş etkileşimlerin başlıca nedenlerinden biri, JavaScript yüklenirken sık karşılaşılan bir sorun olan ana iş parçacığının engellenmesidir. En yavaş etkileşimlerin sayfa yükleme sırasında meydana gelip gelmediğini bilmek, sorunu düzeltmek için ne yapılması gerektiğini belirlerken faydalıdır.

FID metriğinin aksine INP metriği, bir etkileşimin tam gecikmesini dikkate alır. Bu gecikme, kayıtlı etkinlik işleyicilerin çalıştırılması için gereken sürenin yanı sıra tüm etkinlik işleyicileri çalıştırıldıktan sonra bir sonraki kareyi boyamak için gereken süreyi de kapsar. Bu, INP için hangi hedef öğelerin yavaş etkileşimlere yol açma eğiliminde olduğunu ve bunların ne tür etkileşimler olduğunu bilmek daha da yararlıdır.

Hem INP hem de FID, Etkinlik Zamanlaması API'sini temel aldığından, JavaScript'te bu bilgileri belirleme yönteminiz bir önceki örneğe çok benzer. Aşağıdaki kod, INP girişinin hedef öğesini ve zamanını (DOMContentLoaded ile ilgili olarak) günlüğe kaydeder.

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);

  const navEntry = performance.getEntriesByType('navigation')[0];
  const wasINPBeforeDCL =
    inpEntry.startTime < navEntry.domContentLoadedEventStart;

  console.log('INP occurred before DCL:', wasINPBeforeDCL);
}

Daha karmaşık bir mantık gerektirdiği için bu kodun, hangi event girişinin INP girişi olduğunun nasıl belirleneceğini göstermediğini unutmayın. Ancak aşağıdaki bölümde web-vitals JavaScript kitaplığını kullanarak bu bilgileri nasıl edinebileceğiniz açıklanmaktadır.

Web Vitals JavaScript kitaplığıyla kullanım

Yukarıdaki bölümlerde, analiz aracınıza gönderdiğiniz verilere eklenecek hata ayıklama bilgilerini yakalayabileceğiniz bazı genel öneriler ve kod örnekleri sunulmaktadır.

Sürüm 3'ten itibaren web-vitals JavaScript kitaplığı, tüm bu bilgileri içeren 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ı olabilecek hata ayıklama dizesi içeren ek bir etkinlik parametresi (veya özel boyut) ayarlamanın yöntemi gösterilmektedir.

import {onCLS, onFID, 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 'FID':
    case 'INP':
      eventParams.debug_target = attribution.eventTarget;
      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 fikir diğer analiz araçlarına da aktarılmalıdır.

Bu kod yalnızca tek bir hata ayıklama sinyalinin nasıl raporlanacağını da gösterir. Ancak metrik başına birden fazla farklı sinyal toplayıp raporlayabilmek faydalı olabilir. Örneğin, INP'de hata ayıklamak için etkileşim türünü, zamanı ve ayrıca etkileşimde bulunulan öğeyi toplayabilirsiniz. web-vitals ilişkilendirme derlemesi, aşağıdaki örnekte gösterildiği gibi, tüm bu bilgileri ortaya çıkarır:

import {onCLS, onFID, 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.eventTarget;
      eventParams.debug_type = attribution.eventType;
      eventParams.debug_time = attribution.eventTime;
      eventParams.debug_load_state = attribution.loadState;
      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);

Gösterilen hata ayıklama sinyallerinin tam listesi için web hayati verileri ilişkilendirme belgelerine bakın.

Verileri raporlama ve görselleştirme

Metrik değerleriyle birlikte hata ayıklama bilgilerini toplamaya başladıktan sonra, kalıpları ve trendleri aramaya başlamak için verileri tüm kullanıcılarınız genelinde birleştirmek gerekir.

Yukarıda da belirtildiği gibi, kullanıcılarınızın karşılaştığı her sorunu tek tek ele almanız gerekmez. Özellikle başta en fazla sayıda kullanıcıyı etkileyen ve Core Web Vitals puanlarınızda en büyük olumsuz etkiye sahip olan sorunlar olmalıdır.

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

Özet

Bu yayının, sahadaki gerçek kullanıcı ziyaretlerine göre performansın teşhis edilmesine yardımcı olacak hata ayıklama bilgilerini almak için mevcut performans API'lerini ve web-vitals kitaplığını kullanabileceğiniz belirli yolları özetlediğini umarız. Bu kılavuz Önemli Web Verileri'ne odaklansa da, kavramlar JavaScript'te ölçülebilen tüm performans metriklerinde hata ayıklama için de geçerlidir.

Performansı ölçmeye yeni başladıysanız ve zaten bir Google Analytics kullanıcısıysanız Web Verileri Raporu aracı, Önemli Web Verileri metrikleri için hata ayıklama bilgilerinin raporlanmasını zaten desteklediğinden, iyi bir başlangıç noktası olabilir.

Analiz tedarikçisiyseniz ve ürünlerinizi iyileştirmek ve kullanıcılarınıza daha fazla hata ayıklama bilgisi sağlamak istiyorsanız burada açıklanan tekniklerden bazılarını kullanabilirsiniz ancak kendinizi yalnızca burada sunulan fikirlerle sınırlamayın. Bu yayının genel olarak tüm analiz araçları için geçerli olması amaçlanmıştır. Ancak, her analiz aracı büyük olasılıkla daha fazla hata ayıklama bilgisini yakalayıp raporlayabilir (ve bildirmelidir).

Son olarak, API'lerdeki eksik özellikler veya bilgiler nedeniyle bu metriklerde hata ayıklama becerinizde eksiklikler olduğunu düşünüyorsanız geri bildiriminizi web-vitals-feedback@googlegroups.com adresine gönderin.