Topik temu duga representatif

Bagaimanakah Anda Membina Pemantauan Pengguna Sebenar yang Boleh Dipercayai dengan PerformanceObserver?

FrontendSukar
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Reka bentuk pengumpulan prestasi pengguna sebenar untuk aplikasi satu halaman. Ia mesti mengumpul data LCP, sumber, dan tugas panjang, mengawal kos pelaporan, dan mengesan kehilangan penimbal PerformanceObserver, jurang pemasaan rentas asal, serta atribusi pendua merentasi perubahan laluan.

1. Soalan

Aplikasi satu halaman yang diakses secara global memerlukan data prestasi pengguna sebenar untuk membandingkan pengalaman merentasi peranti, rangkaian, dan keluaran. Kumpulkan data LCP, pemuatan sumber, dan tugas panjang sambil mengehadkan laporan bagi setiap sesi halaman. Reka bentuk pengumpul PerformanceObserver dan terangkan cara ia mengendalikan entri yang dibuat sebelum pendaftaran pemerhati, kehilangan penimbal, sumber rentas asal, dan perubahan laluan SPA.

2. Kekangan dan penjelasan

  • Tentukan skop masa bagi setiap metrik: dokumen awal, navigasi lembut (soft navigation), atau keseluruhan sesi.
  • Tetapkan kadar persampelan, had entri setiap jenis, saiz kelompok, dan dasar percubaan semula kegagalan supaya pengumpulan tidak menjejaskan halaman.
  • Bezakan perbezaan sokongan pelayar daripada data yang hilang; nilai yang hilang memerlukan sebab dan tidak boleh dijadikan sifar.
  • Tentukan sempadan privasi untuk URL sumber, pengecam pengguna, dan dimensi pertanyaan; jangan laporkan URL lengkap atau parameter sensitif secara terus.

3. Konsep teras

PerformanceObserver menerima entri untuk jenis entri yang dipilih; buffered: true boleh mendapatkan semula entri yang direkodkan sebelum pemerhati dicipta. Jenis sumber, tugas panjang, cat (paint), dan LCP mempunyai had penimbal, dan panggilan balik boleh menerima droppedEntriesCount untuk mendedahkan entri yang dibuang kerana penimbal penuh. LCP ialah masa render imej atau blok teks terbesar semasa pemuatan; selepas input pengguna, kandungan terkemudian tidak boleh dianggap sebagai LCP awal. Tanpa pengepala respons Timing-Allow-Origin yang sesuai, data pemasaan untuk sumber rentas asal mungkin dihadkan atau hilang.

4. Pelaksanaan rujukan

text
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 pemerhati berasingan untuk setiap jenis entri dan gunakan buffered untuk mendapatkan semula rekod awal. Panggilan balik hanya mengekalkan medan yang diperlukan, membuang parameter URL, dan menghantar kelompok. Setiap paparan menyimpan masa pendaftaran pemerhati, laluan, dan keluaran; navigasi lembut menutup paparan sebelumnya dan menetapkan semula metrik berskop paparan. Kiraan sumber atau ralat berskop sesi diteruskan dengan kunci penyahduplikasian yang jelas.

5. Kualiti data dan pertukaran kos

Persampelan yang lebih tinggi menstabilkan kuantil tetapi meningkatkan kos rangkaian dan storan. Kekalkan sampel yang lebih tinggi untuk LCP dan tugas panjang, sambil melakukan persampelan awal (head-sampling) pada entri sumber atau hanya mengekalkan sumber yang perlahan. Satu penimbal resource memegang sehingga 250 entri secara lalai, jadi pengumpul harus menggunakannya semasa kitaran hayat halaman dan merekodkan kehilangan dan bukannya meningkatkan kekerapan laporan tanpa henti. Hadkan percubaan semula klien selepas kegagalan kelompok dan buang kelompok basi pada lawatan seterusnya supaya baris gilir tempatan tidak memperlahankan permulaan.

6. Pengesahan dan kebolehcerapan

  • Cipta entri sebelum pendaftaran pemerhati untuk mengesahkan buffered; gunakan halaman yang padat sumber untuk mengesahkan amaran droppedEntriesCount.
  • Uji sumber rentas asal dengan dan tanpa Timing-Allow-Origin serta sahkan sebab medan hilang kekal boleh dibezakan.
  • Main semula pemuatan awal, navigasi lembut, pemulihan latar belakang, dan penyembunyian halaman secara berasingan; sahkan entri LCP dan sumber tidak diatribusikan kepada beberapa paparan.
  • Pantau CPU pengumpul, memori, bait yang dilaporkan, kadar kegagalan kelompok, kadar kehilangan entri, dan kadar sokongan.

7. Kesilapan biasa

  • Mencipta pemerhati hanya selepas peristiwa load, menyebabkan entri LCP atau sumber awal terlepas secara kekal.
  • Mengabaikan droppedEntriesCount secara senyap sambil menganggap sampel yang tidak lengkap sebagai taburan yang lengkap.
  • Menganggap pemasaan rentas asal yang dihadkan sebagai kependaman sifar sebenar dan merosakkan kuantil prestasi.
  • Mencipta pemerhati baharu pada setiap laluan SPA tanpa menutup yang lama, menyebabkan laporan bertindih dan kebocoran memori.

8. Mata pemarkahan temu duga

Menggunakan kitaran hayat pemerhati dengan betul

Jawapan harus merangkumi buffered, supportedEntryTypes, penutupan pemerhati, dan sempadan navigasi lembut untuk mengelakkan kehilangan awal dan atribusi pendua.

Mengendalikan had penimbal dan rentas asal

Calon harus memantau droppedEntriesCount, mengetahui had penimbal sumber, dan menggunakan Timing-Allow-Origin untuk menerangkan medan rentas asal yang hilang.

Merekabentuk persampelan dan pelaporan terkawal

Calon harus memperuntukkan persampelan, had entri, dan pengelompokan mengikut nilai metrik serta menerangkan sebab percubaan semula tidak memperlahankan halaman.

Mengesahkan kebolehpercayaan data

Calon harus merangkumi entri awal, halaman padat sumber, pemasaan rentas asal, navigasi lembut, dan pemulihan latar belakang sambil mengukur overhed dan kehilangan data pengumpul.

Sumber awam

Soalan berkaitan