Wawancara Frontend: Kapan HTTP 103 Early Hints Benar-benar Meningkatkan LCP?

Konteks dan arahan

Anda mengelola halaman beranda e-commerce yang HTML di bagian above-the-fold membutuhkan waktu untuk di-generate. Usulannya adalah mengirim 103 Early Hints sebelum respons akhir sehingga browser dapat mulai memuat CSS, font, atau skrip penting. Jelaskan kapan hal ini membantu, cara menghindari unduhan duplikat, dan cara memverifikasi perubahan LCP. Asumsikan navigasi tingkat atas melalui HTTP/2 atau HTTP/3, dengan header Link yang benar tetap dikirimkan pada respons akhir.

Hal yang diuji oleh pewawancara

Apakah Anda mendeskripsikan 103 sebagai petunjuk (hint) alih-alih daftar sumber daya yang otoritatif: browser dapat menghubungkan atau melakukan preload, sementara respons akhir tetap bersifat otoritatif.
Apakah Anda mengidentifikasi server think-time sebagai jendela tumpang tindih (overlap window); ketika server dapat segera mengembalikan status 200, penggunaan preload atau preconnect biasa pada respons utama lebih sederhana.
Apakah Anda mencakup stabilitas sumber daya, caching, pengalihan lintas asal (cross-origin redirect), dukungan browser, dan persyaratan protokol.
Apakah Anda memvalidasi dengan LCP, penggunaan ulang cache, permintaan duplikat, dan error alih-alih sekadar menyebutkan kode status.

Pertanyaan klarifikasi sebelum menjawab

Berapa lama waktu server sebelum byte pertama? Jika mendekati nol, hanya ada sedikit tumpang tindih yang bisa dimanfaatkan; optimalkan backend atau hint pada respons utama terlebih dahulu.
Apakah sumber daya yang di-hint bersifat stabil dan penting? Sumber daya yang bergantung pada pengguna, eksperimen, atau izin dapat terbuang sia-sia jika ditebak terlalu dini.
Apakah ini navigasi tingkat atas melalui HTTP/2+? Penanganan browser berpusat pada navigasi, dan MDN merekomendasikan HTTP/2 atau yang lebih baru.
Apakah sumber daya dapat di-cache (cacheable)? Preload yang tidak dapat di-cache dapat diunduh kembali setelah HTML tiba, mengubah hint menjadi pekerjaan tambahan.

Kerangka jawaban 30 detik

“Pertama, saya memverifikasi bahwa halaman memiliki server think-time yang signifikan dan ini adalah navigasi di mana klien mendukung 103. Kemudian, saya hanya memberikan hint untuk CSS, font, atau asal koneksi yang stabil dan dapat di-cache, serta mengulangi header Link yang benar pada respons akhir. Saya menghindari hint untuk sumber daya yang bergantung pada eksperimen atau izin. Sebelum dan sesudah peluncuran, saya membandingkan tumpang tindih antara TTFB dan permintaan sumber daya, LCP, byte duplikat, serta error; klien yang tidak mendukung 103 akan menggunakan jalur respons normal.”

Jawaban mendalam langkah demi langkah

1. Kuantifikasi jendela tumpang tindih

103 memungkinkan browser terhubung atau mengambil sumber daya sementara server menyiapkan HTML akhir. Batas atas yang berguna kira-kira adalah waktu persiapan server dikurangi waktu di mana browser seharusnya menemukan sumber daya tersebut setelah respons akhir. Jika server mengembalikan 200 dengan cepat, jendela tersebut hampir nol; dalam kasus tersebut Chrome merekomendasikan Link reguler atau link pada HTML.

2. Pilih sumber daya yang stabil alih-alih menyalin setiap hint HTML

Early Hints tiba sebelum HTML akhir dan varian spesifik pengguna diketahui. Kandidat yang baik mencakup CSS bersama, skrip umum, font, dan koneksi CDN penting. Gambar yang dipersonalisasi, cabang eksperimen, dan sumber daya dengan batasan izin harus menunggu HTML. Pisahkan sumber daya menjadi bagian yang stabil untuk hint dan bagian dinamis untuk respons akhir jika hal itu praktis.

3. Perlakukan cache dan protokol sebagai syarat kebenaran

Halaman akhir harus menggunakan kembali sumber daya yang telah di-preload. Jika tidak dapat di-cache, browser dapat mengunduhnya sekali dari hint dan mengunduhnya lagi setelah mengurai HTML. Font lintas asal juga memerlukan semantik crossorigin yang cocok. MDN merekomendasikan pengiriman 103 melalui HTTP/2 atau lebih baru karena klien lama dan perantara mungkin salah menangani respons 1xx.

4. Pertahankan respons akhir sebagai respons yang otoritatif

Tetap kirimkan header Link dalam respons akhir untuk klien yang mengabaikan 103 dan untuk sumber daya yang baru diketahui saat merender HTML. Pengalihan lintas asal dapat menyebabkan browser membuang koneksi dan sumber daya awal, jadi 103 bukanlah perintah unduh yang tidak dapat dibatalkan.

