Bagaimana Cara Membangun Pemantauan Pengguna Riil yang Andal dengan PerformanceObserver?

1. Pertanyaan

Aplikasi satu halaman yang diakses secara global memerlukan data performa pengguna riil untuk membandingkan pengalaman di berbagai perangkat, jaringan, dan rilis. Kumpulkan data LCP, pemuatan resource, dan long-task sambil membatasi laporan per sesi halaman. Rancang pengumpul PerformanceObserver dan jelaskan cara pengumpul tersebut menangani entri yang dibuat sebelum pendaftaran observer, kehilangan buffer, resource cross-origin, dan perubahan rute SPA.

2. Batasan dan klarifikasi

• Tentukan cakupan waktu setiap metrik: dokumen awal, navigasi halus (soft navigation), atau seluruh sesi.
• Tetapkan tingkat pengambilan sampel (sampling rate), batas entri per jenis, ukuran batch, dan kebijakan percobaan ulang saat gagal agar pengumpulan tidak memengaruhi halaman.
• Bedakan perbedaan dukungan browser dari data yang hilang; nilai yang hilang harus memiliki alasan dan tidak boleh diubah menjadi nol.
• Tentukan batasan privasi untuk URL resource, pengenal pengguna, dan dimensi kueri; jangan laporkan URL lengkap atau parameter sensitif secara langsung.

3. Konsep inti

PerformanceObserver menerima entri untuk jenis entri yang dipilih; buffered: true dapat mengambil entri yang dicatat sebelum observer dibuat. Jenis resource, long-task, paint, dan LCP memiliki batas buffer, dan callback dapat menerima droppedEntriesCount untuk mengetahui entri yang dibuang karena buffer penuh. LCP adalah waktu render dari gambar atau blok teks terbesar selama pemuatan; setelah input pengguna, konten setelahnya tidak boleh dianggap sebagai LCP awal. Tanpa header respons Timing-Allow-Origin yang sesuai, data timing untuk resource cross-origin mungkin dibatasi atau hilang.

4. Implementasi referensi

startCollector():
  session = createSessionId()
  observe("largest-contentful-paint", {buffered: true})
  observe("resource", {buffered: true})
  observe("longtask", {buffered: true})

observe(type, options):
  if type not in PerformanceObserver.supportedEntryTypes:
    markUnsupported(type)
    return
  observer = new PerformanceObserver((list, _, dropped) =>
    appendSanitized(list.getEntries())
    if dropped > 0: markDropped(type, dropped)
    flushWhenBatchIsReady()
  )
  observer.observe({type, ...options})

onSoftNavigation(route):
  closePreviousView(route)
  resetViewScopedMetrics()

Daftarkan observer terpisah untuk setiap jenis entri dan gunakan buffered untuk mengambil catatan awal. Callback hanya menyimpan bidang yang diperlukan, menghapus parameter URL, dan mengirim batch. Setiap tampilan menyimpan waktu pendaftaran observer, rute, dan rilis; navigasi halus menutup tampilan sebelumnya dan mengatur ulang metrik yang dicakup tampilan. Jumlah resource atau error dengan cakupan sesi berlanjut dengan kunci deduplikasi yang eksplisit.

5. Kualitas data dan kompromi biaya

Pengambilan sampel yang lebih tinggi menstabilkan kuantil tetapi meningkatkan biaya jaringan dan penyimpanan. Pertahankan sampel yang lebih tinggi untuk LCP dan long-task, sambil melakukan head-sampling pada entri resource atau hanya mempertahankan resource yang lambat. Satu buffer resource menampung hingga 250 entri secara default, sehingga pengumpul harus mengonsumsinya selama siklus hidup halaman dan mencatat kehilangan alih-alih meningkatkan frekuensi pelaporan tanpa henti. Batasi percobaan ulang di sisi klien setelah kegagalan batch dan buang batch usang pada kunjungan berikutnya agar antrean lokal tidak memperlambat startup.

6. Verifikasi dan observabilitas

• Buat entri sebelum pendaftaran observer untuk memverifikasi buffered; gunakan halaman yang sarat resource untuk memverifikasi peringatan droppedEntriesCount.
• Uji resource cross-origin dengan dan tanpa Timing-Allow-Origin dan pastikan alasan bidang yang hilang tetap dapat dibedakan.
• Putar ulang pemuatan awal, navigasi halus, pemulihan latar belakang, dan penyembunyian halaman secara terpisah; verifikasi entri LCP dan resource tidak diatribusikan ke beberapa tampilan.
• Pantau CPU pengumpul, memori, bita yang dilaporkan, tingkat kegagalan batch, tingkat kehilangan entri, dan tingkat dukungan.

7. Kesalahan umum

• Membuat observer hanya setelah peristiwa load, sehingga kehilangan entri LCP atau resource awal secara permanen.
• Mengabaikan droppedEntriesCount secara diam-diam sambil memperlakukan sampel yang tidak lengkap sebagai distribusi yang lengkap.
• Memperlakukan timing cross-origin yang dibatasi sebagai latensi nol sejati dan merusak kuantil performa.
• Membuat observer baru di setiap rute SPA tanpa menutup observer lama, yang menyebabkan duplikasi laporan dan kebocoran memori.

8. Poin penilaian wawancara

Menggunakan siklus hidup observer dengan benar

Jawaban harus mencakup buffered, supportedEntryTypes, penutupan observer, dan batasan navigasi halus untuk menghindari kehilangan awal dan atribusi ganda.

Menangani batasan buffer dan cross-origin

Kandidat harus memantau droppedEntriesCount, mengetahui batas buffer resource, dan menggunakan Timing-Allow-Origin untuk menjelaskan bidang cross-origin yang hilang.

Merancang pengambilan sampel dan pelaporan yang terkontrol

Kandidat harus mengalokasikan pengambilan sampel, batas entri, dan batching berdasarkan nilai metrik serta menjelaskan mengapa percobaan ulang tidak memperlambat halaman.

Memverifikasi keandalan data

Kandidat harus mencakup entri awal, halaman yang sarat resource, timing cross-origin, navigasi halus, dan pemulihan latar belakang sambil mengukur overhead dan kehilangan data pengumpul.