Men-debug performa dalam kolom

Pelajari cara mengatribusikan data performa dengan informasi debug untuk membantu mengidentifikasi dan memperbaiki masalah pengguna nyata terkait

Philip Walton

Google menyediakan dua kategori alat untuk mengukur dan men-debug performa:

• Alat lab: Alat seperti Lighthouse, tempat halaman Anda dimuat di lingkungan simulasi yang dapat meniru berbagai kondisi (misalnya, jaringan lambat dan perangkat seluler kelas bawah).
• Alat kolom: Alat seperti Laporan Pengalaman Pengguna Chrome (CrUX), yang didasarkan pada data gabungan pengguna nyata dari Chrome. (Perhatikan bahwa data kolom yang dilaporkan oleh alat seperti PageSpeed Insights dan Search Console berasal dari data CrUX.)

Meskipun alat lapangan menawarkan data yang lebih akurat—data yang benar-benar mewakili pengalaman pengguna sebenarnya—alat lab sering kali lebih baik dalam membantu Anda mengidentifikasi dan memperbaiki masalah.

Data CrUX lebih mewakili performa sebenarnya halaman Anda, tetapi mengetahui skor CrUX tidak akan membantu Anda mengetahui cara meningkatkan performa.

Di sisi lain, Lighthouse akan mengidentifikasi masalah dan memberikan sugesti khusus tentang cara meningkatkan kualitas. Namun, Lighthouse hanya akan memberikan saran untuk masalah performa yang ditemukan pada waktu pemuatan halaman. Fitur ini tidak mendeteksi masalah yang hanya terlihat sebagai hasil dari interaksi pengguna seperti men-scroll atau mengklik tombol pada halaman.

Hal ini menimbulkan pertanyaan penting: bagaimana cara Anda mengambil informasi debug untuk Core Web Vitals atau metrik performa lainnya dari pengguna sungguhan di lapangan?

Postingan ini akan menjelaskan secara mendetail API yang dapat Anda gunakan untuk mengumpulkan informasi proses debug tambahan untuk setiap metrik Core Web Vitals saat ini dan memberi Anda ide tentang cara mengambil data ini di alat analisis yang sudah ada.

API untuk atribusi dan proses debug

Pergeseran Tata Letak Kumulatif (CLS)

Dari semua metrik Data Web Inti, CLS mungkin adalah metrik yang paling penting untuk mengumpulkan informasi debug di lapangan. CLS diukur sepanjang masa aktif halaman, sehingga cara pengguna berinteraksi dengan halaman—seberapa jauh mereka men-scroll, apa yang diklik, dan sebagainya—dapat memiliki dampak yang signifikan terhadap apakah ada pergeseran tata letak dan elemen mana yang berubah.

Pertimbangkan laporan berikut dari PageSpeed Insights:

PageSpeed Insights menampilkan data lapangan dan lab jika tersedia, dan data tersebut mungkin berbeda

Nilai yang dilaporkan untuk CLS dari lab (Lighthouse) dibandingkan dengan CLS dari kolom (data CrUX) sangat berbeda, dan hal ini masuk akal jika Anda mempertimbangkan bahwa halaman mungkin memiliki banyak konten interaktif yang tidak digunakan saat diuji di Lighthouse.

Namun, meskipun memahami bahwa interaksi pengguna memengaruhi data kolom, Anda tetap harus mengetahui elemen apa pada halaman yang berubah untuk menghasilkan skor 0,28 pada persentil ke-75. Antarmuka LayoutShiftAttribution memungkinkan hal tersebut.

Mendapatkan atribusi pergeseran tata letak

Antarmuka LayoutShiftAttribution ditampilkan di setiap entri layout-shift yang dikeluarkan oleh Layout Instability API.

Untuk penjelasan mendetail tentang kedua antarmuka ini, lihat Perubahan tata letak debug. Untuk tujuan postingan ini, hal utama yang perlu Anda ketahui adalah, sebagai developer, Anda dapat mengamati setiap pergeseran tata letak yang terjadi di halaman serta elemen yang bergeser.

Berikut ini beberapa kode contoh yang mencatat setiap pergeseran tata letak serta elemen yang bergeser ke dalam log:

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

Mungkin tidak praktis untuk mengukur dan mengirim data ke alat analisis untuk setiap pergeseran tata letak yang terjadi. Namun, dengan memantau semua pergeseran, Anda dapat melacak pergeseran terburuk dan hanya melaporkan informasi tentang pergeseran tersebut.

Sasarannya bukan untuk mengidentifikasi dan memperbaiki setiap pergeseran tata letak yang terjadi bagi setiap pengguna; tujuannya adalah mengidentifikasi pergeseran yang memengaruhi jumlah pengguna terbesar sehingga paling banyak berkontribusi pada CLS halaman Anda di persentil ke-75.

