Wawancara Backend: Penjelasan HTTP 103 Early Hints dan Trade-off Preload

Perintah dan konteks

Pertanyaan HTTP, gateway, dan performa ini cocok untuk peran backend, platform, dan infrastruktur. Origin memiliki waktu tunggu yang dapat diprediksi sebelum HTML final siap. Anda harus memutuskan apakah akan mengirim 103 dan menghindari preload yang salah, kegagalan penguraian (parsing) pada klien lama, serta unduhan duplikat.

Hal yang dievaluasi pewawancara

• Membedakan semantik petunjuk 103 dari semantik respons final.
• Menggunakan waktu berpikir server (think time), stabilitas sumber daya, dan hit cache untuk menilai manfaatnya.
• Merancang fallback yang mulus pada HTTP/2 atau HTTP/3 daripada menjadikan 103 sebagai jalur wajib.
• Memverifikasi bahwa preload tidak menghasilkan permintaan duplikat, sumber daya yang salah, atau pemborosan bandwidth.

Pertanyaan klarifikasi

Pastikan apakah waktu tunggu berasal dari pembuatan HTML dinamis atau transfer jaringan, apakah permintaan tersebut merupakan navigasi tingkat atas, apakah klien dan proksi menangani 1xx dengan andal, apakah URL sumber daya, versi, dan nilai as bersifat stabil, serta apakah sumber daya dapat di-cache. Jika respons final dapat dikirim secara instan, header Link biasa atau elemen link HTML lebih sederhana. Jika sumber daya bervariasi berdasarkan autentikasi, pengalihan (redirect), atau personalisasi, petunjuk awal yang salah dapat memakan biaya lebih besar daripada penghematannya.

Kerangka jawaban 30 detik

103 adalah petunjuk sebelum respons final, bukan hasil halaman. Saat membuat HTML, origin dapat mengirim 103 dengan Link: rel=preload atau preconnect sehingga klien menyiapkan sumber daya secara paralel; respons 200 final tetap menyediakan header otoritatif. Aktifkan hanya jika waktu berpikir server cukup signifikan, prediksi stabil, dan HTTP/2 atau HTTP/3 dapat diandalkan. Ukur penggunaan cache, unduhan duplikat, LCP, error, dan bandwidth, dengan fallback respons final normal untuk klien yang lebih lama.

Pembahasan mendalam langkah demi langkah

1. Temukan jendela optimasi. Ukur waktu tunggu antara penerimaan permintaan dan tersedianya HTML final. Jika origin mengembalikan 200 dengan cepat, 103 tidak memiliki celah waktu yang berguna; pertahankan preload biasa pada respons final.
2. Definisikan semantik 103. 103 menyatakan bahwa respons final kemungkinan akan menyertakan field-field ini. Klien dapat melakukan persiapan spekulatif, namun petunjuk tersebut tidak dapat menggantikan atau mengubah semantik respons final.
3. Pilih konten petunjuk. Utamakan CSS, skrip, atau origin koneksi yang stabil, kritis, dan dapat di-cache. Versi sumber daya, tipe media, dan kredensial cross-origin harus cocok dengan respons final; jangan memberikan petunjuk untuk aset terpersonalisasi yang tidak pasti.
4. Batasi protokol dan klien. Utamakan HTTP/2 atau HTTP/3 dan verifikasi bahwa proksi, browser, dan jalur observabilitas menangani 1xx dengan benar. Nonaktifkan atau turunkan (downgrade) untuk klien HTTP/1.1 lama yang mungkin memperlakukan 103 sebagai respons final.
5. Tangani respons final. Status akhir 200/3xx/4xx menentukan hasil halaman. Jika petunjuk 103 menjadi salah, klien akan mengikuti respons final; perantara tidak boleh menyimpan petunjuk tersebut dalam cache sebagai objek final.
6. Ukur nilai dan biaya. Bandingkan LCP first-view, hit sumber daya, unduhan duplikat, bandwidth, dan error sebelum dan sesudah penerapan. Jika pengalihan, caching yang dinonaktifkan, atau varian sumber daya menyia-nyiakan preload, persempit cakupan halaman atau hapus 103.

Contoh jawaban model

Saya tidak akan mengaktifkan 103 di semua tempat hanya karena terdengar lebih cepat. Pertama, saya akan memverifikasi adanya waktu pembuatan HTML dinamis yang signifikan dan navigasi tingkat atas. Jika URL CSS dan skrip kritis, versi, as, dan perilaku cache bersifat stabil, saya akan mengirim petunjuk melalui HTTP/2 atau HTTP/3:

HTTP/2 103 Early Hints
Link: </style.abc.css>; rel=preload; as=style
Link: </app.abc.js>; rel=preload; as=script

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.abc.css>; rel=preload; as=style

Respons final tetap bersifat otoritatif; 103 tidak menjamin bahwa suatu sumber daya akan digunakan. Untuk klien lama, proksi yang tidak andal, atau halaman di mana pengalihan dan personalisasi mengubah sumber daya, saya beralih kembali ke header Link normal pada respons final. Saya akan menjalankan eksperimen yang mengukur waktu tunggu server, LCP, hit cache, unduhan duplikat, bandwidth, dan 4xx/5xx. Jika petunjuk tidak menutupi jeda waktu yang nyata, saya akan menghapus 103.

Kesalahan umum

• Memperlakukan 103 sebagai status final → klien mungkin mengira halaman berhasil dimuat → jelaskan bahwa respons final yang menentukan hasilnya.
• Menyalin setiap sumber daya HTML ke dalam 103 → aset yang dipersonalisasi atau tidak dapat di-cache akan diunduh dua kali → berikan petunjuk hanya untuk sumber daya kritis yang stabil.
• Mengabaikan kompatibilitas protokol dan proksi → klien lama mungkin salah mengurai 1xx → utamakan HTTP/2/3 dan sediakan fallback.
• Hanya mengukur LCP → bandwidth preload yang terbuang dapat menyembunyikan peningkatan lokal → pantau juga permintaan duplikat, cache, dan error.
• Menghilangkan header final otoritatif → petunjuk bukanlah metadata final → ulangi field Link yang diperlukan pada respons final.

Pertanyaan lanjutan

Apa perbedaan 103 dengan HTTP/2 Server Push?

103 membiarkan klien memutuskan apakah akan mengambil (fetch) sumber daya; Server Push mengirimkan sumber daya secara proaktif dan dapat mengirimkan aset yang sudah disimpan dalam cache klien. Saat status cache tidak pasti, 103 mempermudah penghindaran transfer yang tidak perlu.

Bagaimana jika respons final dialihkan ke lintas-origin (cross-origin)?

Koneksi atau sumber daya yang dimulai lebih awal mungkin akan dibuang, sehingga mengubah petunjuk tersebut menjadi biaya bandwidth dan koneksi tambahan. Aktifkan hanya untuk titik masuk (entry points) yang stabil dan sertakan tingkat pengalihan dalam eksperimen.

Bagaimana Anda menangani versi aset yang dinamis?

Gunakan URL dengan content-hash yang sudah diketahui, atau berikan petunjuk hanya untuk versi yang dijamin cocok dengan respons final. Jika versinya tidak diketahui, tunggu HTML final daripada menebak.

Mengapa tidak mengirim 103 di setiap halaman?

Tanpa adanya waktu berpikir server, tidak ada pekerjaan paralel yang dapat dimanfaatkan, dan navigasi yang lebih dalam mungkin sudah menyimpan aset kritis di cache. Terapkan secara bertahap berdasarkan halaman masuk, protokol, perilaku cache, dan nilai yang terukur.