5. Ukur eksperimen nyata

Lakukan pengacakan navigasi nyata dengan dan tanpa Early Hints. Catat server think-time, waktu mulai permintaan sumber daya, LCP, byte duplikat, dan tingkat error. Chrome DevTools menampilkan inisiator Early Hints dan penggunaan ulang cache, tetapi cache harus tetap aktif selama pengujian. Jika LCP tidak membaik, periksa apakah sumber daya sudah ada di cache, hint tiba terlambat, pengalihan membuangnya, atau waktu server bukan merupakan kendala utama (bottleneck).

6. Kontraskan dengan HTTP/2 Push

103 memberikan petunjuk dan membiarkan browser memegang kendali atas pengambilan sumber daya; HTTP/2 Push secara aktif mengirimkan sumber daya dan sering kali menduplikasi item yang sudah di-cache oleh browser. Komprominya adalah Early Hints masih memerlukan round trip dan bergantung pada dukungan browser, tetapi tidak mengambil kendali dari klien.

Contoh jawaban berkualitas tinggi

Saya akan mulai dengan waktu sebelum byte pertama. Jika SSR membutuhkan 300 milidetik dan CSS utama serta font stabil di setiap navigasi, 103 dapat menumpangkan koneksi dan pengunduhannya dengan 300 milidetik tersebut. Saya hanya akan memberikan hint untuk sumber daya stabil yang dapat di-cache, menyertakan crossorigin yang tepat untuk font lintas asal, dan menyerahkan gambar yang dipersonalisasi serta skrip eksperimen ke respons akhir. Respons akhir akan tetap menyertakan Link sehingga klien yang tidak mendukung memiliki fallback normal.

Saya tidak akan mengklaim bahwa menambahkan kode status menjamin kemenangan. Saya akan menjalankan eksperimen navigasi terkontrol dan membandingkan LCP, waktu mulai permintaan, byte duplikat, dan tingkat pengalihan lintas asal. Jika server sudah mengembalikan 200 dengan cepat, sumber daya ada di cache, atau halaman akhir sering menolak hint tersebut, hint respons utama reguler—atau tanpa preload—jauh lebih aman. Jawaban tersebut memaparkan jendela manfaat, biaya tebakan yang salah, dan mekanismenya sebagai fallback.

Kesalahan umum

Kesalahan → Memperlakukan 103 setara dengan 200. Mengapa gagal: 103 bersifat informasi (informational); respons akhir menentukan hasil dan sumber daya. Perbaikan: sampaikan bahwa hint dapat diabaikan dan pertahankan header Link akhir.
Kesalahan → Menyalin setiap preload HTML ke dalam 103. Mengapa gagal: varian pengguna tidak diketahui saat hint dikirim, sehingga sumber daya dinamis membuang bandwidth. Perbaikan: pilih hanya sumber daya yang stabil dan berprobabilitas tinggi.
Kesalahan → Hanya mengukur LCP. Mengapa gagal: preload yang tidak dapat di-cache atau atribut cross-origin yang salah dapat mulai lebih awal namun meningkatkan total byte. Perbaikan: ukur juga penggunaan ulang cache, permintaan duplikat, bandwidth, dan error.
Kesalahan → Mengirimkannya ke setiap permintaan HTTP/1.1. Mengapa gagal: penanganan 1xx bervariasi dan Early Hints menargetkan navigasi. Perbaikan: batasi berdasarkan protokol, jenis permintaan, dan kemampuan klien, dengan fallback respons normal.

Pertanyaan lanjutan dan jawabannya

Respons akhir sering kali dialihkan ke asal yang lain. Apakah Anda masih akan mengirim 103?

Hanya dengan hati-hati. Panduan MDN dan Chrome mencatat bahwa pengalihan lintas asal dapat membuat browser membuang koneksi dan sumber daya awal. Batasi hint pada titik masuk akhir yang stabil atau sumber daya same-origin yang bertahan dari pengalihan, dan tetapkan ambang batas tingkat pengalihan.

CSS berbeda di antara grup eksperimen. Apa yang bisa Anda berikan sebagai hint?

Hanya berikan hint untuk CSS yang digunakan bersama oleh setiap grup; serahkan chunk khusus eksperimen ke HTML akhir. Jika tidak ada irisan yang stabil, jangan lakukan preload. Biaya bandwidth dari tebakan yang salah dapat melebihi waktu tunggu yang dihemat.

Bagaimana Anda membuktikan bahwa peningkatan berasal dari 103 dan bukan dari cache yang sudah hangat (warmed cache)?

Acak grup dengan kondisi cache yang sesuai dan laporkan cold cache dan warm cache secara terpisah. Ukur tumpang tindih antara permintaan sumber daya dan server think-time, bukan hanya satu nilai LCP; periksa inisiator Early Hints, cache hit, dan unduhan duplikat.

Bagaimana jika browser tidak mendukung direktif Early Hints tertentu?

Pertahankan Link akhir dan deklarasi HTML sebagai fallback. Mulai dengan preconnect yang didukung secara luas, luncurkan preload sesuai dengan matriks browser target, dan pantau error.