Bagaimanakah Anda Mengukur Early Hints dengan firstInterimResponseStart?

Soalan dan konteks

Pelayar semakin menyokong PerformanceResourceTiming.firstInterimResponseStart, yang merekodkan masa bait pertama respons interim 1xx tiba. Laksanakan pemerhati untuk menilai sama ada 103 Early Hints mengurangkan masa penyediaan sumber, termasuk kes yang tidak disokong, rentas asal, dan dicache.

Perkara yang sedang diuji oleh penemu duga

• Sama ada anda memahami requestStart, firstInterimResponseStart, dan pemasaan pengepala respons akhir.
• Sama ada anda tahu bahawa sifar boleh bermaksud tiada 1xx, pemintasan rentas asal, atau cap masa tidak tersedia yang berkaitan dengan cache.
• Sama ada anda boleh menggunakan PerformanceObserver dengan entri yang dibimbit (buffered) dan pelaporan persampelan.
• Sama ada anda memisahkan faedah protokol daripada sokongan pelayar, Timing-Allow-Origin, dan metrik produk.

Soalan penjelasan untuk ditanya terlebih dahulu

Matlamat pengukuran

Adakah kita mengukur masa sehingga 1xx pertama, bilangan pramuat (preload) Early Hints, atau hasil pengguna seperti LCP dan kesediaan interaksi?

Skop sumber

Patutkah kita memerhati navigasi asal sama (same-origin) sahaja, atau juga aset CDN, fon, dan skrip rentas asal? Adakah Timing-Allow-Origin dikonfigurasikan?

Dasar keserasian

Adakah data ini akan memacu keputusan langsung? Adakah pelayar lama mesti menyediakan metrik sandaran yang setara apabila sifat tersebut tidak tersedia?

Rangka jawapan 30 saat

Saya akan menggunakan PerformanceObserver dan mengira firstInterimResponseStart - requestStart hanya apabila sifat tersebut wujud dan bukan sifar. Sifar tidak boleh membuktikan bahawa pelayan tidak menghantar 103 kerana pemasaan rentas asal mungkin ditopengkan dan laluan cache boleh mendedahkan sifar. Telemetri harus merekodkan sokongan, skop asal, dan pemasaan respons akhir, kemudian mengesahkan Early Hints terhadap metrik pengguna seperti LCP.

Langkah jawapan mendalam

1. Terangkan cap masa

requestStart ialah masa apabila pelayar hendak meminta sumber; firstInterimResponseStart ialah masa apabila bait pertama respons 1xx tiba; finalResponseHeadersStart ialah masa apabila pengepala respons akhir tiba. Apabila respons interim wujud, perbezaan pertama menganggarkan masa menunggu rangkaian sehingga 1xx tersebut.

2. Tulis pemerhati

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 });

Kod pengeluaran harus mengesan ciri sifat tersebut dan mengehadkan nama, persampelan, dan medan supaya URL lengkap atau parameter pertanyaan sensitif tidak dimasukkan ke dalam analitis.

3. Tafsirkan sifar dengan betul

Sifar boleh bermaksud tiada respons interim, atau sumber rentas asal tidak mendedahkan pemasaan melalui Timing-Allow-Origin; hit cache dan permintaan yang dibatalkan juga boleh menghasilkan sifar untuk cap masa yang berkaitan. Papan pemuka harus memisahkan "tidak diperhatikan" daripada "disahkan tiada 1xx" dan tidak sekali-kali menukar sifar kepada tempoh negatif atau kegagalan automatik.

4. Kendalikan sumber rentas asal

Jika CDN atau fon adalah rentas asal, pelayan mesti mengembalikan Timing-Allow-Origin untuk tapak yang dibenarkan sebelum medan pemasaan yang dilindungi didedahkan. Konfigurasikan pengepala tersebut untuk asal penggunaan sebenar dan bukannya setiap asal, dan terima bahawa sesetengah pengguna tetap tidak dapat diperhatikan disebabkan dasar.

5. Asingkan 103 daripada faedah pengguna

