Halaman ini diterjemahkan oleh Cloud Translation API.

Men-debug performa dalam kolom

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

Philip Walton

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

Alat lab: Alat seperti Lighthouse, tempat halaman Anda dimuat di lingkungan yang disimulasikan yang dapat meniru berbagai kondisi (misalnya, laman jaringan dan perangkat seluler kelas bawah).
Alat kolom: Alat seperti Pengalaman Pengguna Chrome Laporkan (CrUX), yang didasarkan pada data gabungan pengguna nyata dari Chrome. (Perhatikan bahwa data lapangan yang dilaporkan oleh alat seperti PageSpeed Insight dan Penelusuran Konsol berasal dari data CrUX.)

Sementara alat lapangan menawarkan data yang lebih akurat—data yang sebenarnya mewakili apa pengalaman pengguna yang nyata—alat lab sering kali lebih baik dalam membantu Anda mengidentifikasi dan masalah performa.

Data CrUX lebih mewakili performa nyata halaman Anda, tetapi skor CrUX Anda cenderung tidak membantu Anda mengetahui cara meningkatkan tingkat tinggi.

Di sisi lain, Lighthouse akan mengidentifikasi masalah dan membuat saran untuk meningkatkannya. Namun, Lighthouse hanya akan memberikan saran untuk masalah performa yang ditemukannya pada waktu pemuatan halaman. Tidak mendeteksi masalah yang hanya muncul sebagai hasil interaksi pengguna seperti menggulir atau mengklik tombol pada laman.

Hal ini menimbulkan pertanyaan penting: bagaimana Anda bisa menangkap 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 untuk setiap metrik Core Web Vitals saat ini dan memberikan 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, mungkin CLS adalah satu mengumpulkan informasi debug di lapangan adalah yang paling penting. CLS diukur sepanjang masa aktif halaman, sehingga cara pengguna berinteraksi dengan halaman—seberapa jauh mereka men-scroll, apa yang diklik, dan sebagainya—dapat memiliki pengaruh pada apakah ada pergeseran tata letak dan elemen mana yang bergeser.

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 (data CrUX) sangat berbeda, dan ini masuk akal jika Anda bahwa laman itu mungkin memiliki banyak konten interaktif yang tidak digunakan saat diuji di Lighthouse.

Tetapi bahkan jika Anda memahami bahwa interaksi pengguna mempengaruhi data lapangan, Anda masih perlu mengetahui elemen apa pada halaman yang bergeser untuk menghasilkan skor 0,28 pada persentil ke-75. LayoutShiftAttribution memungkinkan hal itu.

Mendapatkan atribusi pergeseran tata letak

LayoutShiftAttribution ditampilkan di setiap entri layout-shift yang menampilkan Layout Instability (Ketidakstabilan Tata Letak) API yang dimunculkan.

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

Berikut ini beberapa kode contoh yang mencatat setiap pergeseran tata letak serta elemen-elemennya yang telah 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 mengukur dan mengirim data ke alat analisis untuk setiap pergeseran tata letak yang terjadi; Namun, dengan memantau semua shift, Anda dapat melacak perubahan terburuk dan melaporkan informasi tentang perubahan tersebut.

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

Juga, Anda tidak perlu menghitung elemen sumber terbesar setiap kali ada Anda hanya perlu melakukannya setelah siap mengirim nilai CLS ke alat analisis.

Kode berikut mengambil daftar layout-shift entri yang telah berkontribusi ke 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 Anda mengidentifikasi elemen terbesar yang berkontribusi pada perubahan terbesar, Anda dapat melaporkannya ke alat analisis Anda.

Elemen yang paling banyak berkontribusi pada CLS untuk halaman tertentu kemungkinan akan bervariasi dari antarpengguna, tetapi jika Anda menggabungkan elemen-elemen itu pada semua pengguna, Anda mampu menghasilkan daftar elemen pergeseran yang mempengaruhi sebagian besar pengguna.

Setelah Anda mengidentifikasi dan memperbaiki akar penyebab perubahan pada 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 kriteria baik" batas 0,1!

