Topik temu duga representatif

Temuduga frontend: Bagaimanakah anda akan menggunakan Long Animation Frames API untuk mendiagnosis INP di lapangan?

FrontendSukar
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Metrik makmal anda kelihatan sihat, tetapi beberapa pengguna sebenar mengalami INP yang lemah. Reka saluran paip diagnostik lapangan menggunakan Long Animation Frames API (LoAF) untuk mengasingkan kelewatan input, kerja skrip dan kos rendering sambil mengawal kos pelaporan dan risiko privasi.

Gesaan dan konteks

Halaman kelihatan baik dalam Lighthouse, namun pengguna sebenar melaporkan bahawa klik terasa tersekat. RUM sedia ada hanya melaporkan nilai INP dan tidak dapat memberitahu sama ada pengendali peristiwa, requestAnimationFrame, gaya dan susun atur, atau skrip pihak ketiga yang menyebabkan kelewatan tersebut. Reka gelung pemerhatian LoAF, korelasi, persampelan, pengagregatan dan pembaikan.

Perkara yang sedang diuji oleh penemuduga

  • Sama ada anda memahami kelewatan input (input delay), tempoh pemprosesan dan kelewatan persembahan (presentation delay) bagi INP.
  • Sama ada anda tahu LoAF mengukur bingkai melebihi 50 milisaat dan mendedahkan atribusi skrip serta pemasaan rendering.
  • Sama ada anda mengaitkan interaksi, LoAF, versi halaman dan konteks peranti dan bukannya memuat naik setiap peristiwa mentah.
  • Sama ada anda mengendalikan sokongan pelayar, penimbal, skrip silang asal (cross-origin) dan risiko privasi.
  • Sama ada anda menyambungkan data kepada pembaikan kod, semakan regresi dan amaran.

Soalan untuk dijelaskan terlebih dahulu

  1. Adakah matlamatnya diagnosis INP, kelancaran animasi, pemantauan tugas panjang, atau ketiga-tiganya?
  2. Apakah kadar persampelan, pengguna harian, belanjawan pelaporan dan tempoh pengekalan?
  3. Bolehkah anda merekodkan URL, sumber skrip, jenis interaksi dan versi halaman?
  4. Pelayar manakah yang mesti disokong, dan apakah sandaran apabila LoAF tidak tersedia?
  5. Pasukan manakah yang memiliki amaran dan pembaikan, dan adakah ambang harus menggunakan p75, p95 atau kohort peranti?

Jawapan 30 saat

“Saya akan meletakkan pecahan fasa INP dan pemerhatian LoAF dalam satu laluan korelasi RUM. Gunakan PerformanceObserver untuk long-animation-frame, kekalkan hanya bingkai yang bersilang dengan tetingkap interaksi INP tinggi, dan simpan duration, blockingDuration, renderStart, styleAndLayoutStart serta atribusi skrip. Kesan sokongan, redact medan, sampel secara dinamik dan kelompokkan laporan dengan versi halaman, kohort peranti dan kunci sesi tanpa nama. Agregatkan mengikut interaksi dan keluaran, kemudian pautkan amaran kepada sourceURL dan fungsi. Sahkan setiap pembaikan dengan kohort dan persampelan yang sama.”

Analisis mendalam langkah demi langkah

1. Pisahkan fasa-fasa INP

Kelewatan input ialah masa dari giliran sehingga permulaan pengendali, tempoh pemprosesan ialah pelaksanaan pengendali, dan kelewatan persembahan ialah masa dari tamat pemprosesan sehingga bingkai dicat seterusnya. LoAF tidak menggantikan INP; ia menambah konteks bingkai untuk mencari fasa yang perlahan.

2. Perhatikan entri LoAF

Perhatikan long-animation-frame dengan PerformanceObserver dan bukannya membaca garis masa prestasi secara berulang kali. Ambang adalah 50 milisaat, dan entri termasuk duration, blockingDuration, renderStart, styleAndLayoutStart, firstUIEventTimestamp dan scripts.

js
if (PerformanceObserver.supportedEntryTypes.includes("long-animation-frame")) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      queueFrameForCorrelation(entry);
    }
  });
  observer.observe({ type: "long-animation-frame", buffered: true });
}

3. Korelasikan interaksi dan keluaran

Kekalkan ringkasan interaksi INP jangka pendek dan penimbal cincin bagi entri LoAF. Apabila interaksi tamat, gunakan firstUIEventTimestamp, startTime dan duration untuk mencari bingkai yang bersilang dan kekalkan hanya beberapa bingkai yang paling memberi penjelasan. Lampirkan versi halaman, kohort eksperimen, kelas peranti dan kunci sesi tanpa nama, jangan sekali-kali input lengkap.

