Melakukan pra-render halaman di Chrome untuk navigasi halaman instan

Barry Pollard

Dipublikasikan: 2 Desember 2022, Terakhir diperbarui: 29 Oktober 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Tim Chrome telah menghadirkan kembali pra-rendering penuh untuk halaman mendatang yang kemungkinan akan dibuka pengguna.

Sejarah singkat pra-render

Sebelumnya, Chrome mendukung petunjuk resource <link rel="prerender" href="/next-page">, tetapi tidak didukung secara luas di luar Chrome, dan bukan API yang sangat ekspresif.

Pra-rendering lama yang menggunakan petunjuk link rel=prerender ini tidak digunakan lagi dan digantikan oleh NoState Prefetch, yang mengambil resource yang diperlukan oleh halaman mendatang, tetapi tidak sepenuhnya melakukan pra-rendering halaman atau mengeksekusi JavaScript. NoState Prefetch membantu meningkatkan performa halaman dengan meningkatkan pemuatan resource, tetapi tidak akan memberikan pemuatan halaman instan seperti pra-rendering penuh.

Tim Chrome kini telah memperkenalkan kembali pra-rendering penuh ke Chrome. Untuk menghindari komplikasi dengan penggunaan yang ada, dan untuk memungkinkan perluasan pra-rendering di masa mendatang, mekanisme pra-rendering baru ini tidak akan menggunakan sintaksis <link rel="prerender"...>, yang tetap digunakan untuk NoState Prefetch, dengan tujuan untuk menghentikannya pada suatu waktu di masa mendatang.

Bagaimana cara halaman dipra-render?

Halaman dapat dipra-render dengan salah satu dari empat cara, yang semuanya bertujuan untuk mempercepat navigasi:

  1. Saat Anda mengetik URL ke kolom URL Chrome (juga dikenal sebagai "omnibox"), Chrome dapat otomatis melakukan pra-render halaman untuk Anda, jika Chrome sangat yakin Anda akan mengunjungi halaman tersebut, berdasarkan histori penjelajahan Anda sebelumnya.
  2. Saat Anda menggunakan kolom bookmark, Chrome dapat otomatis melakukan pra-rendering halaman untuk Anda saat Anda menahan kursor di salah satu tombol bookmark.
  3. Saat Anda mengetik istilah penelusuran di kolom URL Chrome, Chrome dapat otomatis melakukan pra-rendering halaman hasil penelusuran, jika diinstruksikan untuk melakukannya oleh mesin telusur.
  4. Situs dapat menggunakan Speculation Rules API untuk memberi tahu Chrome secara terprogram halaman mana yang akan di-pra-render. Hal ini menggantikan fungsi <link rel="prerender"...> dan memungkinkan situs melakukan pra-render halaman secara proaktif berdasarkan aturan spekulasi di halaman. Tag ini dapat ada secara statis di halaman, atau dimasukkan secara dinamis oleh JavaScript sesuai keinginan pemilik halaman.

Dalam setiap kasus ini, pra-render berperilaku seolah-olah halaman telah dibuka di tab latar belakang yang tidak terlihat, lalu "diaktifkan" dengan mengganti tab latar depan dengan halaman yang telah dipra-render tersebut. Jika halaman diaktifkan sebelum dipra-render sepenuhnya, statusnya saat ini adalah "latar depan" dan terus dimuat, yang berarti Anda masih dapat memulai dengan baik.

Karena halaman yang dipra-render dibuka dalam status tersembunyi, sejumlah API yang menyebabkan perilaku mengganggu (misalnya, dialog) tidak diaktifkan dalam status ini, dan malah ditunda hingga halaman diaktifkan. Dalam sejumlah kecil kasus yang tidak memungkinkan, pra-rendering akan dibatalkan. Tim Chrome sedang berupaya mengekspos alasan pembatalan pra-rendering sebagai API, dan juga meningkatkan kemampuan DevTools untuk mempermudah identifikasi kasus ekstrem tersebut.

Dampak pra-rendering

Pra-rendering memungkinkan pemuatan halaman yang hampir instan seperti yang ditunjukkan dalam video berikut:

Contoh dampak pra-rendering.

Situs contoh sudah merupakan situs yang cepat, tetapi meskipun demikian, Anda dapat melihat bagaimana pra-rendering meningkatkan pengalaman pengguna. Oleh karena itu, hal ini juga dapat berdampak langsung pada Core Web Vitals situs, dengan LCP yang mendekati nol, CLS yang berkurang (karena CLS pemuatan terjadi sebelum tampilan awal), dan INP yang meningkat (karena pemuatan harus diselesaikan sebelum pengguna berinteraksi).

Meskipun halaman diaktifkan sebelum dimuat sepenuhnya, memulai pemuatan halaman lebih awal akan meningkatkan pengalaman pemuatan. Jika link diaktifkan saat pra-rendering masih berlangsung, halaman pra-rendering akan berpindah ke frame utama dan melanjutkan pemuatan.

Namun, pra-rendering menggunakan memori dan bandwidth jaringan tambahan. Berhati-hatilah agar tidak melakukan pra-rendering berlebihan, yang dapat mengorbankan resource pengguna. Hanya lakukan pra-rendering jika ada kemungkinan besar halaman akan dibuka.

Lihat bagian Mengukur performa untuk mengetahui informasi selengkapnya tentang cara mengukur dampak performa yang sebenarnya dalam analisis Anda.

