Pemuatan halaman yang lebih cepat menggunakan waktu berpikir server dengan Petunjuk Awal

Pelajari cara server Anda dapat mengirimkan petunjuk ke browser tentang subresource penting.

Kenji Baheux

Barry Pollard

Dipublikasikan: 23 Juni 2022, Terakhir diperbarui: 10 Juli 2026

Apa yang dimaksud dengan Early Hints?

Situs web menjadi lebih canggih dari waktu ke waktu. Oleh karena itu, server biasanya perlu melakukan pekerjaan yang tidak sepele (misalnya, akses ke database, atau CDN yang mengakses server asal) untuk menghasilkan HTML bagi halaman yang diminta. Sayangnya, "waktu berpikir server" ini menyebabkan latensi tambahan sebelum browser dapat mulai merender halaman. Memang, koneksi akan tidak aktif selama server memerlukan waktu untuk menyiapkan respons.

Early Hints adalah kode status HTTP (103 Early Hints) yang digunakan untuk mengirim respons HTTP awal sebelum respons akhir. Hal ini memungkinkan server mengirimkan petunjuk ke browser tentang subresource penting (misalnya, stylesheet untuk halaman, JavaScript penting) atau asal yang kemungkinan akan digunakan oleh halaman, saat server sibuk membuat resource utama. Browser dapat menggunakan petunjuk tersebut untuk menghidupkan koneksi, dan meminta subresource, sambil menunggu resource utama. Dengan kata lain, Early Hints membantu browser memanfaatkan "waktu berpikir server" tersebut dengan melakukan beberapa pekerjaan terlebih dahulu, sehingga mempercepat pemuatan halaman.

Dalam beberapa kasus, peningkatan performa Largest Contentful Paint dapat berkisar dari beberapa ratus milidetik, seperti yang diamati oleh Shopify dan oleh Cloudflare, dan hingga satu detik lebih cepat, seperti yang terlihat dalam perbandingan sebelum dan sesudah berikut:

Cara menggunakan Early Hints

Langkah pertama untuk memanfaatkan Early Hints adalah mengidentifikasi halaman landing teratas, yaitu halaman tempat pengguna biasanya memulai saat mengunjungi situs web Anda. Halaman ini dapat berupa halaman beranda, atau halaman listing produk populer jika Anda memiliki banyak pengguna yang berasal dari situs web lain. Alasan mengapa titik entri ini lebih penting daripada halaman lain adalah karena kegunaan Early Hints menurun saat pengguna menjelajahi situs web Anda (yaitu, browser lebih cenderung memiliki semua subresource yang diperlukan pada navigasi berikutnya yang kedua atau ketiga). Sebaiknya selalu berikan kesan pertama yang baik.

Setelah memiliki daftar halaman landing yang diprioritaskan ini, langkah berikutnya adalah mengidentifikasi asal atau subresource mana yang akan menjadi kandidat yang baik untuk preconnect atau preload petunjuk. Biasanya, asal dan subresource tersebut akan memberikan kontribusi terbesar pada metrik pengguna utama seperti Largest Contentful Paint, atau First Contentful Paint. Secara lebih konkret, cari subresource yang memblokir rendering seperti JavaScript sinkron, stylesheet, atau bahkan font web. Demikian pula, cari asal yang menghosting subresource yang memberikan kontribusi besar pada metrik pengguna utama.

Perhatikan juga bahwa jika resource utama Anda sudah menggunakan preconnect atau preload, Anda dapat mempertimbangkan asal atau resource ini di antara kandidat untuk Early Hints. Lihat cara mengoptimalkan LCP untuk mengetahui detail selengkapnya. Namun, menyalin petunjuk preconnect dan preload dari HTML ke Early Hints mungkin tidak optimal.

Saat menggunakannya di HTML, Anda biasanya ingin preconnect atau preload resource yang tidak akan ditemukan oleh Pemindai Preload di HTML—misalnya, font, atau gambar latar belakang yang akan ditemukan terlambat. Untuk Early Hints, Anda tidak akan memiliki HTML sehingga Anda mungkin ingin preconnect ke domain penting atau preload resource penting yang mungkin akan ditemukan lebih awal di HTML—misalnya, memuat main.css atau app.js terlebih dahulu.Selain itu, tidak semua browser mendukung preload untuk Early Hints—lihat Dukungan Browser.

