Masalah dan skenario yang berlaku
Pembuatan HTML lambat, dan kumpulan sumber daya bervariasi menurut pengguna, eksperimen, atau otorisasi. Rancang kebijakan prediksi yang menghasilkan 103 Early Hints berdasarkan rute dan kohor, dengan ambang batas keyakinan yang eksplisit, batas privasi, dan kontrol salah prediksi.
Hal ini cocok untuk wawancara backend, edge-gateway, dan rekayasa performa. Asumsikan permintaan tersebut pada akhirnya mengembalikan respons 2xx atau pengalihan (redirect), dan kumpulan sumber daya dapat bervariasi menurut pengguna, eksperimen, atau otorisasi.
Hal yang dievaluasi oleh pewawancara
- Apakah Anda memahami bahwa 103 adalah petunjuk sementara, bukan respons akhir atau status bisnis.
- Apakah kepastian sumber daya, versi protokol, dan perilaku cross-origin mendorong keputusan kirim-atau-lewati.
- Apakah Anda dapat menangani ketidaksesuaian petunjuk/akhir, pengalihan, dan batasan CSP.
- Apakah Anda menggunakan peramban nyata, cache, dan metrik protokol berlapis daripada hanya mengandalkan waktu server.
Pertanyaan klarifikasi sebelum menjawab
- Apakah sumber daya diketahui sebelum pembuatan HTML akhir? Ketidakpastian membuat unduhan spekulatif menjadi sia-sia.
- Apakah koneksinya HTTP/2 atau lebih baru? Klien HTTP/1.1 lama mungkin salah menangani respons informasional.
- Sumber daya mana yang layak mendapatkan petunjuk? CSS penting, font, dan pemanasan koneksi memiliki hasil yang berbeda dibandingkan gambar berprioritas rendah.
- Apakah terdapat pengalihan cross-origin, CSP, kohor pengguna, atau perbedaan otorisasi? Masing-masing mengubah validitas petunjuk.
Kerangka jawaban 30 detik
“Saya memperlakukan 103 sebagai petunjuk performa yang dapat dibuang dan hanya mengirimkan sumber daya Link berkeyakinan tinggi yang kemungkinan besar muncul dalam respons akhir. Saya membatasinya hanya pada HTTP/2 atau lebih baru, memperoleh daftarnya di batas CDN/origin, dan melewatinya ketika pengalihan atau sumber daya khusus pengguna membuat prediksi menjadi tidak pasti. Respons akhir tetap membawa Link dan CSP yang otoritatif, dan logika bisnis tidak pernah bergantung pada 103. Dalam canary, saya mengukur kedatangan, lead time, tingkat pramuat yang berguna, unduhan duplikat, dan kesalahan; saya mematikannya jika tidak ada keuntungan yang terlihat oleh pengguna.”
Pembahasan mendalam langkah demi langkah
1. Pisahkan petunjuk dari respons bisnis
RFC 8297 mendefinisikan 103 sebagai respons informasional: klien dapat memproses header secara spekulatif saat menunggu, tetapi tidak boleh memperlakukannya sebagai metadata akhir. Kirimkan petunjuk performa saja, jangan pernah mengirimkan otorisasi, harga, atau status keberhasilan. Respons akhir harus tetap benar ketika proksi membuang 103.
2. Pilih header Link dengan kepastian tinggi
Utamakan CSS di paruh atas (above-the-fold), font, atau preconnect ke CDN tetap. Jika kohor, izin, atau eksperimen mengubah kumpulan sumber daya, hitung persimpangan (intersection) yang aman atau lewati petunjuk. Petunjuk bukanlah unduhan paksa; as, CORS, dan CSP tetap mengatur pengambilan tersebut.
3. Tetapkan gerbang protokol dan pengalihan
Jadikan HTTP/2 atau lebih baru sebagai gerbang default untuk kompatibilitas dan keamanan. Ketika permintaan berakhir pada pengalihan cross-origin, peramban dapat membuang 103 yang pertama; gateway juga dapat menggabungkan atau menyusun ulang respons informasional. Uji rantai proksi dalam canary sehingga 103 tidak pernah disalahartikan sebagai respons akhir.
4. Tangani CSP dan pergeseran respons akhir
103 dapat membawa CSP yang membatasi pemuatan spekulatif, tetapi respons akhir tetap bersifat otoritatif. Jika server kemudian menemukan sumber daya yang salah, klien mungkin telah mulai mengunduhnya. Batasi petunjuk pada aset berisiko rendah, dapat di-cache, dan dapat dibuang dengan aman; jangan pernah menggunakan 103 untuk melewati CSP akhir.
5. Verifikasi dengan metrik berlapis
Pertahankan grup kontrol tanpa 103 dan aktifkan hanya untuk HTTP/2 atau lebih baru dalam eksperimen. Ukur kedatangan 103, lead time sumber daya, rasio pramuat yang berguna, permintaan duplikat, LCP akhir, bandwidth, dan kesalahan. Bagi berdasarkan cache hit, pengalihan cross-origin, dan perangkat; jika TTFB membaik tetapi LCP tidak, kembalikan ke kondisi semula (roll back).
Contoh jawaban berkualitas tinggi
Pertama-tama saya akan memastikan bahwa 103 hanya membawa petunjuk performa dan respons akhir tidak bergantung padanya. Untuk HTTP/2 atau lebih baru, saya hanya akan memberi petunjuk untuk CSS paruh atas berkeyakinan tinggi, font, atau koneksi CDN tetap; kohor pengguna, otorisasi, atau pengalihan cross-origin yang membuat kumpulan sumber daya tidak pasti akan dilewati. Canary gateway dan peramban harus membuktikan bahwa respons informasional tidak diperlakukan sebagai respons akhir, sementara respons akhir mengulangi Link dan CSP yang otoritatif. Saya akan membandingkan kedatangan, tingkat hit yang berguna, unduhan duplikat, LCP, bandwidth, dan kesalahan berdasarkan cache dan perangkat; jika hanya TTFB server yang membaik, saya akan menonaktifkan Early Hints.
Kesalahan umum
- Gejala: Memperlakukan 103 sebagai respons keberhasilan. Mengapa ini gagal: tidak memiliki semantik penyelesaian bisnis dan dapat dibuang. Solusi: lengkapi otorisasi, status, dan body dalam respons akhir.
- Gejala: Melakukan pramuat untuk setiap sumber daya. Mengapa ini gagal: halaman dinamis menghasilkan unduhan yang sia-sia, perebutan bandwidth, dan polusi cache. Solusi: beri petunjuk hanya pada aset dengan kepastian tinggi dan tetapkan ambang batas hit yang berguna.
- Gejala: Mengabaikan HTTP/1.1 dan rantai proksi. Mengapa ini gagal: klien lama mungkin salah menangani respons informasional. Solusi: tambahkan gerbang protokol, uji proksi, dan tombol pemutus (kill switch).
- Gejala: Hanya mengukur TTFB. Mengapa ini gagal: petunjuk yang lebih awal mungkin tidak meningkatkan rendering dan dapat bersaing memperebutkan bandwidth. Solusi: ukur LCP, duplikasi, bandwidth, dan kesalahan.
Pertanyaan lanjutan dan jawaban
Bagaimana jika sumber daya yang diberi petunjuk tidak lagi diperlukan?
Batasi petunjuk pada aset spekulatif yang aman dan batasi tingkat unduhan yang tidak valid. 103 tidak dapat menjamin bahwa suatu sumber daya akan digunakan.
Haruskah Anda tetap mengirimkan 103 pada pengalihan cross-origin?
Lewati secara default, atau batasi hanya untuk pemanasan koneksi aman yang tidak terkait dengan target akhir. Peramban dapat membuang 103 yang pertama dan proksi dapat menyusun ulang respons, jadi putuskan berdasarkan pengujian ujung-ke-ujung (end-to-end).
Bolehkah Link akhir berbeda dari Link pada 103?
Ya: 103 adalah petunjuk dan respons akhir bersifat otoritatif. Ketidaksesuaian yang besar menunjukkan prediktor yang buruk, jadi persempit kumpulan petunjuk dan pantau duplikasi.
Bagaimana cara mencegah 103 membocorkan informasi pengguna?
Jangan sertakan otorisasi, kohor, atau URL sensitif. Hasilkan petunjuk dari kumpulan aset publik berisiko rendah, sementara CSP akhir dan pemeriksaan otorisasi tetap aktif.
Kapan pramuat HTML biasa lebih baik daripada 103?
Gunakan pramuat HTML akhir ketika aset baru diketahui setelah pembuatan HTML atau ketika respons informasional tidak dapat dikirimkan dengan andal. 103 berguna ketika server mengetahui kumpulan aset lebih awal daripada kemampuannya menghasilkan HTML.