Melihat prediksi kolom URL Chrome

Untuk kasus penggunaan pertama, Anda dapat melihat prediksi Chrome untuk URL di halaman chrome://predictors:

Halaman Prediktor Chrome difilter untuk menampilkan prediksi rendah (abu-abu), sedang (kuning), dan tinggi (hijau) berdasarkan teks yang dimasukkan.
Halaman Chrome Predictors.

Garis hijau menunjukkan keyakinan yang cukup untuk memicu pra-rendering. Dalam contoh ini, mengetik "s" memberikan keyakinan yang wajar (kuning), tetapi setelah Anda mengetik "sh", Chrome memiliki keyakinan yang cukup bahwa Anda hampir selalu membuka https://sheets.google.com.

Screenshot ini diambil dalam penginstalan Chrome yang relatif baru, dan memfilter prediksi keyakinan nol, tetapi jika Anda melihat prediktor Anda sendiri, Anda mungkin akan melihat lebih banyak entri, dan berpotensi lebih banyak karakter yang diperlukan untuk mencapai tingkat keyakinan yang cukup tinggi.

Prediktor ini juga yang mendorong opsi yang disarankan di kolom URL yang mungkin Anda perhatikan:

Fitur 'Ketik otomatis' di kolom URL Chrome
Fitur 'Typeahead' kolom URL.

Chrome akan terus memperbarui prediktornya berdasarkan pengetikan dan pilihan Anda.

  • Untuk tingkat keyakinan lebih dari 30% (ditampilkan dalam warna kuning), Chrome secara proaktif melakukan pra-koneksi ke domain, tetapi tidak melakukan pra-rendering halaman.
  • Untuk tingkat keyakinan lebih dari 50% (ditampilkan dalam warna hijau), Chrome akan melakukan pra-rendering URL.

Speculation Rules API

Untuk opsi pra-rendering Speculation Rules API, developer web dapat menyisipkan petunjuk JSON ke halaman mereka untuk memberi tahu browser URL mana yang akan dipra-render.

Daftar URL

Aturan spekulasi dapat didasarkan pada daftar URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Aturan dokumen

Aturan spekulasi juga dapat berupa "aturan dokumen" menggunakan sintaksis where. Tindakan ini akan berspekulasi link yang ditemukan dalam dokumen berdasarkan pemilih href (berdasarkan API Pola URL) atau pemilih CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Antusiasme

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Setelan eagerness digunakan untuk menunjukkan kapan spekulasi harus diaktifkan, yang sangat berguna untuk aturan dokumen:

  • conservative: Tingkat ini menerapkan spekulasi pada pointer atau touch down.
  • moderate: Di desktop, tingkat ini menerapkan spekulasi jika Anda mengarahkan kursor ke link selama 200 milidetik (atau pada peristiwa pointerdown jika lebih dahulu, dan pada perangkat seluler yang tidak menggunakan peristiwa hover). Di perangkat seluler, kami mengubahnya agar didasarkan pada heuristik area pandang yang kompleks mulai Agustus 2025. Heuristik area pandang yang kompleks dipicu 500 md setelah pengguna berhenti men-scroll, untuk anchor dalam jarak vertikal 30% dari pointer sebelumnya, dengan anchor berukuran minimal 0,5x lebih besar dari anchor terbesar di area pandang. Seperti yang dijelaskan dalam dokumen ini.
  • eager: Tingkat ini sebelumnya berperilaku serupa dengan immediate, tetapi berubah mulai Chrome 143. Di desktop, tingkat ini menerapkan spekulasi jika Anda mengarahkan kursor ke link selama 10 milidetik. Di perangkat seluler, kami mengubahnya agar didasarkan pada heuristik area pandang sederhana mulai Januari 2026. Heuristik area pandang sederhana dipicu 50 md setelah anchor memasuki area pandang.
  • immediate: Tingkat ini digunakan untuk menerapkan spekulasi sesegera mungkin, yaitu tepat setelah aturan spekulasi diamati.

eagerness default untuk aturan list adalah immediate. Opsi eager, moderate, dan conservative dapat digunakan untuk membatasi aturan list ke URL yang berinteraksi dengan pengguna ke daftar tertentu. Meskipun dalam banyak kasus, aturan document dengan kondisi where yang sesuai mungkin lebih tepat.

eagerness default untuk aturan document adalah conservative. Mengingat dokumen dapat terdiri dari banyak URL, penggunaan immediate untuk aturan document harus dilakukan dengan hati-hati (lihat juga bagian Batasan Chrome berikutnya).

Setelan eagerness yang akan digunakan bergantung pada situs Anda. Untuk situs statis yang ringan, spekulasi yang lebih agresif mungkin memerlukan sedikit biaya dan bermanfaat bagi pengguna. Situs dengan arsitektur yang lebih kompleks dan payload halaman yang lebih berat mungkin lebih memilih untuk mengurangi pemborosan dengan mengurangi spekulasi hingga Anda mendapatkan lebih banyak sinyal positif terkait niat dari pengguna untuk membatasi pemborosan.

Opsi moderate adalah jalan tengah, dan banyak situs dapat memanfaatkan aturan spekulasi berikut yang akan melakukan pra-rendering link saat menahan kursor di atas link selama 200 milidetik atau pada peristiwa pointerdown sebagai implementasi aturan spekulasi yang dasar, tetapi efektif:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Prefetch

