Mengidentifikasi penyebab INP yang buruk

Fitur web: Entri performa frame animasi panjang Entri performa pengaturan waktu peristiwa

Responsivitas yang buruk terhadap interaksi akan memberikan kesan buruk bahwa halaman lambat atau bahkan rusak sepenuhnya. Interaction to Next Paint (INP) adalah metrik yang didasarkan pada Event Timing API. Metrik ini mengukur interaksi terburuk (minus beberapa pencilan) sebagai ukuran responsivitas halaman.

Mengidentifikasi penyebab utama halaman web yang tidak responsif bisa jadi sulit, terutama karena hal ini bergantung pada interaksi pengguna dan kondisi lingkungan seperti kemampuan perangkat dan kondisi jaringan. Hal ini membuatnya lebih sulit untuk didiagnosis dibandingkan dengan skenario yang lebih dapat diulang dan diprediksi seperti pemuatan halaman. Data lab hanya mereplikasi sebagian kecil skenario pengguna sungguhan, sehingga mengukur penyebab INP yang lambat di lapangan sangatlah penting.

Event Timing API memungkinkan pembagian durasi INP menjadi tiga subbagian: Penundaan Input (pemrosesan yang sudah terjadi saat interaksi terjadi), Durasi Pemrosesan (penundaan yang terjadi sebagai akibat langsung dari interaksi), dan Penundaan Presentasi (penundaan yang terjadi karena rendering frame berikutnya setelah interaksi). Hal ini membantu mengidentifikasi apakah masalahnya ada pada kode lain, kode JavaScript interaksi, atau update rendering pemrosesan browser, bukan langsung beralih ke kode interaksi.

Anda dapat mengumpulkan insight lebih lanjut tentang JavaScript, penghitungan ulang gaya, dan pekerjaan tata letak yang menunda interaksi. Trace performa lengkap menggunakan JS Self-Profiling API adalah solusi berat yang dapat menyebabkan masalah performa. Long Animation Frames API adalah API ringan yang dapat digunakan di lapangan untuk mengidentifikasi JavaScript yang berjalan lambat dan membedakan antara penghitungan ulang gaya dan biaya tata letak selama interaksi INP:

  • Gaya dan tata letak paksa tingkat skrip (forcedStyleDuration dan forcedLayoutDuration): Melaporkan penghitungan ulang gaya sinkron (seperti memanggil getComputedStyle() setelah mutasi DOM) dan tata letak/penataan ulang paksa (seperti membaca getBoundingClientRect() atau offsetWidth setelah mutasi) di dalam skrip yang berjalan selama Penundaan Input atau Durasi Pemrosesan.
  • Gaya dan tata letak rendering tingkat frame (styleDuration dan layoutDuration): Melaporkan waktu yang dihabiskan untuk menghitung ulang gaya versus memperbarui tata letak selama update rendering frame, sehingga membantu menjelaskan Penundaan Presentasi yang tinggi.

Membedakan penghitungan ulang gaya dari tata letak sangat penting karena keduanya memiliki akar masalah dan perbaikan yang berbeda: durasi gaya yang tinggi menunjukkan pencocokan pemilih CSS yang mahal atau pembatalan gaya yang luas (diperbaiki dengan menyederhanakan pemilih atau mengurangi cakupan aturan), sedangkan durasi tata letak yang tinggi menunjukkan penghitungan geometri yang mahal atau thrashing tata letak sinkron (diperbaiki dengan mengelompokkan pembacaan DOM sebelum penulisan, menyederhanakan struktur DOM, atau menggunakan penampungan CSS).

Cara menerapkan

Menghitung INP dari Event Timing API mentah itu rumit dan memiliki beberapa nuansa. Sebaiknya gunakan alat atau library RUM untuk mengumpulkan data ini.

web-vitals adalah library open source dari Google yang menghitung Core Web Vitals termasuk INP, dan juga menyertakan subbagian dan data frame animasi panjang untuk interaksi INP.

Mendapatkan atribusi untuk interaksi INP menggunakan library web-vitals

Library web-vitals adalah library kecil yang digunakan untuk mengukur Core Web Vitals dan metrik performa lainnya. Fungsi onINP() dapat digunakan untuk mengidentifikasi interaksi paling lambat dan menyertakan informasi tentang subbagian INP, skrip yang dieksekusi selama interaksi, serta durasi gaya dan tata letak menggunakan Long Animation Frames API.

