Topik wawancara representatif

Bagaimana Anda Mengukur Early Hints dengan firstInterimResponseStart?

FrontendSedang
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Implementasikan observer frontend untuk byte pertama dari respons interim 1xx dan jelaskan cara membedakan 103 Early Hints, perilaku cache, masking cross-origin, dan browser yang tidak didukung.

Pertanyaan dan konteks

Browser mulai mengadopsi PerformanceResourceTiming.firstInterimResponseStart, yang mencatat kapan byte pertama dari respons interim 1xx tiba. Implementasikan observer untuk mengevaluasi apakah 103 Early Hints mengurangi waktu persiapan sumber daya, termasuk kasus yang tidak didukung, cross-origin, dan di-cache.

Apa yang sedang diuji oleh pewawancara

  • Apakah Anda memahami requestStart, firstInterimResponseStart, dan timing header respons akhir.
  • Apakah Anda tahu bahwa nol dapat berarti tidak ada 1xx, masking cross-origin, atau timestamp yang tidak tersedia terkait cache.
  • Apakah Anda dapat menggunakan PerformanceObserver dengan entri yang di-buffer dan pelaporan yang disampel.
  • Apakah Anda memisahkan manfaat protokol dari dukungan browser, Timing-Allow-Origin, dan metrik produk.

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

Tujuan pengukuran

Apakah kita mengukur waktu hingga 1xx pertama, jumlah preload Early Hints, atau hasil pengguna seperti LCP dan kesiapan interaksi?

Cakupan sumber daya

Haruskah kita mengamati hanya navigasi same-origin, atau juga aset CDN, font, dan skrip cross-origin? Apakah Timing-Allow-Origin sudah dikonfigurasi?

Kebijakan kompatibilitas

Apakah data tersebut akan mendorong keputusan langsung? Haruskah browser lama menyediakan metrik fallback yang setara saat properti tidak tersedia?

Kerangka jawaban 30 detik

Saya akan menggunakan PerformanceObserver dan menghitung firstInterimResponseStart - requestStart hanya ketika properti tersebut ada dan bernilai bukan nol. Nol tidak dapat membuktikan bahwa server mengabaikan 103 karena timing cross-origin mungkin di-mask dan jalur cache dapat menampilkan nol. Telemetri harus mencatat dukungan, cakupan origin, dan timing respons akhir, kemudian memvalidasi Early Hints terhadap metrik pengguna seperti LCP.

Langkah jawaban mendalam

1. Jelaskan timestamp

requestStart adalah saat browser akan meminta sumber daya; firstInterimResponseStart adalah saat byte pertama dari respons 1xx tiba; finalResponseHeadersStart adalah saat header respons akhir tiba. Ketika respons interim ada, perbedaan pertama mendekati waktu tunggu jaringan hingga 1xx tersebut.

2. Tulis observer

js
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const interim = entry.firstInterimResponseStart;
    if (typeof interim !== "number" || interim <= 0) continue;

    reportTiming({
      name: entry.name,
      interimWait: interim - entry.requestStart,
      finalHeaders: entry.finalResponseHeadersStart - interim,
      initiator: entry.initiatorType,
    });
  }
});

observer.observe({ type: "resource", buffered: true });

Kode produksi harus melakukan feature-detection pada properti dan membatasi nama, sampling, serta bidang sehingga URL lengkap atau parameter kueri yang sensitif tidak masuk ke analitik.

3. Menafsirkan nol dengan benar

Nol dapat berarti tidak ada respons interim, atau sumber daya cross-origin tidak mengekspos timing melalui Timing-Allow-Origin; cache hits dan permintaan yang dibatalkan juga dapat menghasilkan nol untuk timestamp terkait. Dasbor harus memisahkan "tidak teramati" dari "dikonfirmasi tidak ada 1xx" dan tidak pernah mengubah nol menjadi durasi negatif atau kegagalan otomatis.

4. Menangani sumber daya cross-origin

Jika CDN atau font bersifat cross-origin, server harus mengembalikan Timing-Allow-Origin untuk situs yang diizinkan sebelum bidang timing yang dilindungi diekspos. Konfigurasikan header tersebut untuk origin penerapan sebenarnya daripada setiap origin, dan terima bahwa beberapa pengguna tetap tidak dapat diamati karena kebijakan.