Aturan spekulasi juga dapat digunakan untuk mengambil data halaman saja, tanpa pra-render penuh. Hal ini sering kali dapat menjadi langkah awal yang baik dalam proses pra-rendering:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

Tim Chrome juga berupaya menambahkan prerender_until_script ke Speculation Rules API (Lihat: bug implementasi). Langkah ini akan menjadi langkah antara pengambilan data di awal dan pra-rendering, serta akan digunakan dengan cara yang serupa:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Serupa dengan NoState prefetch, tindakan ini akan mengambil data di awal dokumen HTML dan juga subresource yang tersedia dalam HTML tersebut. Namun, Chrome akan melangkah lebih jauh dan juga mulai melakukan pra-rendering halaman, lalu berhenti saat skrip pertama ditemukan.

Artinya, untuk halaman tanpa JavaScript, atau hanya JavaScript di footer, halaman tersebut dapat dipra-render hampir sepenuhnya terlebih dahulu. Halaman dengan skrip di <head> tidak akan dapat melakukan pra-rendering, tetapi masih akan mendapatkan manfaat dari pengambilan subresource.

Hal ini akan menghindari risiko efek samping yang tidak diinginkan dari eksekusi JavaScript, tetapi memungkinkan peningkatan performa yang jauh lebih besar daripada sekadar prefetch.

Batas Chrome

Chrome memiliki batasan untuk mencegah penggunaan Speculation Rules API secara berlebihan:

antusiasme Prefetch Pra-rendering
immediate 50 10
eager/moderate di perangkat seluler 6 (FIFO) 2 (FIFO)
eager/moderate di desktop 2 (FIFO) 2 (FIFO)
conservative 2 (FIFO) 2 (FIFO)
Batas spekulasi di Chrome.

Setelan eager, moderate, dan conservative—yang bergantung pada interaksi pengguna—berfungsi dengan cara First In, First Out (FIFO): setelah mencapai batas, spekulasi baru akan menyebabkan spekulasi terlama dibatalkan dan digantikan oleh spekulasi yang lebih baru untuk menghemat memori.

Spekulasi yang dibatalkan dapat dipicu lagi—misalnya dengan mengarahkan kursor ke link tersebut lagi—yang akan menyebabkan URL tersebut dispekulasikan ulang, sehingga spekulasi terlama akan dihapus. Dalam hal ini, spekulasi sebelumnya akan meng-cache resource yang dapat di-cache di Cache HTTP untuk URL tersebut, sehingga spekulasi lebih lanjut akan mengurangi biaya. Itulah sebabnya batas ditetapkan ke nilai minimum sederhana, yaitu 2, secara default. Kami menggunakan nilai minimum yang lebih tinggi, yaitu 6, untuk pengambilan data di perangkat seluler karena tidak ada "arahkan kursor", heuristik area pandang seluler alternatif kurang akurat, dan pengambilan data lebih murah daripada pra-rendering (kami mempertahankan batas 2 untuk pra-rendering di perangkat seluler).

Aturan daftar statis tidak dipicu oleh tindakan pengguna, sehingga memiliki batas yang lebih tinggi karena browser tidak dapat mengetahui aturan mana yang diperlukan dan kapan aturan tersebut diperlukan.

Chrome juga mempertimbangkan untuk meningkatkan batas menjadi 5 di perangkat seluler untuk eager dan moderate setidaknya untuk pengambilan data di awal, mengingat ini adalah heuristik yang kurang akurat. Developer yang menggunakan eager dapat mempertimbangkan untuk menggunakan aturan conservative selain saat beberapa link tersedia di area pandang sehingga mereka tetap berspekulasi meskipun tidak dipilih sebagai salah satu dari dua link pertama.

Batas immediate juga bersifat dinamis, sehingga menghapus elemen skrip URL list akan menciptakan kapasitas dengan membatalkan spekulasi yang dihapus tersebut.

Chrome juga akan mencegah spekulasi digunakan dalam kondisi tertentu, termasuk:

  • Save-Data.
  • Penghemat energi jika diaktifkan dan baterai lemah.
  • Batasan memori.
  • Jika setelan "Pramuat halaman" dinonaktifkan (yang juga dinonaktifkan secara eksplisit oleh ekstensi Chrome seperti uBlock Origin).
  • Halaman yang dibuka di tab latar belakang.

Chrome juga tidak merender iframe lintas origin di halaman yang dipra-render hingga aktivasi.

Semua kondisi ini bertujuan untuk mengurangi dampak spekulasi berlebihan yang dapat merugikan pengguna.

Cara menyertakan aturan spekulasi di halaman

Aturan spekulasi dapat disertakan secara statis dalam HTML halaman atau disisipkan secara dinamis ke dalam halaman oleh JavaScript:

  • Aturan spekulasi yang disertakan secara statis: Misalnya, situs media berita atau blog dapat melakukan pra-rendering artikel terbaru, jika artikel tersebut sering menjadi navigasi berikutnya bagi sebagian besar pengguna. Atau, aturan dokumen dengan moderate atau conservative dapat digunakan untuk berspekulasi saat pengguna berinteraksi dengan link.
  • Aturan spekulasi yang disisipkan secara dinamis: Aturan ini dapat didasarkan pada logika aplikasi, dipersonalisasi untuk pengguna, atau didasarkan pada heuristik lainnya.