4. Jelaskan kos skrip dan rendering

blockingDuration menganggarkan masa yang menyekat input atau kerja berkeutamaan tinggi; renderStart dan styleAndLayoutStart membantu memisahkan pra-render, gaya/susun atur dan fasa lain. scripts boleh mengenal pasti URL utas utama, fungsi dan jenis pemanggil, tetapi iframe silang asal, pekerja (workers) dan sambungan mungkin mempunyai atribusi yang tidak lengkap.

5. Reka kawalan persampelan dan privasi

Laporkan INP tinggi, bingkai panjang luar biasa, atau sampel rawak kecil secara lalai; hadkan kadar bagi setiap sesi tanpa nama. Senarai putihkan atau cincang domain skrip, buang parameter pertanyaan, input pengguna dan teks DOM, serta lumpuhkan atribusi terperinci pada halaman sensitif. Kuat kuasakan pengekalan, akses, pemadaman dan dasar persampelan berversi pada pelayan.

6. Tutup gelung pengagregatan dan pembaikan

Agregatkan p75/p95 mengikut interaksi, keluaran, peranti, rangkaian dan sumber skrip dan bukannya purata tapak tunggal. Amaran menunjukkan fasa input, pemprosesan dan persembahan serta atribusi biasa. Bandingkan sebelum dan selepas menggunakan persampelan dan kohort yang sama untuk memastikan isu itu tidak berpindah ke peranti atau interaksi lain.

Contoh jawapan yang mantap

“Saya mula-mula akan menggunakan pecahan fasa INP untuk memutuskan sama ada input, pemprosesan atau persembahan mendominasi, kemudian menambah bukti LoAF. Klien mengesan ciri dan memerhati long-animation-frame, mengekalkan hanya entri yang bersilang dengan interaksi INP tinggi bersama-sama duration, blockingDuration, pemasaan rendering dan atribusi skrip yang tersedia. Korelasi menggunakan keluaran, kohort eksperimen, peranti dan kunci sesi tanpa nama, bukan input pengguna. Atribusi terperinci disampel dan diredact dengan had pengekalan; pelayar yang tidak disokong masih melaporkan INP asas. Pelayan mengagregatkan mengikut interaksi, keluaran dan peranti, memberi amaran tentang kemungkinan kod sumber dan mengesahkan pembaikan dengan semakan regresi peringkat kohort.”

Kesilapan biasa

  • Melaporkan hanya satu nombor INP → tiada diagnosis fasa atau kod → korelasikan fasa INP dengan bingkai LoAF.
  • Memuat naik setiap bingkai panjang mentah → kos tinggi dan konteks terdedah → sampel, redact dan simpan bingkai yang bersilang dengan INP tinggi.
  • Menganggap 50 milisaat sebagai garis lulus INP → ambang bingkai dikelirukan dengan metrik produk → terangkan ambang dan sasaran persentil secara berasingan.
  • Menganggap setiap skrip mempunyai atribusi → bingkai silang asal dan pekerja tidak lengkap → tandakan jurang dan analisis dengan keluaran dan kohort peranti.
  • Hanya melihat purata tapak → isu teruk khusus peranti hilang → segmenkan mengikut interaksi, peranti, rangkaian dan keluaran.

Soalan susulan dan respons

Adakah LoAF akan menggantikan Long Tasks API?

Bukan secara langsung. LoAF mengukur bingkai dan membekalkan konteks yang lebih kaya, manakala Long Tasks kekal berguna untuk pemantauan sedia ada dan pelayar yang serasi. Bandingkan kedua-duanya semasa migrasi dan bukannya memadamkan isyarat lama secara tiba-tiba.

Mengapakah tidak memuat naik setiap URL skrip?

URL boleh mengandungi pengecam, parameter pertanyaan atau laluan dalaman, dan ia meningkatkan volum. Buang parameter, hadkan domain, cincang nilai atau simpan pemetaan sumber berversi sahaja mengikut sensitiviti halaman.

Bagaimanakah anda membezakan kos susun atur daripada pelaksanaan skrip?

Bandingkan renderStart, styleAndLayoutStart, duration dan entri skrip. Jika masa skrip adalah kecil tetapi selang gaya/susun atur adalah besar, periksa saiz DOM, pemilih (selectors) dan susun atur segerak; sahkan dengan surihan makmal.

Bagaimana pula dengan pelayar tanpa LoAF?

Kesan ciri dan sandarkan kepada INP asas, Event Timing atau Long Tasks, sambil menandakan versi pemerhatian pada bahagian pelayan. Jangan kecualikan pengguna tersebut daripada metrik pengalaman keseluruhan; dedahkan perbezaan keupayaan diagnostik dalam laporan yang disegmentasikan.

Sumber awam

Soalan berkaitan