Beberapa {i>metadata<i} lain yang mungkin berguna untuk ditangkap bersama dengan pergeseran terbesar elemen sumber 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 butuhkan adalah adalah elemen terbesar (elemen kandidat LCP) untuk pemuatan halaman.

Perhatikan bahwa sangat mungkin—pada kenyataannya, cukup umum—bahwa LCP akan berbeda dari satu pengguna ke pengguna lainnya, bahkan untuk kami.

Hal ini dapat terjadi karena beberapa alasan:

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

Artinya Anda tidak dapat membuat asumsi tentang elemen atau kumpulan elemen mana akan menjadi elemen kandidat LCP yang 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 opsi Contentful Paint 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 beserta nilai metriknya. Seperti halnya CLS, ini akan membantu Anda mengidentifikasi yang paling penting untuk dioptimalkan terlebih dahulu.

Selain elemen kandidat LCP, mungkin juga berguna untuk mengukur Waktu sub-bagian LCP, yang dapat bermanfaat dalam menentukan langkah-langkah pengoptimalan spesifik yang relevan untuk situs Anda.

Interaksi dengan Next Paint (INP)

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

Elemen apa yang berinteraksi dengan
Mengapa jenis interaksi itu
Kapan interaksi tersebut terjadi

Penyebab utama interaksi yang lambat adalah thread utama yang diblokir, yang dapat umum saat JavaScript dimuat. Mengetahui apakah interaksi yang paling lambat terjadi selama pemuatan halaman sangat membantu dalam menentukan apa yang harus dilakukan untuk memperbaiki menyelesaikan masalah.

Metrik INP mempertimbangkan latensi penuh dari termasuk waktu yang diperlukan untuk menjalankan pemroses peristiwa terdaftar serta waktu yang diperlukan untuk menggambar frame berikutnya setelah semua pemroses peristiwa sudah berjalan. Artinya bagi INP, sangat berguna untuk mengetahui target yang cenderung mengakibatkan interaksi lambat, dan jenis interaksi apa itu.

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 INP entri data, karena logika tersebut lebih terlibat. Namun, bagian berikut menjelaskan cara mendapatkan informasi ini dengan library JavaScript web-vitals.

Penggunaan dengan library JavaScript web-vitals

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

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

Contoh kode berikut menunjukkan cara menetapkan peristiwa tambahan parameter (atau custom dimensi) yang berisi string debug berguna untuk membantu mengidentifikasi akar masalah performa 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 gagasan umumnya harus diterjemahkan ke alat analisis lainnya.

Kode ini juga hanya menunjukkan cara melaporkan satu sinyal debug, tetapi berguna untuk dapat mengumpulkan dan melaporkan berbagai sinyal yang berbeda sesuai metrik.

Misalnya, untuk men-debug INP, Anda mungkin ingin mengumpulkan elemen berinteraksi, jenis interaksi, waktu, loadState, 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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

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

Melaporkan dan memvisualisasikan data

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

Seperti yang disebutkan sebelumnya, Anda tidak perlu selalu mengatasi setiap masalah ditemui pengguna, Anda ingin 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 membantu menjelaskan cara spesifik Anda dapat menggunakan API performa yang ada dan library web-vitals untuk mendapatkan informasi debug untuk membantu mendiagnosis performa berdasarkan kunjungan pengguna nyata di lapangan. Meskipun ini berfokus pada Core Web Vitals, konsepnya juga berlaku untuk proses debug metrik performa apa pun yang dapat diukur di JavaScript.

Jika Anda baru mulai mengukur performa, dan telah pengguna Google Analytics, alat Laporan Data Web mungkin merupakan tempat yang tepat untuk memulai karena sudah mendukung pelaporan informasi debug untuk Web Inti Metrik Android vitals.

Jika Anda adalah vendor analitik dan Anda ingin meningkatkan produk dan memberikan lebih banyak informasi {i>debugging<i} kepada pengguna, pertimbangkan beberapa teknik yang dijelaskan di sini tetapi jangan membatasi diri Anda hanya pada ide-ide yang disajikan di sini. Postingan ini dimaksudkan untuk dapat diterapkan secara umum pada semua alat analisis; Namun, masing-masing alat analisis kemungkinan dapat (dan harus) menangkap dan melaporkan lebih banyak informasi debug.

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