Mereka yang lebih menyukai penyisipan dinamis berdasarkan tindakan seperti mengarahkan kursor ke, atau mengklik link—seperti yang telah dilakukan banyak library di masa lalu dengan <link rel=prefetch>—disarankan untuk melihat aturan dokumen, karena aturan ini memungkinkan browser menangani banyak kasus penggunaan Anda.

Aturan spekulasi dapat ditambahkan di <head> atau <body> dalam frame utama. Aturan spekulasi dalam subframe tidak ditindaklanjuti, dan aturan spekulasi di halaman yang dipra-render hanya ditindaklanjuti setelah halaman tersebut diaktifkan.

Header HTTP Speculation-Rules

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Aturan spekulasi juga dapat dikirimkan menggunakan header HTTP Speculation-Rules, bukan menyertakannya langsung dalam HTML dokumen. Hal ini memudahkan deployment oleh CDN tanpa perlu mengubah konten dokumen itu sendiri.

Header HTTP Speculation-Rules ditampilkan bersama dokumen, dan mengarah ke lokasi file JSON yang berisi aturan spekulasi:

Speculation-Rules: "/speculationrules.json"

Resource ini harus menggunakan jenis MIME yang benar dan, jika merupakan resource lintas origin, lulus pemeriksaan CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Jika ingin menggunakan URL relatif, Anda mungkin perlu menyertakan kunci "relative_to": "document" dalam aturan spekulasi. Jika tidak, URL relatif akan relatif terhadap URL file JSON aturan spekulasi. Hal ini dapat sangat berguna jika Anda perlu memilih beberapa—atau semua—link origin yang sama.

Kolom tag aturan spekulasi

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Anda juga dapat menambahkan "tag" dalam sintaksis JSON aturan spekulasi di tingkat keseluruhan untuk semua aturan spekulasi dalam kumpulan aturan:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Atau di tingkat aturan individual:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Tag ini kemudian ditampilkan di header HTTP Sec-Speculation-Tags, yang dapat digunakan untuk memfilter aturan spekulasi di server. Header HTTP Sec-Speculation-Tags dapat menyertakan beberapa tag jika spekulasi dicakup oleh beberapa aturan, seperti yang ditunjukkan contoh berikut:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Beberapa CDN otomatis memasukkan aturan spekulasi, tetapi memblokir spekulasi untuk halaman yang tidak di-edge caching agar fitur ini tidak meningkatkan penggunaan server asal. Tag memungkinkan mereka mengidentifikasi spekulasi yang dimulai oleh ruleset default, tetapi tetap mengizinkan aturan apa pun yang ditambahkan oleh situs untuk diteruskan ke origin.

Tag set aturan juga ditampilkan di Chrome DevTools.

Kolom target_hint aturan spekulasi

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Aturan spekulasi juga dapat menyertakan kolom target_hint, yang berisi nama atau kata kunci konteks penjelajahan yang valid yang menunjukkan tempat halaman mengharapkan konten yang diprarender diaktifkan:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Petunjuk ini memungkinkan spekulasi pra-rendering ditangani untuk link target="_blank":

<a target="_blank" href="next.html">Open this link in a new tab</a>

Untuk saat ini, hanya "target_hint": "_blank" dan "target_hint": "_self" (default jika tidak ditentukan) yang didukung di Chrome dan hanya untuk pra-rendering—pengambilan data di awal tidak didukung.

target_hint hanya diperlukan untuk aturan spekulasi urls, sedangkan untuk aturan dokumen, target diketahui dari link itu sendiri.

Aturan spekulasi dan SPA

Aturan spekulasi hanya didukung untuk navigasi halaman penuh yang dikelola oleh browser, dan tidak untuk Aplikasi Web Satu Halaman (SPA) atau halaman app shell. Arsitektur ini tidak menggunakan pengambilan dokumen, melainkan melakukan pengambilan data atau halaman secara parsial atau melalui API, yang kemudian diproses dan ditampilkan di halaman saat ini. Data yang diperlukan untuk "navigasi ringan" ini dapat diambil lebih awal oleh aplikasi di luar aturan spekulasi, tetapi tidak dapat dipra-render.

Aturan Spekulasi dapat digunakan untuk melakukan pra-render aplikasi itu sendiri dari halaman sebelumnya. Hal ini dapat membantu mengimbangi beberapa biaya pemuatan awal tambahan yang dimiliki beberapa SPA. Namun, perubahan rute dalam aplikasi tidak dapat dipra-render.

Men-debug aturan spekulasi

Lihat postingan khusus tentang men-debug aturan spekulasi, untuk mengetahui fitur Chrome DevTools baru yang membantu melihat dan men-debug API baru ini.

Beberapa aturan spekulasi

Beberapa aturan spekulasi juga dapat ditambahkan ke halaman yang sama, dan aturan tersebut akan ditambahkan ke aturan yang ada. Oleh karena itu, berbagai cara berikut akan menghasilkan pra-rendering one.html dan two.html:

Daftar URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Beberapa skrip speculationrules:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Beberapa daftar dalam satu set speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

Saat melakukan pengambilan atau pra-rendering halaman, parameter URL tertentu (secara teknis dikenal sebagai parameter penelusuran) mungkin tidak penting untuk halaman yang sebenarnya dikirim oleh server, dan hanya digunakan oleh JavaScript sisi klien.

Misalnya, parameter UTM digunakan oleh Google Analytics untuk pengukuran kampanye, tetapi biasanya tidak menghasilkan halaman berbeda yang dikirim dari server. Artinya, page1.html?utm_content=123 dan page1.html?utm_content=456 akan mengirimkan halaman yang sama dari server, sehingga halaman yang sama dapat digunakan kembali dari cache.