Langkah kedua adalah meminimalkan risiko penggunaan Early Hints pada resource atau asal yang mungkin sudah tidak digunakan, atau tidak lagi digunakan oleh resource utama. Misalnya, resource yang sering diperbarui dan diberi versi (misalnya, example.com/css/main.fa231e9c.css) mungkin bukan pilihan terbaik. Perhatikan bahwa masalah ini tidak khusus untuk Early Hints, tetapi berlaku untuk preload atau preconnect apa pun yang mungkin ada. Detail semacam ini paling baik ditangani dengan otomatisasi atau pembuatan template (misalnya, proses manual lebih cenderung menyebabkan URL hash atau versi yang tidak cocok antara preload dan tag HTML sebenarnya yang menggunakan resource).

Sebagai contoh, pertimbangkan alur berikut:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

Server memprediksi bahwa main.abcd100.css akan diperlukan, dan menyarankan untuk memuatnya terlebih dahulu menggunakan Early Hints:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Beberapa saat kemudian, halaman web, termasuk CSS tertaut, ditayangkan. Sayangnya, resource CSS ini sering diperbarui, dan resource utama sudah lima versi lebih baru (abcd105) dari resource CSS yang diprediksi (abcd100).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

Secara umum, targetkan resource dan asal yang cukup stabil, dan sebagian besar independen dari hasil untuk resource utama. Jika perlu, Anda dapat mempertimbangkan untuk membagi resource utama menjadi dua: bagian stabil yang dirancang untuk digunakan dengan Early Hints, dan bagian yang lebih dinamis yang akan diambil setelah resource utama diterima oleh browser:

<html>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Terakhir, di sisi server, cari permintaan resource utama yang dikirim oleh browser yang diketahui mendukung Early Hints, dan segera respons dengan 103 Early Hints. Dalam respons 103, sertakan petunjuk preconnect dan preload yang relevan. Setelah resource utama siap, tindak lanjuti dengan respons biasa (misalnya, 200 OK jika berhasil). Untuk kompatibilitas mundur, sebaiknya sertakan juga header HTTP Link dalam respons akhir, bahkan mungkin ditambah dengan resource penting yang menjadi jelas sebagai bagian dari pembuatan resource utama (misalnya, bagian dinamis dari resource utama jika Anda mengikuti saran "bagi menjadi dua"). Berikut tampilannya:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Beberapa saat kemudian:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Dukungan browser

Meskipun 103 Early Hints didukung di semua browser utama, petunjuk yang dapat dikirim di Early Hint berbeda-beda per browser:

Dukungan preconnect:

Dukungan preload:

Chrome DevTools juga memiliki dukungan 103 Early Hints dan header Link dapat dilihat di resource dokumen:

Catatan: Untuk menggunakan resource Early Hints, Disable cache tidak boleh dicentang di DevTools karena Early Hints menggunakan cache browser. Untuk resource yang dimuat terlebih dahulu, Initiator akan ditampilkan sebagai Early-hints dan Size sebagai (Disk cache):

Hal ini juga memerlukan sertifikat tepercaya untuk pengujian HTTPS.

Firefox tidak memiliki dukungan 103 Early Hints eksplisit sebagai inisiator di DevTools, tetapi resource yang dimuat menggunakan Early Hints ditampilkan sebagai cached di kolom Transferred dan, saat diklik, memiliki header permintaan HTTP X-Moz: early hint.

Dukungan server

Berikut ringkasan singkat tingkat dukungan untuk Early Hints di antara perangkat lunak server HTTP open source populer:

• Apache: didukung menggunakan mod_http2.
• H2O: didukung.
• NGINX: didukung.
• Node: didukung untuk http dan http2

Mengaktifkan Early Hints dengan cara yang lebih mudah

Jika Anda menggunakan salah satu CDN atau platform berikut, Anda mungkin tidak perlu menerapkan Early Hints secara manual. Lihat dokumentasi online penyedia solusi Anda untuk mengetahui apakah solusi tersebut mendukung Early Hints, atau lihat daftar yang tidak lengkap di sini:

• Early Hints di Cloudflare
• Early Hints di Fastly.
• Early Hints di Akamai.

Cara menghindari masalah untuk klien yang tidak mendukung Early Hints

Respons HTTP informasi dalam rentang 100 adalah bagian dari standar HTTP, tetapi beberapa klien atau bot lama mungkin mengalami kesulitan dengan respons ini karena sebelum peluncuran 103 Early Hints, respons ini jarang digunakan untuk penjelajahan web umum.

Hanya mengirim 103 Early Hints sebagai respons terhadap klien yang mengirim header permintaan HTTP sec-fetch-mode: navigate hanya akan mengirim petunjuk tersebut untuk klien yang lebih baru yang memahami untuk menunggu respons berikutnya. Selain itu, karena Early Hints hanya didukung pada permintaan navigasi (lihat batasan saat ini), hal ini memiliki manfaat tambahan untuk menghindari pengiriman yang tidak perlu pada permintaan lainnya.

