HTTP 103 Early Hints — Biarkan Browser Bekerja Saat Server Berpikir

Browser meminta sebuah dokumen, tetapi server mungkin membutuhkan waktu sebelum tahu apa yang harus dikirim. Server dapat perlu menjalankan query database, menunggu layanan upstream, atau merender halaman melalui aplikasi PHP. Selama itu, koneksi terlihat menganggur meski server sebenarnya sedang bekerja. Apakah ada cara aman untuk memberi browser pekerjaan yang berguna sebelum respons akhir siap?

HTTP 103 Early Hints adalah salah satu jawabannya. Server dapat mengirim respons pendahuluan berisi petunjuk tentang resource yang kemungkinan dibutuhkan. Browser mungkin memakai petunjuk itu untuk memulai koneksi atau mengambil stylesheet sambil menunggu respons akhir. Kata pentingnya adalah pendahuluan dan kemungkinan: 103 bukan dokumen, dan bukan janji bahwa resource tersebut pasti dipakai.

Celah Sebelum Respons Akhir

Bayangkan permintaan dokumen yang lambat. Browser mengirim GET /dashboard. Aplikasi kemudian melakukan beberapa pekerjaan sebelum dapat menghasilkan HTML. Jika stylesheet dan script penting sudah diketahui, menunggu sampai respons akhir untuk menyebutkannya berarti sebagian waktu terbuang.

Dengan Early Hints, urutannya kurang lebih menjadi seperti ini:

GET /dashboard
Host: example.com

HTTP/2 103 Early Hints
Link: </assets/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200 OK
Content-Type: text/html
Link: </assets/app.css>; rel=preload; as=style

<!doctype html>
...

Respons 103 memberi tahu client apa yang kemungkinan akan dikirim server berikutnya. Respons akhir tetap harus datang, dan header-nya tetap memiliki otoritas. Menurut RFC 8297, client dapat mengevaluasi field awal secara spekulatif, tetapi evaluasi itu tidak boleh mengubah cara client memproses respons akhir.

Apa yang Dapat Dilakukan Browser?

Petunjuk yang biasanya paling berguna adalah field Link. Dengan rel=preload, server dapat menunjukkan resource penting untuk halaman awal dan menyertakan jenis tujuannya melalui as. Dengan rel=preconnect, server dapat menyarankan browser menyiapkan koneksi ke origin lain.

Semua itu tetap berupa petunjuk. Browser dapat memutuskan bahwa resource sudah ada di cache, tidak didukung, tidak aman diambil dalam situasi tersebut, atau tidak lagi relevan setelah redirect. Referensi MDN untuk 103 juga menjelaskan bahwa browser memiliki batas kompatibilitas dan dapat membuang pekerjaan awal ketika navigasi akhirnya berpindah ke origin lain.

Inilah perbedaan Early Hints dari menaruh link stylesheet di HTML akhir. Link HTML baru ditemukan setelah dokumen tiba. Link 103 dapat ditemukan lebih awal, ketika server masih menyiapkan respons. Early Hints juga berbeda dari HTTP/2 server push: Early Hints menyarankan pekerjaan dan membiarkan browser mengendalikan pengambilan resource, sedangkan server push mengirim byte meskipun browser mungkin sudah memiliki resource tersebut.

Kapan Layak Dipertimbangkan?

Early Hints tidak otomatis berguna untuk setiap halaman. Jika aplikasi dapat mengirim respons akhir dengan segera, header Link biasa atau elemen HTML <link> mungkin sudah cukup. Panduan implementasi Google Chrome menjelaskan Early Hints sebagai cara memanfaatkan waktu berpikir server, bukan pengganti penemuan resource dasar.

Kandidat yang masuk akal biasanya memiliki tiga sifat:

• Dibutuhkan pada halaman masuk yang penting, seperti homepage atau landing page yang sering dikunjungi.
• Cukup stabil sehingga server dapat memprediksi URL-nya sebelum dokumen dibuat.
• Dapat di-cache dan benar-benar digunakan halaman akhir.

Asset dengan hash yang berubah pada setiap deployment bisa menjadi kandidat buruk jika hint dan HTML yang dihasilkan dapat berbeda. Resource yang jarang digunakan hanya akan memakai bandwidth lebih awal. Dokumentasi Chrome secara khusus memperingatkan bahwa resource non-cacheable dapat diambil dua kali: sekali karena Early Hints dan sekali lagi ketika dokumen menemukannya.

Karena itu, langkah pertama bukan menambahkan header ke semua tempat. Cari navigasi yang lambat, periksa resource yang terlambat ditemukan, lalu bandingkan perubahan terkontrol dengan baseline. Tanpa pengukuran itu, “lebih cepat” baru merupakan asumsi.