Demikian pula, aplikasi dapat menggunakan parameter URL lain yang hanya ditangani di sisi klien.

Proposal No-Vary-Search memungkinkan server menentukan parameter yang tidak menghasilkan perbedaan pada resource yang dikirim, sehingga memungkinkan browser menggunakan kembali versi dokumen yang di-cache sebelumnya yang hanya berbeda berdasarkan parameter ini. Hal ini didukung di Chrome (dan browser berbasis Chromium) untuk spekulasi navigasi, baik untuk pengambilan data maupun pra-rendering.

Aturan spekulasi mendukung penggunaan expects_no_vary_search untuk menunjukkan tempat header HTTP No-Vary-Search diharapkan akan ditampilkan. Tindakan ini dapat membantu menghindari download yang tidak perlu sebelum respons dilihat.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

Dalam contoh ini, HTML halaman awal /products sama untuk ID produk 123 dan 124. Namun, konten halaman pada akhirnya berbeda berdasarkan rendering sisi klien menggunakan JavaScript untuk mengambil data produk menggunakan parameter penelusuran id. Jadi, kami melakukan pengambilan data di awal untuk URL tersebut secara proaktif dan URL tersebut akan menampilkan header HTTP No-Vary-Search yang menunjukkan bahwa halaman tersebut dapat digunakan untuk parameter penelusuran id apa pun.

Namun, jika pengguna mengklik salah satu link sebelum pengambilan data di awal selesai, browser mungkin belum menerima halaman /products. Dalam hal ini, browser tidak tahu apakah header HTTP No-Vary-Search akan disertakan. Browser kemudian memiliki pilihan untuk mengambil link lagi, atau menunggu pengambilan data di awal selesai untuk melihat apakah link tersebut berisi header HTTP No-Vary-Search. Setelan expects_no_vary_search memungkinkan browser mengetahui bahwa respons halaman diharapkan berisi header HTTP No-Vary-Search, dan menunggu pengambilan data di awal tersebut selesai.

Anda juga dapat menambahkan beberapa parameter ke expects_no_vary_search dengan spasi yang memisahkannya (karena No-Vary-Search adalah header terstruktur HTTP):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Batasan aturan spekulasi dan peningkatan di masa mendatang

Aturan spekulasi dibatasi untuk halaman yang dibuka dalam tab yang sama, tetapi kami berupaya mengurangi batasan tersebut.

Secara default, pra-rendering dibatasi untuk halaman origin yang sama. Pra-rendering halaman lintas origin situs yang sama (misalnya, https://a.example.com dapat melakukan pra-rendering halaman di https://b.example.com) dapat diaktifkan. Untuk menggunakan fitur ini, halaman yang dispekulasikan (https://b.example.com dalam contoh ini) harus diikutsertakan dengan menyertakan header HTTP Supports-Loading-Mode: credentialed-prerender atau Chrome akan membatalkan spekulasi.

Versi mendatang juga dapat mengizinkan pra-render untuk halaman lintas origin, non-situs yang sama asalkan cookie tidak ada untuk halaman yang dipra-render dan halaman yang dipra-render ikut serta dengan header HTTP Supports-Loading-Mode: uncredentialed-prerender yang serupa.

Aturan spekulasi sudah mendukung pengambilan data di awal lintas origin. Untuk pengambilan data di awal lintas origin di situs yang sama, tidak ada batasan. Pengambilan data lintas origin dari situs yang berbeda hanya didukung jika cookie untuk domain lintas origin tidak ada. Jika cookie ada dari pengguna yang telah mengunjungi situs tersebut sebelumnya, spekulasi tidak akan digunakan dan akan menampilkan kegagalan di DevTools.

Mengingat batasan saat ini, salah satu pola yang dapat meningkatkan pengalaman pengguna untuk link internal dan link eksternal jika memungkinkan adalah melakukan pra-rendering URL origin yang sama dan mencoba melakukan pengambilan data di awal URL lintas origin:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }],
    "prefetch": [{
      "where": { "not": { "href_matches": "/*" } },
      "eagerness": "moderate"
    }]
  }
</script>

Pembatasan untuk mencegah spekulasi lintas origin untuk link lintas origin secara default diperlukan untuk keamanan. Ini adalah peningkatan dibandingkan <link rel="prefetch"> untuk tujuan lintas origin yang juga tidak akan mengirim cookie, tetapi tetap mencoba pengambilan data di awal—yang akan menghasilkan pengambilan data di awal yang sia-sia dan perlu dikirim ulang atau, lebih buruk lagi, pemuatan halaman yang salah.

Mendeteksi dukungan Speculation Rules API

Anda dapat mendeteksi fitur dukungan Speculation Rules API dengan pemeriksaan HTML standar:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Menambahkan aturan spekulasi secara dinamis melalui JavaScript

Berikut adalah contoh penambahan aturan spekulasi prerender dengan JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Anda dapat melihat demo pra-rendering Speculation Rules API, menggunakan penyisipan JavaScript, di halaman demo pra-render ini.

Menyisipkan elemen <script type = "speculationrules"> langsung ke DOM menggunakan innerHTML tidak akan mendaftarkan aturan spekulasi karena alasan keamanan dan ini harus ditambahkan seperti yang ditunjukkan sebelumnya. Namun, konten yang disisipkan secara dinamis menggunakan innerHTML yang berisi link baru, akan diambil oleh aturan yang ada di halaman.