Selain itu, Early Hints direkomendasikan untuk hanya dikirim melalui koneksi HTTP/2 atau HTTP/3 dan sebagian besar browser hanya akan menerimanya melalui protokol tersebut.

Pola lanjutan

Jika Anda telah menerapkan Early Hints sepenuhnya ke halaman landing utama dan mencari peluang lainnya, Anda mungkin tertarik dengan pola lanjutan berikut.

Untuk pengunjung yang berada di permintaan halaman ke-n sebagai bagian dari perjalanan pengguna yang umum, Anda mungkin ingin menyesuaikan respons Early Hints dengan konten yang lebih rendah dan lebih dalam di halaman, dengan kata lain menggunakan Early Hints pada resource dengan prioritas lebih rendah. Hal ini mungkin terdengar tidak intuitif mengingat kami merekomendasikan untuk berfokus pada subresource atau asal yang memblokir rendering dan memiliki prioritas tinggi. Namun, saat pengunjung telah menjelajah selama beberapa waktu, kemungkinan besar browser mereka sudah memiliki semua resource penting. Mulai saat itu, sebaiknya alihkan perhatian Anda ke resource dengan prioritas lebih rendah. Misalnya, hal ini dapat berarti menggunakan Early Hints untuk memuat gambar produk, atau JS/CSS tambahan yang hanya diperlukan untuk interaksi pengguna yang kurang umum.

Batasan saat ini

Berikut batasan Early Hints seperti yang diterapkan di Chrome:

• Hanya tersedia untuk permintaan navigasi (yaitu, resource utama untuk dokumen tingkat atas).
• Hanya mendukung preconnect dan preload (yaitu, prefetch tidak didukung).
• Early Hints yang diikuti oleh pengalihan lintas origin pada respons akhir akan menyebabkan browser menghapus resource dan koneksi yang diperoleh menggunakan Early Hints.
• Resource yang dimuat terlebih dahulu menggunakan Early Hints disimpan dalam cache HTTP dan diambil dari sana oleh halaman nanti. Oleh karena itu, hanya resource yang dapat di-cache yang dapat dimuat terlebih dahulu menggunakan Early Hints atau resource akan diambil dua kali (sekali oleh Early Hints dan sekali lagi oleh dokumen). Di Chrome, cache HTTP dinonaktifkan untuk sertifikat HTTPS yang tidak tepercaya (meskipun Anda melanjutkan untuk memuat halaman).
• Memuat gambar responsif terlebih dahulu (menggunakan imagesrcset, imagesizes atau media) mungkin tidak didukung menggunakan header HTTP <link> karena viewport tidak ditentukan hingga dokumen dibuat. Paling baik, mereka akan menunggu hingga dokumen diterima, sehingga meniadakan manfaat utama 103 Early Hints.

Browser lain memiliki batasan serupa dan, seperti yang disebutkan sebelumnya, beberapa browser lebih lanjut membatasi 103 early hints hanya untuk preconnect saja.

Hubungan dengan H2/Push

Jika Anda memahami fitur HTTP2/Push yang tidak digunakan lagi, Anda mungkin bertanya-tanya bagaimana Early Hints berbeda. Meskipun Early Hints memerlukan perjalanan pulang pergi agar browser dapat mulai mengambil subresource penting, dengan HTTP2/Push, server dapat mulai mengirim subresource bersama dengan respons. Meskipun terdengar luar biasa, hal ini menyebabkan kelemahan struktural utama: dengan HTTP2/Push, sangat sulit untuk menghindari pengiriman subresource yang sudah dimiliki browser. Efek "pengiriman berlebihan" ini menyebabkan penggunaan bandwidth jaringan yang kurang efisien, yang secara signifikan menghambat manfaat performa. Secara keseluruhan, data Chrome menunjukkan bahwa HTTP2/Push sebenarnya merupakan hal yang negatif bagi performa di seluruh web.

Sebaliknya, Early Hints berkinerja lebih baik dalam praktiknya karena menggabungkan kemampuan untuk mengirim respons awal dengan petunjuk yang membuat browser bertanggung jawab untuk mengambil, atau terhubung ke, apa yang sebenarnya dibutuhkan. Meskipun Early Hints tidak mencakup semua kasus penggunaan yang secara teori dapat ditangani oleh HTTP2/Push, kami yakin bahwa Early Hints adalah solusi yang lebih praktis untuk mempercepat navigasi.

Gambar thumbnail oleh Pierre Bamin.