Melakukan pra-render halaman di Chrome untuk navigasi halaman instan

Barry Pollard

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

Sejarah singkat pra-rendering

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 ini menggunakan petunjuk rel=prerender link tidak digunakan lagi dan diganti dengan Pengambilan Data NoState, yang mengambil resource yang diperlukan oleh halaman mendatang, tetapi tidak melakukan pra-rendering halaman sepenuhnya atau menjalankan JavaScript. Pengambilan Data NoState memang membantu meningkatkan performa halaman dengan meningkatkan pemuatan resource, tetapi tidak akan memberikan pemuatan halaman seketika 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-render baru ini tidak akan menggunakan sintaksis <link rel="prerender"...>, yang tetap ada untuk Pengambilan Data NoState, dengan tujuan untuk menghentikannya pada suatu saat di masa mendatang.

Bagaimana cara halaman dipra-render?

Halaman dapat diprarender 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-rendering halaman untuk Anda, jika Chrome memiliki keyakinan tinggi bahwa Anda akan mengunjungi halaman tersebut, berdasarkan histori penjelajahan Anda sebelumnya.
2. Saat Anda menggunakan panel bookmark, Chrome dapat otomatis melakukan pra-rendering halaman untuk Anda dengan 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 diminta untuk melakukannya oleh mesin telusur.
4. Situs dapat menggunakan Speculation Rules API, untuk memberi tahu Chrome secara terprogram halaman mana yang akan dipra-render. Hal ini menggantikan fungsi <link rel="prerender"...> sebelumnya dan memungkinkan situs melakukan pra-rendering halaman secara proaktif berdasarkan aturan spekulasi di halaman. Elemen ini dapat ada secara statis di halaman, atau dimasukkan secara dinamis oleh JavaScript sesuai keinginan pemilik halaman.

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

Saat halaman yang dipra-render dibuka dalam status tersembunyi, sejumlah API yang menyebabkan perilaku yang mengganggu (misalnya, perintah) tidak diaktifkan dalam status ini, dan malah ditunda hingga halaman diaktifkan. Dalam beberapa kasus yang kecil, jika hal ini belum memungkinkan, pra-rendering akan dibatalkan. Tim Chrome sedang berusaha mengekspos alasan pembatalan pra-render 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 situs ini sudah cepat, tetapi meskipun demikian, Anda dapat melihat bagaimana pra-rendering meningkatkan pengalaman pengguna. Oleh karena itu, hal ini juga dapat berdampak langsung pada Data Web Inti situs, dengan LCP mendekati nol, CLS yang berkurang (karena CLS pemuatan terjadi sebelum tampilan awal), dan INP yang lebih baik (karena pemuatan harus selesai sebelum pengguna berinteraksi).

Meskipun halaman diaktifkan sebelum dimuat sepenuhnya, memiliki pra-render untuk pemuatan halaman akan meningkatkan pengalaman pemuatan. Ketika link diaktifkan ketika pra-rendering masih terjadi, halaman pra-rendering akan berpindah ke bingkai utama dan melanjutkan pemuatan.

Namun, pra-rendering menggunakan memori dan bandwidth jaringan tambahan. Berhati-hatilah agar tidak melakukan pra-rendering secara berlebihan, yang akan menghabiskan resource pengguna. Hanya pra-render jika ada kemungkinan tinggi halaman akan dibuka.

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

Melihat prediksi kolom URL Chrome

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

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

Screenshot ini diambil pada penginstalan Chrome yang relatif baru, dan memfilter prediksi dengan 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.

Alat prediksi ini jugalah yang mendorong opsi yang disarankan kolom URL yang mungkin Anda lihat:

Chrome akan terus memperbarui prediktornya berdasarkan pengetikan dan pilihan Anda.