Demikian pula, pengeditan langsung panel Elements di Chrome DevTools untuk menambahkan elemen <script type = "speculationrules"> tidak akan mendaftarkan aturan spekulasi. Sebagai gantinya, skrip untuk menambahkan aturan ini secara dinamis ke DOM harus dijalankan dari Konsol untuk menyisipkan aturan.

Menambahkan aturan spekulasi melalui Tag Manager

Untuk menambahkan aturan spekulasi menggunakan pengelola tag seperti Google Tag Manager (GTM), aturan ini harus disisipkan melalui JavaScript, bukan menambahkan elemen <script type = "speculationrules"> melalui GTM secara langsung karena alasan yang sama seperti yang disebutkan sebelumnya:

Konfigurasi tag HTML kustom di Google Tag Manager
Menambahkan Aturan Spekulasi melalui Google Tag Manager.

Perhatikan bahwa contoh ini menggunakan var karena GTM tidak mendukung const.

Membatalkan aturan spekulasi

Menghapus aturan spekulasi akan menyebabkan pra-rendering dibatalkan. Namun, pada saat hal ini terjadi, resource kemungkinan sudah digunakan untuk memulai pra-rendering, jadi sebaiknya jangan melakukan pra-rendering jika ada kemungkinan perlu membatalkan pra-rendering. Di sisi lain, resource yang di-cache masih dapat digunakan kembali sehingga pembatalan mungkin tidak sepenuhnya sia-sia dan masih dapat bermanfaat untuk spekulasi dan navigasi di masa mendatang.

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Spekulasi juga dapat dibatalkan menggunakan header HTTP Clear-Site-Data dengan perintah prefetchCache dan prerenderCache.

Hal ini dapat berguna saat status diubah di server. Misalnya, saat memanggil API "tambahkan ke keranjang" atau API login atau logout.

Idealnya, update status ini akan disebarkan ke halaman yang dipra-render menggunakan API seperti Broadcast Channel API, tetapi jika hal ini tidak memungkinkan, atau hingga logika tersebut diterapkan, membatalkan spekulasi dapat lebih mudah.

Aturan spekulasi dan Kebijakan Keamanan Konten

Karena aturan spekulasi menggunakan elemen <script>, meskipun hanya berisi JSON, aturan tersebut harus disertakan dalam script-src Content-Security-Policy jika situs menggunakannya—baik menggunakan hash maupun nonce.

inline-speculation-rules baru dapat ditambahkan ke script-src sehingga memungkinkan elemen <script type="speculationrules"> yang dimasukkan dari skrip hash atau nonce didukung. Hal ini tidak mendukung aturan yang disertakan dalam HTML awal, sehingga aturan perlu dimasukkan oleh JavaScript untuk situs yang menggunakan CSP ketat.

Mendeteksi dan menonaktifkan pra-rendering

Pra-rendering biasanya memberikan pengalaman positif bagi pengguna karena memungkinkan rendering halaman yang cepat, bahkan sering kali instan. Hal ini menguntungkan pengguna dan pemilik situs, karena halaman yang dipra-render memungkinkan pengalaman pengguna yang lebih baik yang mungkin sulit dicapai dengan cara lain.

Namun, mungkin ada situasi saat Anda tidak ingin pra-rendering halaman terjadi, misalnya saat halaman berubah status—baik berdasarkan permintaan awal, atau berdasarkan JavaScript yang dieksekusi di halaman.

Mengaktifkan dan menonaktifkan pra-rendering di Chrome

Pra-rendering hanya diaktifkan untuk pengguna Chrome yang mengaktifkan setelan "Pra-pemuatan halaman" di chrome://settings/performance/. Selain itu, pra-render juga dinonaktifkan di perangkat dengan memori rendah, atau jika sistem operasi berada dalam mode Hemat data atau Penghemat energi. Lihat bagian Batas Chrome.

Mendeteksi dan menonaktifkan pra-rendering sisi server

Halaman yang dipra-render akan dikirim dengan header HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Halaman yang diambil datanya menggunakan Speculation Rules API akan memiliki header ini yang ditetapkan ke prefetch saja:

Sec-Purpose: prefetch

Server dapat merespons berdasarkan header ini, untuk mencatat permintaan spekulasi, menampilkan konten yang berbeda, atau mencegah terjadinya pra-rendering. Jika kode respons akhir yang tidak berhasil ditampilkan—yaitu, tidak dalam rentang 200-299 setelah pengalihan—halaman tidak akan dipra-render dan halaman pengambilan data di awal akan dihapus. Perhatikan juga bahwa respons 204 dan 205 juga tidak valid untuk pra-rendering, tetapi valid untuk pengambilan data di awal.

Jika Anda tidak ingin halaman tertentu dipra-render, menampilkan kode respons non-2XX (seperti 503) adalah cara terbaik untuk memastikan hal tersebut tidak terjadi. Namun, untuk memberikan pengalaman terbaik, sebaiknya izinkan pra-rendering, tetapi tunda tindakan apa pun yang seharusnya hanya terjadi saat halaman benar-benar dilihat, menggunakan JavaScript.

Mendeteksi pra-render di JavaScript

document.prerendering API akan menampilkan true saat halaman sedang melakukan pra-rendering. Hal ini dapat digunakan oleh halaman untuk mencegah—atau menunda—aktivitas tertentu selama pra-rendering hingga halaman benar-benar diaktifkan.