Pola Proxy NGINX yang Konservatif

NGINX mendokumentasikan directive early_hints pada core HTTP module. Directive ini hadir mulai NGINX 1.29.0 dan mengatur kapan respons 103 dari upstream diteruskan ke client. Contoh NGINX membatasi respons itu untuk HTTP/2 atau HTTP/3:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://application_backend;
    }
}

Contoh ini tidak membuat respons 103 dengan sendirinya. Aplikasi upstream harus mengirim respons informasional dan field Link-nya. NGINX kemudian meneruskan respons 103 dari upstream apa adanya ketika kondisinya benar. Dokumentasi resmi NGINX adalah rujukan untuk sintaks dan kebutuhan versinya.

Pemeriksaan navigate dilakukan dengan sengaja. Pemeriksaan itu mencegah setiap permintaan image, script, atau API diperlakukan seperti navigasi dokumen. Ekspresi $http2$http3 juga menjaga contoh ini agar tidak mengirim Early Hints ke client HTTP/1.1, kecuali server memiliki alasan dan bukti bahwa client tersebut dapat menangani respons informasional dengan benar.

Mengapa Respons Akhir Tetap Penting?

Mengulang header Link dalam respons akhir mungkin tampak berlebihan, tetapi kedua respons memiliki tugas berbeda. Respons awal memberi client kesempatan memulai pekerjaan. Respons akhir menjelaskan representasi yang sebenarnya. Jika aplikasi berubah pikiran, respons akhir dapat menghapus atau mengganti hint.

HTML Living Standard menjelaskan Early Hints sebagai bagian dari model pemrosesan link browser. Itu tidak menjadikan preload sebagai jaminan. Preload tetap membutuhkan metadata tujuan yang benar, cache yang sesuai, dan halaman akhir yang memakai resource tersebut. Browser juga dapat membatasi hint yang diproses. MDN saat ini menyarankan pengiriman 103 melalui HTTP/2 atau yang lebih baru, kecuali server mengetahui bahwa client-nya aman menangani respons informasional.

Batasan dan Mode Kegagalan

Ada beberapa alasan untuk berhati-hati:

• Ini bersifat spekulatif. Hint yang salah memakai koneksi dan bandwidth sebelum server membuktikan resource itu dibutuhkan.
• Ini bukan pengganti otorisasi atau header respons. Respons akhir tetap menjadi sumber kebenaran.
• Protokol dan dukungan browser penting. RFC 8297 memperingatkan tentang client yang salah menangani respons informasional, terutama melalui HTTP/1.1.
• Redirect dapat membatalkan pekerjaan. Navigasi lintas origin dapat membuat browser membuang resource yang diperoleh dari respons awal.
• Fitur ini membutuhkan waktu berpikir server. Jika tidak ada jeda berarti sebelum respons akhir, preload atau preconnect biasa lebih sederhana.

Batasan itu bukan alasan untuk menolak fiturnya. Ini pengingat bahwa Early Hints adalah lapisan optimisasi. Fitur tersebut sebaiknya diperkenalkan setelah resource graph, caching, negosiasi protokol, dan pengukuran halaman dipahami.

Kesimpulan

HTTP 103 Early Hints memberi server kosakata kecil di tengah proses: “selagi aku menyiapkan jawaban, resource ini kemungkinan penting.” Browser boleh memakai waktu itu untuk melakukan koneksi atau preload, tetapi tetap bebas mengabaikan hint. Respons akhir tetap menentukan isi halaman dan header yang berlaku.

Untuk aplikasi PHP di belakang NGINX, awal yang paling masuk akal adalah tetap sempit: pilih navigasi yang lambat, hint hanya resource yang stabil dan cacheable, pertahankan hint di respons akhir, lalu batasi penerusan untuk client dan protokol yang dapat menanganinya. Jika hasil pengukurannya tidak lebih baik, tidak ada masalah untuk menghapus optimisasi tersebut. Respons yang lebih kecil dan dapat diprediksi sering kali lebih baik daripada hint cerdas yang salah menebak.

References

1. RFC 8297: An HTTP Status Code for Indicating Hints, Kazuho Oku, IETF, December 2017.
2. 103 Early Hints, MDN Web Docs, modified June 22, 2026.
3. 103 Early Hints, Kenji Baheux and Barry Pollard, Chrome for Developers, published June 23, 2022, updated July 10, 2026.
4. Module ngx_http_core_module: early_hints, NGINX documentation.
5. HTML Living Standard: Early hints, WHATWG, updated November 9, 2026.