5. Memisahkan 103 dari manfaat pengguna

Properti melaporkan timing 1xx pertama; itu tidak mengidentifikasi 103 atau membuktikan bahwa preload digunakan. Konfirmasikan 103 dengan data navigasi, log server, atau eksperimen terkontrol, lalu bandingkan finalResponseHeadersStart, responseEnd sumber daya, dan LCP. Preload yang terlalu dini atau salah dapat merusak performa bahkan ketika 1xx pertama tiba dengan cepat.

6. Merancang fallback kompatibilitas

Browser yang tidak didukung masih dapat melaporkan metrik umum requestStart, responseStart, dan responseEnd, tetapi tidak dapat mengarang timing interim. Tandai kapabilitas dan agregasikan sampel lama dan baru secara terpisah; API yang hilang tidak boleh memblokir rendering.

7. Membangun verifikasi dan tata kelola

Bandingkan kasus same-origin dan cross-origin HTTP/2 atau yang lebih baru, cache hits dan misses, serta server dengan dan tanpa 103. Pastikan interimWait >= 0 dan bahwa header akhir tidak mendahului respons interim pertama. Batasi frekuensi laporan dan interpretasikan timing bersama LCP, rasio preload hit, dan tingkat kesalahan daripada memperlakukan timestamp jaringan sebagai hasil produk.

Contoh jawaban berkualitas tinggi

Saya akan menggunakan PerformanceObserver yang di-buffer dan melaporkan waktu tunggu 1xx hanya ketika firstInterimResponseStart ada dan bernilai bukan nol. Saya akan mempertahankan nol sebagai tidak pasti, melakukan segmentasi berdasarkan origin, Timing-Allow-Origin, cache, dan kapabilitas browser, serta memverifikasi 103 dengan eksperimen terkontrol. Early Hints dipertahankan hanya jika LCP, rasio preload hit, dan error membaik—bukan hanya karena byte interim tiba lebih cepat.

Kesalahan umum

  • Memperlakukan nilai bukan nol sebagai bukti bahwa responsnya adalah 103.
  • Memperlakukan setiap nilai nol sebagai bukti bahwa server tidak mengirim 1xx.
  • Mengabaikan kesenjangan data yang disebabkan oleh hilangnya Timing-Allow-Origin cross-origin.
  • Menggunakan responseStart sebagai waktu header akhir dan mencampur respons interim dengan respons akhir.
  • Memanggil getEntriesByType hanya setelah pemuatan dan melewatkan entri yang dicatat sebelumnya.
  • Memantau timing jaringan tanpa memeriksa LCP, preload hits, dan error.

Pertanyaan lanjutan dan jawaban

Bisakah firstInterimResponseStart mengonfirmasi 103?

Tidak. Ini mencatat byte pertama dari respons 1xx apa pun, termasuk 100 Continue. Konfirmasikan 103 dengan log server, permintaan terkontrol, dan perilaku pemuatan sumber daya.

Mengapa entri cross-origin sering bernilai nol?

Resource Timing menyamarkan (mask) timestamp cross-origin. Tanpa Timing-Allow-Origin yang cocok, bidang yang dilindungi mengembalikan nol. Perbaiki kebijakan respons atau klasifikasikan sampel sebagai tidak dapat diamati; jangan mengarang perkiraan.

Apa perbedaan antara responseStart dan finalResponseHeadersStart?

Dengan respons interim, responseStart mungkin mencerminkan byte interim pertama, sedangkan finalResponseHeadersStart mewakili header akhir. Gunakan yang terakhir saat mengukur persiapan server sebelum respons akhir.

Apa fallback untuk browser lama?

Lakukan feature-detection pada properti, lanjutkan pengumpulan waktu permintaan dan respons umum, dan tandai bidang interim yang hilang. Agregasikan sampel browser lama secara terpisah dari sampel API baru.

Bagaimana Anda membuktikan bahwa Early Hints layak dipertahankan?

Jalankan kohort yang diaktifkan dan dinonaktifkan dengan jaringan, cache, dan versi aset yang sama. Bandingkan LCP, rasio preload hit, waktu header akhir, penyelesaian sumber daya, dan error; 1xx yang lebih awal hanyalah bukti perantara.

Sumber publik

Pertanyaan terkait