Setelah dokumen yang dipra-render diaktifkan, activationStart PerformanceNavigationTiming juga akan ditetapkan ke waktu bukan nol yang menunjukkan waktu antara saat pra-render dimulai dan dokumen benar-benar diaktifkan.

Anda dapat memiliki fungsi untuk memeriksa halaman yang di-pra-render dan pra-rendering seperti berikut:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

Cara termudah untuk melihat apakah halaman telah dipra-render (baik secara penuh maupun sebagian) adalah dengan membuka DevTools setelah halaman diaktifkan dan mengetik performance.getEntriesByType('navigation')[0].activationStart di konsol. Jika nilai selain nol ditampilkan, Anda tahu bahwa halaman telah dipra-render:

Konsol di Chrome DevTools menampilkan activationStart positif yang menunjukkan bahwa halaman telah dipra-render
Menguji pra-rendering di konsol.

Saat halaman diaktifkan oleh pengguna yang melihat halaman, peristiwa prerenderingchange akan dikirim di document, yang kemudian dapat digunakan untuk mengaktifkan aktivitas yang sebelumnya akan dimulai secara default saat pemuatan halaman, tetapi ingin Anda tunda hingga halaman benar-benar dilihat oleh pengguna.

Dengan menggunakan API ini, JavaScript frontend dapat mendeteksi dan bertindak berdasarkan halaman yang dipra-render dengan tepat.

Dampak pada analisis

Analisis digunakan untuk mengukur penggunaan situs, misalnya menggunakan Google Analytics untuk mengukur kunjungan halaman dan peristiwa. Atau dengan mengukur metrik performa halaman menggunakan Pemantauan Pengguna Nyata (RUM).

Halaman hanya boleh dipra-render jika ada kemungkinan besar halaman tersebut akan dimuat oleh pengguna. Inilah alasan opsi pra-rendering kolom URL Chrome hanya terjadi jika ada probabilitas yang sangat tinggi (lebih dari 80%).

Namun, terutama saat menggunakan Speculation Rules API, halaman yang dipramuat dapat berdampak pada analisis dan pemilik situs mungkin perlu menambahkan kode tambahan untuk hanya mengaktifkan analisis untuk halaman yang dipramuat saat aktivasi, karena tidak semua penyedia analisis dapat melakukannya secara default.

Hal ini dapat dicapai dengan menggunakan Promise yang menunggu peristiwa prerenderingchange jika dokumen sedang dipra-render, atau segera diselesaikan jika sekarang:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Pendekatan alternatifnya adalah menunda aktivitas analisis hingga halaman pertama kali terlihat, yang akan mencakup kasus pra-rendering, dan juga saat tab dibuka di latar belakang (misalnya, dengan klik kanan dan buka di tab baru):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Meskipun hal ini mungkin masuk akal untuk analisis dan kasus penggunaan serupa, dalam kasus lain, Anda mungkin ingin lebih banyak konten dimuat untuk kasus tersebut, sehingga mungkin ingin menggunakan document.prerendering dan prerenderingchange untuk menargetkan halaman pra-rendering secara khusus.

Menahan konten lain selama pra-rendering

API yang sama seperti yang dibahas sebelumnya dapat digunakan untuk menahan konten lain selama fase pra-rendering. Hal ini dapat berupa bagian tertentu dari JavaScript atau seluruh elemen skrip yang tidak ingin Anda jalankan selama tahap pra-rendering.

Misalnya, dengan skrip ini:

<script src="https://example.com/app/script.js" async></script>

Anda dapat mengubahnya menjadi elemen skrip yang disisipkan secara dinamis yang hanya disisipkan berdasarkan fungsi whenActivated sebelumnya:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Hal ini dapat berguna untuk menahan skrip berbeda yang menyertakan analisis, atau merender konten berdasarkan status atau variabel lain yang dapat berubah selama kunjungan. Misalnya, rekomendasi, atau status login, atau ikon keranjang belanja dapat ditahan untuk memastikan informasi terbaru ditampilkan.

Meskipun hal ini mungkin lebih sering terjadi dengan penggunaan pra-rendering, kondisi ini juga berlaku untuk halaman yang dimuat di tab latar belakang yang disebutkan sebelumnya (sehingga fungsi whenFirstVisible dapat digunakan sebagai pengganti whenActivated).

Dalam banyak kasus, status idealnya juga harus diperiksa pada perubahan visibilitychange umum—misalnya, saat kembali ke halaman yang telah berada di latar belakang, penghitung keranjang belanja harus diperbarui dengan jumlah item terbaru di keranjang. Jadi, ini bukan masalah khusus pra-rendering, tetapi pra-rendering hanya membuat masalah yang ada menjadi lebih jelas.

Salah satu cara Chrome mengurangi kebutuhan untuk menggabungkan skrip atau fungsi secara manual adalah dengan menahan API tertentu seperti yang disebutkan sebelumnya, dan juga iframe pihak ketiga tidak dirender, sehingga hanya konten di atasnya yang perlu ditahan secara manual.

Mengukur performa

Untuk mengukur metrik performa, analisis harus mempertimbangkan apakah lebih baik mengukur metrik ini berdasarkan waktu aktivasi, bukan waktu pemuatan halaman yang akan dilaporkan oleh API browser.