• Untuk tingkat keyakinan lebih dari 50% (ditampilkan dalam warna kuning), Chrome akan melakukan prakoneksi secara proaktif ke domain, tetapi tidak melakukan pra-rendering halaman.
• Untuk tingkat keyakinan lebih dari 80% (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:

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

Atau dengan aturan dokumen (tersedia dari Chrome 121), yang melakukan pra-rendering link yang ditemukan dalam dokumen berdasarkan pemilih href (berdasarkan URL Pattern API) 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>

Tim Chrome telah menyiapkan Codelab Aturan Spekulasi yang akan memandu Anda menambahkan Aturan Spekulasi ke situs.

Keinginan

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

• immediate: Tingkat ini digunakan untuk menerapkan spekulasi sesegera mungkin, yaitu tepat setelah aturan spekulasi diamati.
• eager: Tingkat ini berperilaku serupa dengan setelan immediate, tetapi kami akan menempatkannya di antara immediate dan moderate pada masa mendatang.
• moderate: Tingkat ini menerapkan spekulasi jika Anda menahan pointer di atas link selama 200 milidetik (atau pada peristiwa pointerdown jika lebih cepat, dan pada perangkat seluler yang tidak menggunakan peristiwa hover).
• conservative: Fungsi ini berspekulasi pada pointer atau touch down.

eagerness default untuk aturan list adalah immediate. Opsi 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 sesuai.

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

Setelan eagerness yang akan digunakan bergantung pada situs Anda. Untuk situs statis yang ringan, berspekulasi dengan lebih cepat mungkin tidak akan menimbulkan banyak biaya dan bermanfaat bagi pengguna. Situs dengan arsitektur yang lebih kompleks dan payload halaman yang lebih berat mungkin lebih memilih untuk mengurangi pemborosan dengan lebih jarang berspekulasi hingga Anda mendapatkan sinyal niat yang lebih positif 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 pointer diarahkan ke link selama 200 milidetik atau pada peristiwa pointerdown sebagai implementasi dasar—tetapi efektif—dari aturan spekulasi:

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

Prefetch

Aturan spekulasi juga dapat digunakan untuk hanya melakukan pramuat halaman, tanpa pra-rendering penuh. Hal ini sering kali menjadi langkah pertama yang baik dalam proses pra-rendering:

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

Batas Chrome

Chrome memiliki batas untuk mencegah penggunaan berlebihan Speculation Rules API:

Setelan 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 diganti dengan 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 di-spekulasi ulang, sehingga spekulasi yang paling lama akan dihapus. Dalam hal ini, spekulasi sebelumnya akan meng-cache resource yang dapat di-cache di Cache HTTP untuk URL tersebut sehingga spekulasi pada waktu yang lebih lama akan memiliki biaya yang lebih rendah. Itulah sebabnya batas ditetapkan ke nilai minimum 2. Aturan daftar statis tidak dipicu oleh tindakan pengguna sehingga memiliki batas yang lebih tinggi karena browser tidak mungkin mengetahui mana yang diperlukan dan kapan diperlukan.

Batas immediate dan eager juga 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 saat diaktifkan dan daya baterai lemah.
• Batasan memori.
• Jika setelan "Preload 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 akan 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 sering kali 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.

Bagi yang lebih menyukai penyisipan dinamis berdasarkan tindakan seperti mengarahkan kursor, atau mengklik link—seperti yang telah dilakukan banyak library sebelumnya dengan <link rel=prefetch>—sebaiknya lihat aturan dokumen, karena aturan ini memungkinkan browser menangani banyak kasus penggunaan Anda.

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

Header HTTP Speculation-Rules

Aturan spekulasi juga dapat ditayangkan menggunakan header HTTP Speculation-Rules, bukan menyertakannya langsung di HTML dokumen. Hal ini memungkinkan deployment yang lebih mudah oleh CDN tanpa perlu mengubah konten dokumen itu sendiri.

Header HTTP Speculation-Rules ditampilkan dengan 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-asal, lulus pemeriksaan CORS.

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

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

Aturan spekulasi dan SPA

Aturan spekulasi hanya didukung untuk navigasi halaman penuh yang dikelola oleh browser, dan bukan untuk halaman Aplikasi Web Satu Halaman (SPA) atau shell aplikasi. Arsitektur ini tidak menggunakan pengambilan dokumen, tetapi membuat API atau pengambilan parsial dari data atau halaman—yang kemudian diproses dan ditampilkan di halaman saat ini. Data yang diperlukan untuk "navigasi lembut" ini dapat diambil sebelumnya oleh aplikasi di luar aturan spekulasi, tetapi tidak dapat dirender sebelumnya.

Aturan Spekulasi dapat digunakan untuk melakukan pra-rendering aplikasi itu sendiri dari halaman sebelumnya. Hal ini dapat membantu mengurangi 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 aturan spekulasi proses debug, untuk fitur Chrome DevTools baru guna membantu melihat dan men-debug API baru ini.

Beberapa aturan spekulasi

Beberapa aturan spekulasi juga dapat ditambahkan ke halaman yang sama, dan ditambahkan ke aturan yang ada. Oleh karena itu, berbagai cara berikut semuanya 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 kumpulan speculationrules

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

Dukungan No-Vary-Search

Saat melakukan pramuat 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 yang berbeda yang dikirim dari server. Ini berarti 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 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 dengan parameter ini. Hal ini didukung di Chrome (dan browser berbasis Chromium) untuk spekulasi navigasi pengambilan data (meskipun kami ingin mendukung hal ini untuk pra-rendering juga).

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

<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 akan berbeda berdasarkan rendering sisi klien menggunakan JavaScript untuk mengambil data produk menggunakan parameter penelusuran id. Jadi, kita mengambil data URL tersebut dengan segera dan URL akan menampilkan header HTTP No-Vary-Search yang menampilkan halaman dapat digunakan untuk parameter penelusuran id apa pun.

Namun, jika pengguna mengklik link sebelum pengambilan data selesai, browser mungkin belum menerima halaman /products. Dalam hal ini, browser tidak tahu apakah akan berisi header HTTP No-Vary-Search. Browser kemudian memiliki pilihan untuk mengambil link lagi, atau menunggu pramuat 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 prefetch tersebut selesai.

Pembatasan aturan spekulasi dan peningkatan di masa mendatang

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

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

Versi mendatang juga dapat mengizinkan pra-rendering untuk halaman lintas origin yang tidak sama selama cookie tidak ada untuk halaman yang dipra-render dan halaman yang dipra-render memilih untuk menggunakan header HTTP Supports-Loading-Mode: uncredentialed-prerender yang serupa.

Aturan spekulasi sudah mendukung pengambilan data lintas-asal, tetapi sekali lagi hanya jika cookie untuk domain lintas-asal tidak ada. Jika cookie ada dari pengguna yang telah mengunjungi situs tersebut sebelumnya, spekulasi tidak akan dipicu dan akan menampilkan kegagalan di DevTools.

Dengan batasan saat ini, satu pola yang dapat meningkatkan pengalaman pengguna Anda untuk link internal dan link eksternal jika memungkinkan adalah melakukan pra-rendering URL origin yang sama dan mencoba melakukan pengambilan data 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 dari <link rel="prefetch"> untuk tujuan lintas origin yang juga tidak akan mengirim cookie, tetapi tetap mencoba prefetch—yang akan menghasilkan prefetch yang terbuang dan perlu dikirim ulang atau, lebih buruk lagi, pemuatan halaman yang salah.

Aturan spekulasi tidak didukung untuk pengambilan data halaman yang dikontrol oleh pekerja layanan. Kami sedang berupaya menambahkan dukungan ini. Ikuti Dukung masalah pekerja layanan ini untuk mendapatkan info terbaru. Pra-rendering didukung untuk halaman yang dikontrol pekerja layanan.

Dukungan Detect Speculation Rules API

Anda dapat mendeteksi 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-rendering 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, mengedit langsung panel Elements di Chrome DevTools untuk menambahkan elemen <script type = "speculationrules"> tidak akan mendaftarkan aturan spekulasi. Sebagai gantinya, skrip untuk menambahkannya 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 tersebut harus disisipkan melalui JavaScript, bukan menambahkan elemen <script type = "speculationrules"> melalui GTM secara langsung karena alasan yang sama seperti yang disebutkan sebelumnya:

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

Batalkan aturan spekulasi

Menghapus aturan spekulasi akan mengakibatkan pra-rendering dibatalkan, tetapi, pada saat hal ini terjadi, resource kemungkinan telah digunakan untuk memulai pra-rendering. Oleh karena itu, sebaiknya jangan melakukan pra-rendering jika ada kemungkinan untuk membatalkan pra-render.

Aturan spekulasi dan Kebijakan Keamanan Konten

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

inline-speculation-rules baru dapat ditambahkan ke script-src, sehingga elemen <script type="speculationrules"> yang dimasukkan dari skrip hash atau non-ced dapat didukung. Hal ini tidak mendukung aturan yang disertakan dalam HTML awal sehingga aturan harus 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—sering kali instan. Hal ini menguntungkan pengguna dan pemilik situs, karena halaman yang dirender sebelumnya memungkinkan pengalaman pengguna yang lebih baik yang mungkin sulit dicapai jika tidak.

Namun, mungkin ada kasus 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 tersebut dengan setelan "Muat halaman secara otomatis" di chrome://settings/performance/. Selain itu, pra-rendering juga dinonaktifkan di perangkat dengan memori rendah, atau jika sistem operasi dalam mode Penghemat data atau Penghemat energi. Lihat bagian Batas Chrome.

Mendeteksi dan menonaktifkan pra-rendering sisi server

Halaman yang dirender sebelumnya akan dikirim dengan header HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Halaman yang diambil sebelumnya menggunakan Speculation Rules API akan memiliki header ini yang disetel hanya ke prefetch:

Sec-Purpose: prefetch

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

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

Mendeteksi pra-rendering di JavaScript

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

Setelah dokumen pra-rendering diaktifkan, activationStart PerformanceNavigationTiming juga akan disetel ke waktu non-nol yang mewakili waktu antara saat pra-rendering dimulai dan dokumen benar-benar diaktifkan.

Anda dapat memiliki fungsi untuk memeriksa halaman pra-rendering dan pra-dirender seperti berikut:

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

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

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 halaman dimuat, tetapi yang ingin Anda tunda hingga halaman benar-benar dilihat oleh pengguna.

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

Dampak pada analisis

Analytics digunakan untuk mengukur penggunaan situs, misalnya menggunakan Google Analytics untuk mengukur kunjungan halaman dan peristiwa. Atau dengan mengukur metrik performa halaman menggunakan Real User Monitoring (RUM).

Halaman hanya boleh dipra-render jika ada kemungkinan tinggi bahwa halaman akan dimuat oleh pengguna. Itulah sebabnya opsi pra-rendering kolom URL Chrome hanya terjadi jika ada probabilitas yang tinggi (lebih dari 80% waktu).

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

Hal ini dapat dicapai dengan menggunakan Promise yang menunggu peristiwa prerenderingchange jika dokumen dipra-render, atau langsung di-resolve 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 mengklik kanan dan membuka 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 sebaiknya gunakan document.prerendering dan prerenderingchange untuk menargetkan halaman pra-rendering secara khusus.

Menahan konten lain selama pra-rendering

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

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 rentang kunjungan. Misalnya, rekomendasi, 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 memitigasi beberapa 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 mengukurnya berdasarkan waktu aktivasi, bukan waktu pemuatan halaman yang akan dilaporkan oleh API browser.

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

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

Mengukur pra-rendering

Apakah halaman dipra-render dapat dilihat dengan entri activationStart PerformanceNavigationTiming yang bukan nol. Hal ini kemudian dapat dicatat ke dalam log menggunakan Dimensi Kustom, atau yang serupa saat mencatat kunjungan halaman, 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 mengaitkan metrik performa atau metrik bisnis dengan berbagai jenis navigasi ini. Halaman yang lebih cepat berarti pengguna yang lebih puas, yang sering kali dapat berdampak nyata pada ukuran bisnis seperti yang ditunjukkan dalam studi kasus kami.

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

Mengukur rasio hit

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

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

Kemudian, Anda dapat membandingkan jumlah peristiwa ini dengan kunjungan halaman pra-rendering yang sebenarnya. Atau, aktifkan peristiwa lain saat aktivasi jika hal itu mempermudah 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 dirender sebelumnya) jika ingin membedakannya.

Jangan lupa untuk melihat halaman yang tidak memiliki pra-rendering, karena hal ini 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 mengungkap alasan pra-rendering gagal.

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 penulis ekstensi untuk halaman yang dirender sebelumnya.

Masukan

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

Link terkait

• Codelab Aturan Spekulasi
• Melakukan proses debug aturan spekulasi
• Memperkenalkan Pengambilan Data NoState
• Spesifikasi Speculation Rules API
• Repo GitHub spekulasi Navigasi
• Ekstensi Chrome: Memperluas API untuk mendukung Navigasi Instan

Ucapan terima kasih

Gambar thumbnail oleh Marc-Olivier Jodoin di Unsplash