// Use the attribution build to get Long Animation Frame data
// alongside the INP metric value.
import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const { attribution } = metric;
  const longestScript = attribution.longestScript;

  // Sum rendering-phase style and layout durations across all LoAF entries
  // intersecting the INP interaction (primarily explains presentationDelay).
  let renderStyleDuration = 0;
  let renderLayoutDuration = 0;
  for (const entry of attribution.longAnimationFrameEntries) {
    renderStyleDuration += entry.styleDuration ?? 0;
    renderLayoutDuration += entry.layoutDuration ?? 0;
  }

  // Beacon script, style, and layout attribution for the INP interaction,
  // so you can identify the root cause in production.
  navigator.sendBeacon(
    '/analytics',
    JSON.stringify({
      name: 'INP',
      value: metric.value,
      // These fields give the INP subparts:
      inputDelay: attribution.inputDelay,
      presentationDelay: attribution.presentationDelay,
      processingDuration: attribution.processingDuration,
      interactionTarget: attribution.interactionTarget,
      // These fields identify which script function was responsible
      // for the longest processing during the INP interaction.
      invokerType: longestScript?.entry?.invokerType,
      sourceURL: longestScript?.entry?.sourceURL,
      sourceFunctionName: longestScript?.entry?.sourceFunctionName,
      sourceCharPosition: longestScript?.entry?.sourceCharPosition,
      // subpart indicates which phase (input delay, processing, or
      // presentation delay) the longest script overlapped with most.
      subpart: longestScript?.subpart,
      intersectingDuration: longestScript?.intersectingDuration,
      // Synchronous style and layout work forced inside the longest script
      // (with forcedStyleAndLayoutDuration as a combined fallback):
      forcedStyleDuration: longestScript?.entry?.forcedStyleDuration,
      forcedLayoutDuration: longestScript?.entry?.forcedLayoutDuration,
      forcedStyleAndLayoutDuration: longestScript?.entry?.forcedStyleAndLayoutDuration,
      // Rendering-phase style and layout work across the interaction's frames
      // (with totalStyleAndLayoutDuration as a combined fallback):
      renderStyleDuration,
      renderLayoutDuration,
      totalStyleAndLayoutDuration: attribution.totalStyleAndLayoutDuration
    })
  );
});

Praktik Terbaik

  • LAKUKAN penggunaan subbagian INP di awal untuk mengidentifikasi apakah penundaan sudah menjalankan JavaScript (penundaan input), JavaScript pengendali peristiwa untuk interaksi (durasi pemrosesan), atau rendering berikutnya (penundaan presentasi).
  • LAKUKAN upaya untuk mengidentifikasi JavaScript pemblokir terbesar sebagai detail tambahan, terutama untuk penundaan input, dan durasi pemrosesan.
  • LAKUKAN pembedaan antara penghitungan ulang gaya (styleDuration, forcedStyleDuration) dan tata letak (layoutDuration, forcedLayoutDuration) saat mendiagnosis durasi pemrosesan yang tinggi atau penundaan presentasi: waktu gaya yang tinggi menunjukkan pemilih CSS yang mahal atau pembatalan yang luas, sedangkan waktu tata letak yang tinggi menunjukkan bottleneck geometri DOM atau thrashing tata letak sinkron.
  • LAKUKAN: Pilih Long Animation Frames API untuk memberikan detail lebih lanjut ini daripada alternatif seperti JS Self-Profiling API, yang memiliki overhead runtime lebih tinggi.
  • GUNAKAN library web-vitals jika tidak ada solusi RUM lain yang diterapkan. Alat ini dapat mengidentifikasi interaksi INP dan menyertakan informasi tentang subbagian dan skrip yang dieksekusi selama interaksi (menggunakan Long Animation Frames API).
  • LAKUKAN pengiriman kembali informasi yang diperlukan ke layanan analisis, bukan hanya mencatatnya secara lokal.

Dukungan browser dan strategi penggantian

Event Timing API tersedia di sebagian besar browser modern dan diperlukan untuk menghitung INP dan subbagian INP. Untuk browser yang tidak mendukung API ini, INP tidak dapat diukur.

Long Animation Frames API memberikan detail tambahan opsional. Fitur ini dapat digunakan dengan aman tanpa penggantian. Biasanya, peluang performa yang diidentifikasi juga akan berlaku untuk browser lain.

Jika target Dasar Pengukuran Anda mendukung Long Animation Frames API (long-animation-frames), tetapi tidak mendukung properti durasi gaya dan tata letak terpisah (styleDuration dan layoutDuration di PerformanceLongAnimationFrameTiming, atau forcedStyleDuration dan forcedLayoutDuration di PerformanceScriptTiming), gunakan kembali pengaturan waktu gaya dan tata letak gabungan:

  • Gunakan script.forcedStyleAndLayoutDuration di PerformanceScriptTiming untuk gaya paksa sinkron dan pekerjaan tata letak di dalam skrip.
  • Gunakan metric.attribution.totalStyleAndLayoutDuration di web-vitals/attribution (atau komputasi (entry.paintTime || entry.startTime + entry.duration) - entry.styleAndLayoutStart pada setiap entri PerformanceLongAnimationFrameTiming) untuk pekerjaan gaya dan tata letak gabungan.