Untuk Core Web Vitals, yang diukur oleh Chrome melalui Chrome User Experience Report, metrik ini dimaksudkan untuk mengukur pengalaman pengguna. Jadi, ini diukur berdasarkan waktu aktivasi. Hal ini sering kali akan menghasilkan LCP 0 detik, misalnya, yang menunjukkan bahwa ini adalah cara yang bagus untuk meningkatkan Core Web Vitals Anda.

Mulai versi 3.1.0, library web-vitals telah diupdate untuk menangani navigasi yang diprarender dengan cara yang sama seperti Chrome mengukur Core Web Vitals. Versi ini juga menandai navigasi yang dipra-render untuk metrik tersebut dalam atribut Metric.navigationType jika halaman dipra-render sepenuhnya atau sebagian.

Mengukur pra-rendering

Apakah halaman di-pra-render dapat dilihat dengan entri activationStart bukan nol dari PerformanceNavigationTiming. Hal ini kemudian dapat dicatat ke dalam log menggunakan Dimensi Kustom, atau yang serupa saat mencatat kunjungan halaman ke dalam log, misalnya menggunakan fungsi pagePrerendered yang dijelaskan sebelumnya:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Hal ini akan memungkinkan analisis Anda menampilkan jumlah navigasi yang dipra-render dibandingkan dengan jenis navigasi lainnya, dan juga memungkinkan Anda menghubungkan metrik performa atau metrik bisnis apa pun dengan berbagai jenis navigasi ini. Halaman yang lebih cepat berarti pengguna yang lebih puas, yang sering kali dapat memberikan dampak nyata pada ukuran bisnis seperti yang ditunjukkan oleh studi kasus kami.

Saat mengukur dampak bisnis dari pra-rendering halaman untuk navigasi instan, Anda dapat memutuskan apakah perlu menginvestasikan lebih banyak upaya dalam menggunakan teknologi ini untuk memungkinkan lebih banyak navigasi di-pra-render, atau untuk menyelidiki alasan halaman tidak di-pra-render.

Mengukur rasio hit

Selain mengukur dampak halaman yang dikunjungi setelah pra-rendering, penting juga untuk mengukur halaman yang di-pra-render dan tidak dikunjungi setelahnya. Hal ini dapat berarti Anda melakukan pra-rendering terlalu banyak, dan menghabiskan resource berharga pengguna untuk manfaat yang kecil.

Hal ini dapat diukur dengan mengaktifkan peristiwa analisis saat aturan spekulasi disisipkan—setelah memeriksa apakah browser mendukung pra-rendering menggunakan HTMLScriptElement.supports('speculationrules')—untuk menunjukkan bahwa pra-rendering diminta. (Perhatikan bahwa permintaan pra-rendering tidak berarti pra-rendering telah dimulai atau selesai karena, seperti yang telah disebutkan sebelumnya, pra-rendering adalah petunjuk bagi browser dan browser dapat memilih untuk tidak melakukan pra-rendering halaman berdasarkan setelan pengguna, penggunaan memori saat ini, atau heuristik lainnya.)

Kemudian, Anda dapat membandingkan jumlah peristiwa ini dengan tayangan halaman pra-render yang sebenarnya. Atau, picu peristiwa lain saat aktivasi jika hal itu memudahkan perbandingan.

"Rasio hit yang berhasil" kemudian dapat diperkirakan dengan melihat perbedaan antara kedua angka ini. Untuk halaman tempat Anda menggunakan Speculation Rules API untuk melakukan pra-rendering halaman, Anda dapat menyesuaikan aturan dengan tepat untuk memastikan Anda mempertahankan rasio hit yang tinggi guna menjaga keseimbangan antara menggunakan resource pengguna untuk membantu mereka, versus menggunakannya tanpa perlu.

Perhatikan bahwa beberapa pra-rendering mungkin terjadi karena pra-rendering kolom URL, bukan hanya aturan spekulasi Anda. Anda dapat memeriksa document.referrer (yang akan kosong untuk navigasi kolom URL, termasuk navigasi kolom URL yang diprarender) jika ingin membedakannya.

Ingatlah untuk juga melihat halaman yang tidak memiliki pra-rendering, karena hal itu dapat menunjukkan bahwa halaman tersebut tidak memenuhi syarat untuk pra-rendering, bahkan dari kolom URL. Artinya, Anda mungkin tidak mendapatkan manfaat dari peningkatan performa ini. Tim Chrome ingin menambahkan alat tambahan untuk menguji kelayakan Pra-rendering, mungkin mirip dengan alat pengujian bfcache, dan juga berpotensi menambahkan API untuk mengekspos alasan kegagalan pra-rendering.

Dampak terhadap ekstensi

Lihat postingan khusus tentang Ekstensi Chrome: Memperluas API untuk mendukung Navigasi Instan yang menjelaskan beberapa pertimbangan tambahan yang mungkin perlu dipikirkan oleh pembuat ekstensi untuk halaman yang dipra-render.

Masukan

Pra-rendering sedang dalam pengembangan aktif oleh tim Chrome, dan ada banyak rencana untuk memperluas cakupan hal-hal yang telah tersedia dalam rilis Chrome 108. Kami menerima masukan apa pun di repo GitHub atau menggunakan issue tracker kami, dan berharap dapat mendengar serta membagikan studi kasus API baru yang menarik ini.

Ucapan terima kasih

Gambar thumbnail oleh Marc-Olivier Jodoin di Unsplash