Selain itu, Anda tidak perlu menghitung elemen sumber terbesar setiap kali terjadi perubahan, Anda hanya perlu melakukannya jika sudah siap untuk mengirimkan nilai CLS ke alat analisis.

Kode berikut mengambil daftar entri layout-shift yang telah berkontribusi pada CLS dan menampilkan elemen sumber terbesar dari pergeseran terbesar:

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

Setelah mengidentifikasi elemen terbesar yang berkontribusi pada pergeseran terbesar, Anda dapat melaporkannya ke alat analisis.

Elemen yang paling banyak berkontribusi pada CLS untuk halaman tertentu mungkin akan bervariasi dari pengguna ke pengguna, tetapi jika menggabungkan elemen tersebut di semua pengguna, Anda akan dapat membuat daftar elemen pergeseran yang memengaruhi sebagian besar pengguna.

Setelah Anda mengidentifikasi dan memperbaiki akar penyebab pergeseran untuk elemen tersebut, kode analisis akan mulai melaporkan pergeseran yang lebih kecil sebagai pergeseran "terburuk" untuk halaman Anda. Pada akhirnya, semua perubahan yang dilaporkan akan cukup kecil sehingga halaman Anda berada dalam nilai minimum "baik" 0,1.

Beberapa metadata lain yang mungkin berguna untuk diambil bersama dengan elemen sumber pergeseran terbesar adalah:

• Waktu perubahan terbesar
• Jalur URL pada saat pergeseran terbesar (untuk situs yang memperbarui URL secara dinamis, seperti Aplikasi Web Satu Halaman).

Largest Contentful Paint (LCP)

Untuk men-debug LCP di lapangan, informasi utama yang Anda perlukan adalah elemen tertentu yang merupakan elemen terbesar (elemen kandidat LCP) untuk pemuatan halaman tertentu tersebut.

Perhatikan bahwa sangat mungkin—pada kenyataannya, sangat umum—elemen kandidat LCP akan berbeda dari satu pengguna ke pengguna lainnya, bahkan untuk halaman yang sama persis.

Hal ini dapat terjadi karena beberapa alasan:

• Perangkat pengguna memiliki resolusi layar yang berbeda, sehingga menghasilkan tata letak halaman yang berbeda sehingga elemen yang berbeda terlihat dalam area tampilan.
• Pengguna tidak selalu memuat halaman yang di-scroll ke paling atas. Sering kali link akan berisi ID fragmen atau bahkan fragmen teks, yang berarti halaman Anda dapat dimuat dan ditampilkan di posisi scroll mana pun di halaman.
• Konten dapat dipersonalisasi untuk pengguna saat ini, sehingga elemen kandidat LCP dapat sangat bervariasi dari satu pengguna ke pengguna lainnya.

Artinya, Anda tidak dapat membuat asumsi tentang elemen atau kumpulan elemen mana yang akan menjadi elemen kandidat LCP paling umum untuk halaman tertentu. Anda harus mengukurnya berdasarkan perilaku pengguna nyata.

Catatan: Untuk mengetahui detail selengkapnya tentang perbedaan ini, lihat: Alasan data lab dan lapangan dapat berbeda (dan cara mengatasinya)

Mengidentifikasi elemen kandidat LCP

Untuk menentukan elemen kandidat LCP di JavaScript, Anda dapat menggunakan Largest Contentful Paint API, yaitu API yang sama dengan yang Anda gunakan untuk menentukan nilai waktu LCP.

Saat mengamati entri largest-contentful-paint, Anda dapat menentukan elemen kandidat LCP saat ini dengan melihat properti element dari entri terakhir:

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

Perhatian: Seperti yang dijelaskan dalam dokumentasi metrik LCP, elemen kandidat LCP dapat berubah selama pemuatan halaman, sehingga diperlukan lebih banyak pekerjaan untuk mengidentifikasi elemen kandidat LCP "akhir". Cara termudah untuk mengidentifikasi dan mengukur elemen kandidat LCP "final" adalah dengan menggunakan library JavaScript web-vitals, seperti yang ditunjukkan dalam contoh.

Setelah mengetahui elemen kandidat LCP, Anda dapat mengirimkannya ke alat analisis bersama dengan nilai metrik. Seperti CLS, hal ini akan membantu Anda mengidentifikasi elemen mana yang paling penting untuk dioptimalkan terlebih dahulu.

Selain elemen kandidat LCP, sebaiknya ukur juga waktu sub-bagian LCP, yang dapat berguna dalam menentukan langkah pengoptimalan spesifik yang relevan untuk situs Anda.

Interaksi dengan Next Paint (INP)

Tips: Lihat artikel khusus Menemukan interaksi lambat di kolom untuk informasi selengkapnya tentang cara men-debug INP dengan data kolom.

Informasi yang paling penting untuk diambil di lapangan untuk INP adalah:

1. Elemen yang berinteraksi
2. Jenis interaksi yang dilakukan
3. Kapan interaksi tersebut terjadi

Penyebab utama interaksi yang lambat adalah thread utama yang diblokir, yang dapat terjadi saat JavaScript sedang dimuat. Mengetahui apakah sebagian besar interaksi lambat terjadi selama pemuatan halaman dapat membantu dalam menentukan hal yang perlu dilakukan untuk memperbaiki masalah tersebut.

Metrik INP mempertimbangkan latensi penuh interaksi—termasuk waktu yang diperlukan untuk menjalankan pemroses peristiwa terdaftar serta waktu yang diperlukan untuk merender frame berikutnya setelah semua pemroses peristiwa berjalan. Artinya, bagi INP, sangat berguna untuk mengetahui elemen target mana yang cenderung menghasilkan interaksi lambat, dan jenis interaksi tersebut.

Kode berikut mencatat elemen target dan waktu entri INP ke dalam log.

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

Perhatikan bahwa kode ini tidak menunjukkan cara menentukan entri event mana yang merupakan entri INP karena logika tersebut lebih terlibat. Namun, bagian berikut menjelaskan cara mendapatkan informasi ini menggunakan library JavaScript web-vitals.

Penggunaan dengan library JavaScript web-vitals

Bagian sebelumnya menawarkan beberapa saran umum dan contoh kode untuk mengambil info debug yang akan disertakan dalam data yang Anda kirim ke alat analisis.

Sejak versi 3, library JavaScript web-vitals menyertakan build atribusi yang menampilkan semua informasi ini, dan juga beberapa sinyal tambahan.

Contoh kode berikut menunjukkan cara menetapkan parameter peristiwa tambahan (atau dimensi kustom) yang berisi string debug yang berguna untuk membantu mengidentifikasi akar masalah performa.

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

Kode ini khusus untuk Google Analytics, tetapi ide umumnya juga harus diterjemahkan ke alat analisis lainnya.

Kode ini juga hanya menunjukkan cara melaporkan satu sinyal debug, tetapi akan berguna untuk mengumpulkan dan melaporkan beberapa sinyal yang berbeda per metrik.

Misalnya, untuk men-debug INP, Anda mungkin ingin mengumpulkan elemen yang sedang berinteraksi, jenis interaksi, waktu, loadState, fase interaksi, dan lainnya (seperti data Frame Animasi Panjang).

Build atribusi web-vitals mengekspos informasi atribusi tambahan, seperti yang ditunjukkan dalam contoh berikut untuk INP:

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

Lihat dokumentasi atribusi web-vitals untuk mengetahui daftar lengkap sinyal debug yang terekspos.

Melaporkan dan memvisualisasikan data

Setelah Anda mulai mengumpulkan informasi debug beserta nilai metrik, langkah berikutnya adalah menggabungkan data di semua pengguna untuk mulai mencari pola dan tren.

Seperti yang disebutkan sebelumnya, Anda tidak perlu mengatasi setiap masalah yang dialami pengguna. Anda ingin mengatasi—terutama pada awalnya—masalah yang memengaruhi jumlah pengguna terbesar, yang juga harus menjadi masalah yang memiliki dampak negatif terbesar pada skor Core Web Vitals Anda.

Untuk GA4, lihat artikel khusus tentang cara membuat kueri dan memvisualisasikan data menggunakan BigQuery.

Ringkasan

Semoga postingan ini dapat membantu menguraikan cara spesifik Anda dapat menggunakan API performa yang ada dan library web-vitals untuk mendapatkan informasi debug guna membantu mendiagnosis performa berdasarkan kunjungan pengguna yang sebenarnya di lapangan. Meskipun panduan ini berfokus pada Core Web Vitals, konsepnya juga berlaku untuk men-debug metrik performa apa pun yang dapat diukur dalam JavaScript.

Jika Anda baru mulai mengukur performa, dan sudah menjadi pengguna Google Analytics, alat Laporan Web Vitals dapat menjadi tempat yang tepat untuk memulai karena sudah mendukung pelaporan informasi debug untuk metrik Core Web Vitals.

Jika Anda adalah vendor analisis dan ingin meningkatkan kualitas produk serta memberikan lebih banyak informasi proses debug kepada pengguna, pertimbangkan beberapa teknik yang dijelaskan di sini, tetapi jangan membatasi diri Anda hanya pada ide yang disampaikan di sini. Postingan ini dimaksudkan agar dapat diterapkan secara umum pada semua alat analisis; tetapi setiap alat analisis kemungkinan dapat (dan seharusnya) mengambil dan melaporkan lebih banyak informasi debug.

Terakhir, jika Anda merasa ada kekurangan dalam kemampuan Anda untuk men-debug metrik ini karena hilangnya fitur atau informasi di API itu sendiri, kirim masukan Anda ke [e-mail].