Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Men-debug performa dalam kolom

Pelajari cara mengatribusikan data performa Anda dengan informasi proses debug untuk membantu Anda mengidentifikasi dan memperbaiki masalah pengguna sebenarnya dengan analisis

Philip Walton

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

Alat lab: Alat seperti Lighthouse, tempat halaman Anda dimuat dalam lingkungan simulasi yang dapat meniru berbagai kondisi (misalnya, jaringan lambat dan perangkat seluler kelas bawah).
Alat kolom: Alat seperti Chrome User Experience Report (CrUX), yang didasarkan pada data gabungan pengguna sebenarnya dari Chrome. (Perhatikan bahwa data lapangan 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 nyata—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 Anda kemungkinan tidak akan membantu Anda mengetahui cara meningkatkan performa Anda.

Sebaliknya, Lighthouse akan mengidentifikasi masalah dan memberikan saran spesifik tentang cara meningkatkannya. Namun, Lighthouse hanya akan memberikan saran untuk masalah performa yang ditemukannya saat waktu pemuatan halaman. Lighthouse tidak mendeteksi masalah yang hanya muncul sebagai akibat dari interaksi pengguna seperti men-scroll atau mengklik tombol di halaman.

Hal ini menimbulkan pertanyaan penting: bagaimana cara mendapatkan informasi proses debug untuk Core Web Vitals atau metrik performa lainnya dari pengguna sebenarnya di lapangan?

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

API untuk atribusi dan proses debug

Pergeseran Tata Letak Kumulatif (CLS)

Dari semua metrik Core Web Vitals, CLS mungkin merupakan metrik yang paling penting untuk mengumpulkan informasi proses debug di lapangan. CLS diukur selama masa aktif halaman, sehingga cara pengguna berinteraksi dengan halaman—seberapa jauh mereka men-scroll, apa yang mereka klik, dan sebagainya—dapat berdampak signifikan pada apakah ada perubahan 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 lapangan dan lab jika tersedia dan data ini mungkin berbeda

Nilai yang dilaporkan untuk CLS dari lab (Lighthouse) dibandingkan dengan CLS dari lapangan (data CrUX) cukup 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 Anda memahami bahwa interaksi pengguna memengaruhi data kolom, Anda tetap perlu mengetahui elemen apa di halaman yang bergeser sehingga menghasilkan skor 0,28 pada persentil ke-75. Antarmuka LayoutShiftAttribution memungkinkan hal tersebut.

Mendapatkan atribusi pergeseran tata letak

Antarmuka LayoutShiftAttribution diekspos pada setiap entri layout-shift yang dipancarkan oleh Layout Instability API.

Untuk 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 yang bergeser.

Berikut adalah contoh kode yang mencatat setiap pergeseran tata letak serta elemen yang bergeser:

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 pergeseran terburuk dan hanya melaporkan informasi tentang pergeseran tersebut.

Tujuannya bukan untuk mengidentifikasi dan memperbaiki setiap pergeseran tata letak yang terjadi untuk setiap pengguna; tujuannya adalah mengidentifikasi pergeseran yang memengaruhi jumlah pengguna terbesar dan dengan demikian memberikan kontribusi terbesar pada CLS halaman Anda pada persentil ke-75.

Selain itu, Anda tidak perlu menghitung elemen sumber terbesar setiap kali ada pergeseran, Anda hanya perlu melakukannya saat Anda siap mengirimkan nilai CLS ke alat analisis Anda.

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 berkontribusi pada CLS untuk halaman tertentu kemungkinan akan bervariasi dari pengguna ke pengguna, tetapi jika Anda menggabungkan elemen tersebut di semua pengguna, Anda akan dapat membuat daftar elemen yang bergeser dan memengaruhi sebagian besar pengguna.

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

Beberapa metadata lain yang mungkin berguna untuk direkam 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 butuhkan adalah elemen tertentu mana yang merupakan elemen terbesar (elemen kandidat LCP) untuk pemuatan halaman tertentu tersebut.

Perhatikan bahwa sangat mungkin—bahkan cukup umum—bahwa elemen kandidat LCP akan berbeda dari pengguna ke pengguna, 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 dan elemen yang berbeda yang terlihat dalam area tampilan.
Pengguna tidak selalu memuat halaman yang di-scroll ke bagian 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 pengguna ke pengguna.

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 sebenarnya.

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

Interaction to Next Paint (INP)

Informasi paling penting yang perlu direkam di kolom untuk INP adalah:

Elemen yang berinteraksi
Jenis interaksi yang terjadi
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 akan membantu menentukan tindakan yang perlu dilakukan untuk memperbaiki masalah.

Metrik INP mempertimbangkan latensi penuh suatu interaksi—termasuk waktu yang diperlukan untuk menjalankan semua pemroses peristiwa terdaftar serta waktu yang diperlukan untuk menggambar frame berikutnya setelah semua pemroses peristiwa dijalankan. Artinya, untuk INP, sangat berguna untuk mengetahui elemen target mana yang cenderung menghasilkan interaksi lambat, dan jenis interaksi apa yang terjadi.

Kode berikut mencatat elemen target dan waktu entri INP.

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 rumit. 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 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, serta 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);
onINP(sendToGoogleAnalytics);

Kode ini khusus untuk Google Analytics, tetapi ide umumnya juga dapat diterapkan pada alat analisis lainnya.

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

Misalnya, untuk men-debug INP, Anda mungkin ingin mengumpulkan elemen yang 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 ditampilkan.

Melaporkan dan memvisualisasikan data

Setelah Anda mulai mengumpulkan informasi proses debug bersama dengan nilai metrik, langkah selanjutnya adalah menggabungkan data di semua pengguna untuk mulai mencari pola dan tren.

Seperti yang disebutkan sebelumnya, Anda tidak perlu mengatasi setiap masalah yang dihadapi pengguna. Anda harus mengatasi—terutama pada awalnya—masalah yang memengaruhi jumlah pengguna terbanyak, 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 telah membantu menguraikan cara spesifik Anda dapat menggunakan API performa yang ada dan library web-vitals untuk mendapatkan informasi proses debug guna membantu mendiagnosis performa berdasarkan kunjungan pengguna sebenarnya di lapangan. Meskipun panduan ini berfokus pada Core Web Vitals, konsepnya juga berlaku untuk men-debug metrik performa apa pun yang dapat diukur di JavaScript.

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

Terakhir, jika Anda merasa ada kekurangan dalam kemampuan Anda untuk men-debug metrik ini karena fitur atau informasi yang tidak ada di API itu sendiri, kirimkan masukan Anda ke web-vitals-feedback@googlegroups.com.