Men-debug performa dalam kolom

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

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, yaitu data yang benar-benar mewakili pengalaman pengguna nyata, alat lab sering kali lebih baik dalam membantu Anda mengidentifikasi dan memperbaiki masalah.

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

Di sisi lain, Lighthouse akan mengidentifikasi masalah dan memberikan saran spesifik untuk meningkatkan kualitas. Namun, Lighthouse hanya akan memberikan saran untuk masalah performa yang ditemukannya 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 mengambil informasi debug untuk Data Web Inti 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 Core Web Vitals, CLS mungkin adalah metrik yang paling penting untuk mengumpulkan informasi debug di kolom. CLS diukur sepanjang masa aktif halaman, sehingga cara pengguna berinteraksi dengan halaman—seberapa jauh mereka men-scroll, apa yang diklik, dan sebagainya—dapat berdampak signifikan terhadap apakah ada pergeseran tata letak dan elemen mana yang berubah.

Pertimbangkan laporan berikut dari PageSpeed Insights:

Laporan PageSpeed Insights dengan nilai CLS yang berbeda
PageSpeed Insights menampilkan data kolom dan lab jika tersedia, dan data ini dapat 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 pada setiap entri layout-shift yang dikeluarkan oleh Layout Instability API.

Untuk mengetahui penjelasan mendetail tentang kedua antarmuka ini, lihat Men-debug pergeseran tata letak. Untuk tujuan postingan ini, hal utama yang perlu Anda ketahui adalah bahwa, sebagai developer, Anda dapat mengamati setiap pergeseran tata letak yang terjadi di halaman serta elemen apa saja yang berubah.

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 Anda untuk setiap pergeseran tata letak yang terjadi. Namun, dengan memantau semua pergeseran, Anda dapat melacak perubahan terburuk dan hanya melaporkan informasi tentang perubahan 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 perubahan 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 penyebab utama pergeseran elemen-elemen tersebut, kode analisis Anda akan mulai melaporkan perubahan yang lebih kecil sebagai perubahan "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 secara dinamis memperbarui URL, seperti Aplikasi Web Satu Halaman).

Largest Contentful Paint (LCP)

Untuk men-debug LCP di kolom, informasi utama yang Anda perlukan adalah elemen mana 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 pada 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.

Mengidentifikasi elemen kandidat LCP

Untuk menentukan elemen kandidat LCP di JavaScript, Anda dapat menggunakan Largest Contentful Paint API, 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});

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, ada baiknya juga mengukur waktu sub-bagian LCP, yang dapat berguna dalam menentukan langkah-langkah pengoptimalan spesifik apa yang relevan untuk situs Anda.

Interaksi dengan Next Paint (INP)

Bit informasi terpenting yang perlu ditangkap di lapangan untuk INP adalah:

  1. Elemen apa yang berinteraksi dengan
  2. Mengapa jenis interaksi itu
  3. Kapan interaksi tersebut terjadi

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

Metrik INP mempertimbangkan latensi penuh dari sebuah interaksi, termasuk waktu yang diperlukan untuk menjalankan pemroses peristiwa yang terdaftar serta waktu yang diperlukan untuk menggambar 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 dan contoh kode umum untuk merekam 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 penyebab utama 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);
onFID(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 ditunjukkan dalam contoh INP berikut:

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

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 selanjutnya adalah menggabungkan data dari semua pengguna untuk mulai mencari pola dan tren.

Seperti yang disebutkan sebelumnya, Anda tidak perlu mengatasi setiap masalah yang dihadapi pengguna, Anda perlu mengatasi—terutama pada awalnya—masalah yang memengaruhi sejumlah besar pengguna, yang seharusnya juga 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 Data Web 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 hanya ide yang disajikan 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 merasa ada kesenjangan dalam kemampuan Anda untuk men-debug metrik ini karena tidak adanya fitur atau informasi dalam API, kirimkan masukan Anda ke web-vitals-feedback@googlegroups.com.