Kecepatan adalah salah satu faktor terpenting dalam pengalaman pengguna di web. Ketika pengunjung mengeklik sebuah tautan, keterlambatan beberapa ratus milidetik saja dapat membuat situs terasa kurang responsif. Masalah ini semakin terasa pada halaman yang harus mengunduh banyak aset, mengeksekusi JavaScript, mengambil data, dan menyusun tampilan sebelum dapat digunakan.
Selama bertahun-tahun, developer mengatasinya dengan mengoptimalkan gambar, memperkecil ukuran JavaScript, menggunakan CDN, menerapkan caching, dan memperbaiki Critical Rendering Path. Semua teknik tersebut tetap penting, tetapi pada dasarnya baru bekerja ketika browser mulai membuka halaman tujuan.
Speculation Rules API menawarkan pendekatan berbeda: browser diberi petunjuk mengenai halaman yang kemungkinan akan dibuka berikutnya. Sebelum pengguna mengeklik tautan, browser dapat terlebih dahulu mengambil dokumennya melalui prefetch atau bahkan memuat dan merender seluruh halaman melalui prerender.
Hasil akhirnya adalah navigasi yang dapat terasa seolah-olah selesai dalam “0 detik”.
Namun, istilah tersebut harus dipahami secara tepat. Speculation Rules API tidak menjamin waktu pemuatan selalu tepat 0,00 detik. Browser dapat mengabaikan spekulasi, proses prerender mungkin belum selesai ketika tautan diklik, atau halaman dapat dibatalkan karena batasan keamanan dan sumber daya. Istilah yang lebih akurat secara teknis adalah navigasi nyaris instan.
Table of Contents
ToggleApa Itu Speculation Rules API?
Speculation Rules API adalah mekanisme deklaratif untuk memberi tahu browser tentang dokumen yang kemungkinan akan dikunjungi pengguna berikutnya. Aturan ditulis dalam format JSON dan biasanya ditempatkan di dalam elemen berikut:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["/artikel/speculation-rules"]
}
]
}
</script>
Kode tersebut tidak bekerja seperti JavaScript biasa. Isinya merupakan konfigurasi yang dibaca langsung oleh browser. Berdasarkan aturan itu, browser dapat mulai memuat /artikel/speculation-rules di latar belakang.
Ketika pengguna akhirnya membuka URL tersebut, browser tidak harus memulai semuanya dari awal. Jika proses prerender telah selesai, browser cukup mengaktifkan halaman yang sebelumnya sudah dipersiapkan.
Berbeda dari teknik pemuatan aset seperti <link rel="preload">, Speculation Rules API menargetkan dokumen navigasi, yaitu halaman yang mungkin akan dibuka selanjutnya. API ini paling relevan untuk situs dengan perpindahan dokumen penuh atau Multi-Page Application (MPA), bukan untuk perpindahan rute internal pada SPA yang tidak menjalankan navigasi dokumen baru. MDN menjelaskan bahwa API ini memang dirancang untuk navigasi dokumen dan lebih cocok bagi MPA daripada SPA.
Cara Kerja Speculative Loading
Saat menemukan aturan spekulasi, browser memasukkan URL yang sesuai sebagai kandidat. Browser kemudian menentukan apakah kandidat tersebut layak diproses berdasarkan aturan, interaksi pengguna, ketersediaan memori, kondisi jaringan, pengaturan pengguna, serta kebijakan internal browser.
Dengan kata lain, aturan dari developer adalah petunjuk, bukan perintah mutlak. Browser tetap memiliki keputusan akhir.
Ada dua mekanisme utama yang dapat digunakan, yaitu prefetch dan prerender.
Prefetch: Mengambil Dokumen Lebih Awal
Prefetch mengunduh respons dokumen utama dari URL tujuan sebelum navigasi dilakukan.
<script type="speculationrules">
{
"prefetch": [
{
"urls": [
"/artikel/html",
"/artikel/css"
]
}
]
}
</script>
Dalam proses ini, browser belum merender halaman dan tidak mengunduh seluruh subresource seperti CSS, gambar, font, dan JavaScript yang direferensikan dokumen tersebut.
Ketika pengguna membuka salah satu URL, dokumen utamanya telah tersedia sehingga sebagian pekerjaan jaringan dapat dilewati. Akan tetapi, browser masih harus mengambil subresource, menjalankan JavaScript, menghitung layout, dan menggambar tampilan.
Karena itu, prefetch lebih hemat sumber daya daripada prerender, tetapi hasil navigasinya belum tentu terasa sepenuhnya instan.
Speculation Rules API juga lebih tepat untuk melakukan prefetch dokumen navigasi dibandingkan <link rel="prefetch">. Sementara itu, <link rel="prefetch"> masih berguna untuk mengambil subresource tertentu. Dokumentasi MDN membedakan kedua kegunaan tersebut secara eksplisit.
Prerender: Menyiapkan Halaman Secara Lengkap
Prerender merupakan strategi yang jauh lebih agresif. Browser dapat:
- Mengunduh dokumen HTML.
- Mengambil subresource seperti CSS, font, gambar, dan JavaScript.
- Menjalankan JavaScript.
- Menghitung style dan layout.
- Merender halaman dalam konteks tersembunyi.
- Menjalankan pengambilan data yang dimulai oleh JavaScript, selama tidak terkena pembatasan.
Contoh penerapannya:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["/produk/laptop-developer"]
}
]
}
</script>
Jika pengguna kemudian membuka /produk/laptop-developer, browser dapat mengaktifkan halaman tersembunyi tersebut dan menjadikannya halaman aktif. Inilah yang membuat perpindahan halaman terasa nyaris tanpa waktu tunggu.
Jika pengguna mengeklik tautan ketika proses prerender belum selesai, halaman dapat diaktifkan dalam keadaan saat itu dan meneruskan pemuatan secara normal. Pengguna tetap memperoleh percepatan, tetapi hasilnya tidak selalu benar-benar instan.
Perlu diingat bahwa prerender mengonsumsi bandwidth, CPU, dan memori lebih besar daripada prefetch. MDN memperkirakan biaya sumber dayanya kira-kira sebanding dengan merender sebuah <iframe>. Oleh sebab itu, prerender sebaiknya hanya digunakan untuk tujuan yang kemungkinan besar akan dikunjungi. Penjelasan lengkap mengenai proses dan biaya prerender tersedia di MDN.
Menentukan URL yang Akan Dipersiapkan
Speculation Rules API menyediakan dua pendekatan utama: daftar URL dan document rules.
Menuliskan Daftar URL
Pendekatan paling sederhana adalah mencantumkan URL secara eksplisit melalui properti urls.
<script type="speculationrules">
{
"prerender": [
{
"urls": [
"/checkout/alamat",
"/checkout/pembayaran"
]
}
]
}
</script>
Pendekatan ini cocok ketika developer sudah mengetahui halaman selanjutnya dengan tingkat kepastian tinggi, misalnya:
- Langkah selanjutnya dalam proses registrasi.
- Halaman berikutnya pada artikel berseri.
- Tahap pembayaran setelah pengguna mengisi alamat.
- Detail produk unggulan dari sebuah kampanye.
Pada contoh lama, Anda mungkin menemukan "source": "list". Properti tersebut tidak lagi diwajibkan sejak Chrome 121 karena browser dapat mengenali aturan daftar dari keberadaan urls. Menghilangkannya membuat konfigurasi lebih ringkas.
Menggunakan Document Rules
Document rules memungkinkan browser memilih tautan langsung dari dokumen berdasarkan kondisi tertentu. Developer tidak perlu mendaftarkan setiap URL satu per satu.
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/cart/*" } },
{ "not": { "selector_matches": ".no-prerender" } },
{ "not": { "selector_matches": "[rel~=nofollow]" } }
]
},
"eagerness": "moderate"
}
]
}
</script>
Aturan tersebut memilih tautan internal, kemudian mengecualikan:
- URL
/logout. - Halaman di bawah
/cart/. - Tautan dengan kelas
.no-prerender. - Tautan yang memiliki atribut
rel="nofollow".
Operator and, or, dan not dapat digunakan untuk membangun penyaringan yang lebih presisi. Properti href_matches menyaring berdasarkan pola URL, sedangkan selector_matches menggunakan selector CSS.
Pendekatan ini sangat berguna pada blog, portal berita, katalog produk, dan situs dokumentasi yang memiliki banyak tautan dinamis.
Mengendalikan Waktu Spekulasi dengan Eagerness
Properti eagerness mengatur seberapa cepat browser memulai spekulasi. Pilihan strategi ini menentukan keseimbangan antara kecepatan dan kemungkinan pemborosan sumber daya.
Immediate
Nilai immediate meminta browser memulai spekulasi sesegera mungkin setelah aturan diproses.
{
"prerender": [
{
"urls": ["/checkout/pembayaran"],
"eagerness": "immediate"
}
]
}
Gunakan strategi ini apabila peluang pengguna membuka halaman tujuan sangat tinggi. Contohnya adalah langkah berikutnya dalam alur formulir atau transaksi yang berurutan.
Jangan menerapkannya tanpa seleksi pada puluhan tautan berat karena browser mungkin mengunduh dan merender halaman yang tidak pernah digunakan.
Eager
eager bekerja lebih cepat daripada moderate, tetapi tidak selalu langsung seperti immediate. Perilaku tepatnya dapat berubah mengikuti versi dan heuristik browser.
Pada Chrome versi modern, sinyalnya dapat berupa hover yang sangat singkat di desktop atau keberadaan tautan di area pandang pada perangkat bergerak. Karena perilaku tersebut merupakan bagian dari heuristik browser, aplikasi sebaiknya tidak menggantungkan logika bisnis pada waktu pemicu yang presisi.
Moderate
moderate menjadi titik tengah yang masuk akal untuk banyak situs. Pada desktop, spekulasi biasanya dijalankan setelah pengguna mengarahkan pointer ke tautan selama kurang lebih 200 milidetik, atau lebih awal jika terjadi pointerdown.
<script type="speculationrules">
{
"prerender": [
{
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}
]
}
</script>
Sinyal hover menunjukkan niat pengguna lebih kuat daripada sekadar menampilkan tautan. Browser mendapat sedikit waktu untuk bekerja sebelum klik dilakukan, tetapi risiko memuat halaman yang tidak akan dibuka tetap lebih kecil daripada strategi immediate.
Conservative
conservative baru memulai spekulasi ketika pengguna melakukan pointerdown atau menyentuh tautan. Jarak waktunya menuju peristiwa click memang sangat pendek, tetapi masih dapat digunakan untuk memulai pekerjaan jaringan lebih awal.
Strategi ini cocok ketika:
- Halaman tujuan cukup berat.
- Pengguna memiliki banyak pilihan tautan.
- Prediksi navigasi sulit dilakukan.
- Penghematan bandwidth lebih penting daripada navigasi yang sepenuhnya instan.
Menurut dokumentasi Chrome mengenai prerender, nilai bawaan untuk aturan berbasis urls adalah immediate, sedangkan nilai bawaan document rules adalah conservative. Chrome juga membatasi jumlah spekulasi aktif untuk menghindari penggunaan sumber daya berlebihan.
Implementasi yang Lebih Aman untuk Production
Implementasi terbaik bukanlah melakukan prerender terhadap semua tautan. Strategi yang sehat dimulai dari halaman berisiko rendah, kemudian ditingkatkan berdasarkan data.
Memadukan Prefetch dan Prerender
Developer dapat menggunakan prefetch ketika kemungkinan navigasi masih rendah, kemudian memakai prerender ketika muncul sinyal niat yang lebih kuat.
<script type="speculationrules">
{
"prefetch": [
{
"where": {
"href_matches": "/artikel/*"
},
"eagerness": "eager"
}
],
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/artikel/*" },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}
]
}
</script>
Pendekatan bertingkat ini memberi browser kesempatan mengambil dokumen lebih awal tanpa selalu membayar biaya prerender penuh untuk setiap kandidat.
Mengirim Aturan Melalui HTTP Header
Aturan juga dapat diletakkan dalam berkas terpisah, kemudian direferensikan melalui HTTP response header:
Speculation-Rules: "/rules/speculation.json"
Berkas tersebut harus disajikan menggunakan MIME type yang benar:
Content-Type: application/speculationrules+json
Metode ini berguna apabila aturan dikelola melalui server, CDN, atau edge worker tanpa mengubah isi setiap halaman HTML.
Jika aturan ditulis langsung di dalam elemen <script type="speculationrules">, kebijakan Content Security Policy harus mengizinkannya. Salah satu opsi yang disediakan adalah sumber CSP 'inline-speculation-rules'. MDN mendokumentasikan metode inline, HTTP header, MIME type, dan ketentuan CSP tersebut.
Mendeteksi Dukungan Browser
Karena dukungannya belum merata, lakukan deteksi fitur sebelum menambahkan aturan secara dinamis:
if (
HTMLScriptElement.supports &&
HTMLScriptElement.supports("speculationrules")
) {
console.log("Speculation Rules API didukung.");
} else {
console.log("Gunakan navigasi standar sebagai fallback.");
}
Untuk aturan yang sudah ditulis di HTML, browser yang tidak mendukung type="speculationrules" umumnya akan mengabaikannya. Navigasi biasa tetap berfungsi sehingga API ini cocok diterapkan sebagai progressive enhancement.
Masalah Keamanan dan Efek Samping
Kecepatan bukan satu-satunya pertimbangan. Prerender dapat mengeksekusi JavaScript sebelum pengguna benar-benar melihat halaman. Karena itu, halaman target harus dirancang seolah-olah dapat mulai berjalan di latar belakang.
Jangan Melakukan Mutasi Saat Halaman Dibuka
Hindari melakukan prerender terhadap URL yang langsung menghasilkan perubahan, seperti:
- Mengeluarkan pengguna dari akun.
- Menghapus atau membatalkan pesanan.
- Menambahkan produk ke keranjang.
- Mengirim formulir.
- Mengubah status transaksi.
- Memicu operasi database yang tidak idempoten.
Secara prinsip HTTP, permintaan GET seharusnya tidak menyebabkan perubahan destruktif. Speculative loading membuat disiplin ini semakin penting karena browser dapat meminta URL sebelum pengguna secara eksplisit membukanya.
Route seperti /logout, /delete, /cancel, dan URL yang memiliki parameter pemicu aksi harus dikecualikan dari aturan.
Hati-Hati dengan Analytics
Karena JavaScript dapat berjalan selama prerender, implementasi analitik yang tidak siap dapat menghitung page view sebelum halaman benar-benar dilihat. Hasilnya adalah trafik, durasi sesi, atau rasio konversi yang tidak akurat.
Gunakan document.prerendering untuk menunda inisialisasi analitik:
function initAnalytics() {
gtag("event", "page_view");
}
if (document.prerendering) {
document.addEventListener(
"prerenderingchange",
initAnalytics,
{ once: true }
);
} else {
initAnalytics();
}
Event prerenderingchange berjalan ketika halaman yang sebelumnya di-prerender diaktifkan. Pola ini juga dapat dipakai untuk menunda iklan, pemutaran media, atau aktivitas lain yang hanya masuk akal setelah pengguna benar-benar melihat halaman. MDN merekomendasikan pola tersebut untuk mencegah analytics berjalan sebelum aktivasi.
Pembatasan API Selama Prerender
Beberapa fitur browser dibatasi atau ditangguhkan selama halaman masih tersembunyi. Dialog seperti alert(), confirm(), dan prompt() tidak boleh diandalkan selama proses ini. Permintaan izin perangkat serta aktivitas tertentu juga dapat ditunda sampai halaman diaktifkan.
Karena itu, kode halaman harus membedakan antara:
- Halaman sedang dipersiapkan.
- Halaman telah aktif dan benar-benar dilihat pengguna.
Batasan Origin
Secara default, prerender berfokus pada halaman same-origin. Prerender lintas origin tetapi masih same-site memerlukan persetujuan dari halaman tujuan melalui header berikut:
Supports-Loading-Mode: credentialed-prerender
Prerender lintas situs secara umum tidak tersedia seperti prerender same-origin. Prefetch memiliki kemampuan lintas origin yang lebih luas, tetapi tetap mengikuti pembatasan kredensial, privasi, dan kebijakan browser.
Mengukur Apakah Prerender Berhasil
Optimasi performa harus dibuktikan dengan data, bukan hanya berdasarkan kesan visual.
Menggunakan PerformanceNavigationTiming
Properti activationStart pada entri navigasi dapat digunakan untuk mendeteksi apakah halaman diaktifkan dari hasil prerender:
const navigation =
performance.getEntriesByType("navigation")[0];
if (navigation?.activationStart > 0) {
console.log("Halaman diaktifkan dari prerender.");
}
Developer dapat membandingkan beberapa metrik berikut antara navigasi biasa dan navigasi hasil spekulasi:
- Largest Contentful Paint atau LCP.
- Interaction to Next Paint atau INP setelah aktivasi.
- Waktu navigasi yang dirasakan pengguna.
- Rasio kandidat yang benar-benar diaktifkan.
- Bandwidth yang terbuang dari spekulasi yang tidak digunakan.
- Penggunaan CPU dan memori.
- Dampak terhadap konversi atau penyelesaian alur pengguna.
Jangan hanya mengejar LCP rendah. Jika 90% halaman yang di-prerender tidak pernah dibuka, peningkatan performa tersebut mungkin dibayar dengan pemborosan jaringan dan sumber daya pengguna.
Melakukan Debugging di Chrome DevTools
Chrome menyediakan panel khusus untuk memeriksa speculative loading:
- Buka Chrome DevTools.
- Pilih panel Application.
- Buka Background services.
- Pilih Speculative loads.
- Periksa bagian Rules dan Speculations.
Panel tersebut menampilkan aturan yang ditemukan, URL kandidat, status proses, serta penyebab kegagalan atau pembatalan. Dokumentasi resmi Chrome juga menjelaskan bahwa request prefetch membawa header Sec-Purpose: prefetch, sedangkan prerender menggunakan Sec-Purpose: prefetch;prerender. Panduan debugging tersedia di Chrome for Developers.
Dukungan Browser dan Progressive Enhancement
Speculation Rules API tersedia pada Google Chrome dan Microsoft Edge sejak versi 109, sedangkan sejumlah browser berbasis Chromium lainnya juga telah mengadopsinya. Namun, dukungan fitur turunannya tidak selalu hadir pada versi yang sama. Sebagai contoh, document rules baru tersedia di Chrome 121.
Firefox dan Safari belum mendukungnya secara penuh. Oleh karena itu, MDN masih menandai Speculation Rules API sebagai teknologi eksperimental dengan status Limited availability, bukan fitur Baseline.
Data kompatibilitas terbaru dapat diperiksa melalui Can I Use. Developer tetap disarankan melakukan pengujian pada browser sasaran dan tidak menyimpulkan dukungan hanya karena sebuah browser menggunakan Chromium.
Ketiadaan dukungan tidak merusak fungsi dasar situs. Pengguna hanya akan memperoleh navigasi normal. Inilah alasan Speculation Rules API sebaiknya diperlakukan sebagai lapisan peningkatan performa, bukan fondasi yang menentukan apakah navigasi dapat bekerja.
Dampaknya bagi MPA dan SPA
Speculation Rules API sangat menarik bagi MPA seperti situs berbasis Laravel, Django, Ruby on Rails, WordPress, atau HTML hasil server-side rendering. MPA tetap dapat menggunakan navigasi dokumen biasa, tetapi halaman selanjutnya sudah dipersiapkan sebelum klik.
Hal ini dapat mengurangi salah satu keunggulan persepsi yang selama ini identik dengan SPA: transisi tanpa menunggu pemuatan halaman baru. MPA dapat memperoleh perpindahan nyaris instan tanpa harus memindahkan seluruh logika navigasi ke JavaScript pada sisi klien.
Namun, Speculation Rules API bukan pengganti SPA dan tidak dapat melakukan prerender terhadap perubahan rute internal yang hanya dimanipulasi oleh client-side router. API ini bekerja untuk navigasi dokumen yang dikelola browser.
Pada SPA, API tersebut masih dapat membantu mempersiapkan dokumen awal aplikasi dari halaman lain. Untuk perpindahan rute internal, aplikasi perlu memakai mekanisme lain, seperti data prefetching, pemanasan cache, atau fasilitas yang disediakan framework.
Apakah Benar Bisa Membuka Web dalam 0 Detik?
Speculation Rules API dapat membuat navigasi terasa instan apabila:
- Browser mendukung API.
- URL tujuan berhasil diprediksi.
- Aturan tidak ditolak.
- Proses prerender selesai sebelum klik.
- Halaman tidak melanggar pembatasan prerender.
- Perangkat memiliki sumber daya yang cukup.
- Pengguna benar-benar membuka kandidat yang sudah dipersiapkan.
Sebaliknya, hasilnya tidak akan instan apabila spekulasi belum selesai, URL tidak cocok, halaman tidak aman untuk diproses, atau browser memilih mengabaikan aturan.
Dengan demikian, “kecepatan 0 detik” merupakan gambaran pengalaman pengguna, bukan jaminan angka laboratorium. Istilah yang lebih bertanggung jawab adalah perpindahan halaman nyaris instan melalui pemuatan spekulatif.
Berikut perbandingan beberapa pendekatan yang dapat digunakan:
| Pendekatan | Yang dipersiapkan | Subresource dimuat | JavaScript dijalankan | Potensi kecepatan navigasi | Biaya sumber daya | Kegunaan utama |
|---|---|---|---|---|---|---|
| Navigasi biasa | Tidak ada sebelum klik | Setelah navigasi | Setelah navigasi | Normal | Rendah sebelum klik | Fallback universal dan halaman yang sulit diprediksi |
<link rel="prefetch"> | Resource atau dokumen ke HTTP cache | Hanya resource yang ditentukan | Tidak | Lebih cepat pada kondisi tertentu | Rendah–menengah | Prefetch subresource; bukan pilihan utama untuk spekulasi dokumen modern |
Speculation Rules prefetch | Dokumen tujuan | Tidak | Tidak | Lebih cepat, tetapi masih memerlukan render dan subresource | Menengah | Kandidat navigasi dengan tingkat kepastian sedang |
Speculation Rules prerender | Dokumen dan halaman yang telah dirender | Ya | Ya, dengan pembatasan tertentu | Nyaris instan jika berhasil diaktifkan | Paling tinggi | Navigasi yang sangat mungkin dilakukan dan aman dipersiapkan |
| SPA dengan client-side routing | Data, komponen, atau route sesuai implementasi aplikasi | Bergantung pada framework | Ya | Dapat terasa cepat setelah aplikasi aktif | Bergantung pada ukuran bundle dan arsitektur | Aplikasi dengan interaksi dan state sisi klien yang kompleks |
Strategi implementasi yang paling sehat adalah memulai dari prefetch, menggunakan eagerness: "moderate" atau "conservative", serta memilih halaman yang aman dan sering dikunjungi. Setelah hasil pengukuran menunjukkan prediksi yang akurat, halaman terpenting dapat ditingkatkan menjadi prerender.
Speculation Rules API bukan tombol ajaib yang membuat semua halaman otomatis cepat. API ini adalah alat optimasi yang kuat ketika didukung oleh pemilihan URL yang tepat, desain route yang aman, analytics yang sadar prerender, pengukuran nyata, dan fallback navigasi standar.
Jika diterapkan dengan disiplin, teknologi ini dapat memberikan sesuatu yang sebelumnya sulit diperoleh oleh MPA: perpindahan antarhalaman yang terasa seperti sudah selesai bahkan sebelum pengguna mengekliknya.