Sifat ini melaporkan pemasaan 1xx pertama; ia tidak mengenal pasti 103 atau membuktikan bahawa pramuat telah digunakan. Sahkan 103 dengan data navigasi, log pelayan, atau eksperimen terkawal, kemudian bandingkan finalResponseHeadersStart, responseEnd sumber, dan LCP. Pramuat yang awal atau tidak betul boleh menjejaskan prestasi walaupun 1xx pertama tiba dengan cepat.

6. Reka bentuk sandaran keserasian

Pelayar yang tidak disokong masih boleh melaporkan metrik umum requestStart, responseStart, dan responseEnd, tetapi ia tidak boleh mereka-reka pemasaan interim. Tandakan keupayaan dan kumpulkan sampel lama dan baharu secara berasingan; API yang tiada tidak boleh menyekat paparan (rendering).

7. Bina pengesahan dan tadbir urus

Bandingkan kes asal sama dan rentas asal HTTP/2 atau lebih baharu, hit dan miss cache, serta pelayan dengan dan tanpa 103. Sahkan (assert) interimWait >= 0 dan bahawa pengepala akhir tidak mendahului respons interim pertama. Hadkan kekerapan laporan dan tafsirkan pemasaan bersama LCP, kadar hit pramuat, dan kadar ralat berbanding menganggap cap masa rangkaian sebagai hasil produk.

Contoh jawapan berkualiti tinggi

Saya akan menggunakan PerformanceObserver yang dibimbit dan melaporkan masa menunggu 1xx hanya apabila firstInterimResponseStart wujud dan bukan sifar. Saya akan mengekalkan sifar sebagai tidak ditentukan, membahagikan mengikut asal, Timing-Allow-Origin, cache, dan keupayaan pelayar, serta mengesahkan 103 dengan eksperimen terkawal. Early Hints hanya dikekalkan jika LCP, kadar hit pramuat, dan ralat bertambah baik—bukan semata-mata kerana bait interim tiba lebih awal.

Kesilapan biasa

• Menganggap nilai bukan sifar sebagai bukti bahawa respons adalah 103.
• Menganggap setiap sifar sebagai bukti bahawa pelayan tidak menghantar sebarang 1xx.
• Mengabaikan jurang data yang disebabkan oleh ketiadaan Timing-Allow-Origin rentas asal.
• Menggunakan responseStart sebagai masa pengepala akhir dan mencampurkan respons interim dengan respons akhir.
• Memanggil getEntriesByType hanya selepas pemuatan dan terlepas entri yang direkodkan lebih awal.
• Memerhati pemasaan rangkaian tanpa menyemak LCP, hit pramuat, dan ralat.

Soalan susulan dan jawapan

Bolehkah firstInterimResponseStart mengesahkan 103?

Tidak. Ia merekodkan bait pertama bagi sebarang respons 1xx, termasuk 100 Continue. Sahkan 103 dengan log pelayan, permintaan terkawal, dan tingkah laku pemuatan sumber.

Mengapakah entri rentas asal sering kali bernilai sifar?

Resource Timing memintaskan cap masa rentas asal. Tanpa Timing-Allow-Origin yang sepadan, medan yang dilindungi mengembalikan sifar. Betulkan dasar respons atau kelaskan sampel sebagai tidak dapat diperhatikan; jangan mereka-reka anggaran.

Bagaimanakah perbezaan antara responseStart dan finalResponseHeadersStart?

Dengan respons interim, responseStart mungkin mencerminkan bait interim pertama, manakala finalResponseHeadersStart mewakili pengepala akhir. Gunakan yang kedua apabila mengukur penyediaan pelayan sebelum respons akhir.

Apakah sandaran untuk pelayar yang lebih lama?

Kesan ciri sifat tersebut, teruskan mengumpul masa permintaan dan respons umum, dan tandakan medan interim yang tiada. Kumpulkan sampel pelayar lama secara berasingan daripada sampel API baharu.

Bagaimanakah anda membuktikan Early Hints bernilai untuk dikekalkan?

Jalankan kohort yang didayakan dan dilumpuhkan dengan rangkaian, cache, dan versi aset yang sama. Bandingkan LCP, kadar hit pramuat, masa pengepala akhir, penyiapan sumber, dan ralat; 1xx yang lebih awal hanyalah bukti perantaraan.