Melakukan pra-render halaman di Chrome untuk navigasi halaman instan

Barry Pollard

Dukungan Browser

  • 109
  • 109
  • x
  • x

Tim Chrome telah mengembalikan pra-rendering penuh dari halaman mendatang yang kemungkinan akan dibuka oleh pengguna.

Histori 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 yang menggunakan petunjuk link rel=prerender ini tidak digunakan lagi dan digantikan oleh NoState Prefetch, yang justru mengambil resource yang diperlukan oleh halaman mendatang, tetapi tidak sepenuhnya melakukan pra-rendering halaman atau menjalankan JavaScript. Pengambilan Data NoState membantu meningkatkan performa halaman dengan meningkatkan pemuatan resource, tetapi tidak akan menghasilkan pemuatan halaman instan seperti pra-rendering penuh.

Tim Chrome kini telah memperkenalkan kembali pra-rendering penuh ke Chrome. Untuk menghindari kerumitan dengan penggunaan yang ada, dan untuk memungkinkan perluasan pra-rendering baru, mekanisme pra-render baru ini tidak akan menggunakan sintaksis <link rel="prerender"...>, yang tetap berlaku untuk Pengambilan Data NoState, dengan rencana untuk menghentikannya pada masa mendatang.

Bagaimana halaman dipra-render?

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

  1. Saat Anda mengetikkan URL di kolom URL Chrome (juga dikenal sebagai "omnibox"), Chrome dapat melakukan pra-rendering halaman secara otomatis untuk Anda, jika sangat yakin Anda akan mengunjungi halaman tersebut.
  2. Saat Anda menggunakan kolom bookmark, Chrome dapat melakukan pra-rendering halaman secara otomatis untuk Anda dengan mengarahkan kursor ke salah satu tombol bookmark.
  3. Saat Anda mengetik istilah penelusuran di kolom URL Chrome, Chrome dapat melakukan pra-rendering halaman hasil penelusuran secara otomatis, saat diminta oleh mesin telusur.
  4. Situs dapat menggunakan Speculation Rules API untuk memberi tahu Chrome halaman mana yang akan dipra-render secara terprogram. Hal ini menggantikan fungsi yang biasa dilakukan <link rel="prerender"...> dan memungkinkan situs melakukan pra-rendering halaman secara proaktif berdasarkan aturan spekulasi di halaman tersebut. Link ini dapat tersedia secara statis di halaman, atau dimasukkan secara dinamis oleh JavaScript sesuai kebutuhan 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 pra-rendering tersebut. Jika halaman diaktifkan sebelum pra-rendering sepenuhnya, status saat ini adalah "latar depan" dan terus dimuat, yang berarti Anda masih dapat memulai lebih awal dengan baik.

Saat halaman pra-rendering dibuka dalam status tersembunyi, sejumlah API yang menyebabkan perilaku mengganggu (misalnya, perintah) tidak diaktifkan dalam status ini, dan ditunda hingga halaman diaktifkan. Dalam sejumlah kecil kasus yang belum memungkinkan hal ini, pra-rendering 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 dampak pra-rendering.

Situs contoh ini sudah menjadi situs yang cepat, tetapi meskipun dengan ini 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 hampir nol, CLS lebih rendah (karena semua CLS pemuatan terjadi sebelum tampilan awal), dan peningkatan INP (karena pemuatan harus selesai sebelum pengguna berinteraksi).

Meskipun halaman aktif sebelum dimuat sepenuhnya, pemuatan halaman lebih awal dapat 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 tambahan dan bandwidth jaringan. Hati-hati, jangan melakukan pra-rendering secara berlebihan, tetapi dapat merugikan resource pengguna. Hanya lakukan pra-rendering saat ada kemungkinan besar halaman akan dibuka.

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

Melihat prediksi kolom URL Chrome

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

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

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

Screenshot ini diambil di penginstalan Chrome yang relatif baru, dan memfilter prediksi dengan tingkat keyakinan nol. Namun, jika Anda melihat prediktor sendiri, Anda mungkin akan melihat lebih banyak entri, dan kemungkinan 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:

Fitur &#39;Typeahead&#39; pada kolom URL Chrome
Fitur 'Typeahead' di kolom URL.

Chrome akan terus mengupdate prediktornya berdasarkan ketikan dan pilihan Anda.

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

Speculation Rules API

Untuk opsi pra-render ketiga, developer web dapat memasukkan petunjuk JSON ke halaman mereka untuk memberi tahu browser tentang URL mana yang akan dipra-render:

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

Atau berdasarkan 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 dalam menambahkan Aturan Spekulasi ke situs.

Kegembiraan

Dukungan Browser

  • 121
  • 121
  • x
  • x

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

  • immediate: Hal ini digunakan untuk berspekulasi sesegera mungkin, yaitu segera setelah aturan spekulasi diamati.
  • eager: Perilaku ini identik dengan setelan immediate, tetapi pada masa mendatang, kita ingin menempatkannya di antara immediate dan moderate.
  • moderate: Fungsi ini melakukan spekulasi jika Anda mengarahkan pointer ke link selama 200 milidetik (atau pada peristiwa pointerdown jika lebih cepat, dan di perangkat seluler saat tidak ada 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 memerlukan sedikit biaya dan bermanfaat bagi pengguna. Situs dengan arsitektur yang lebih kompleks dan payload halaman yang lebih berat mungkin lebih memilih mengurangi pemborosan dengan mengurangi frekuensi spekulasi sampai Anda mendapatkan sinyal niat yang lebih positif dari pengguna untuk membatasi pemborosan.

Opsi moderate adalah jalan tengah, dan banyak situs dapat memperoleh manfaat dari aturan spekulasi berikut yang akan melakukan pra-rendering link saat mengarahkan kursor ke link selama 200 milidetik atau pada peristiwa pointerdown sebagai implementasi aturan spekulasi dasar—namun andal::

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

Prefetch

Aturan spekulasi juga dapat digunakan untuk mengambil data halaman saja, tanpa pra-rendering penuh. Hal ini sering kali bisa menjadi langkah pertama yang baik untuk melakukan pra-rendering:

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

Batas Chrome

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

keinginan Prefetch Pra-rendering
immediate/eager 50 10
moderate/conservative 2 (FIFO) 2 (FIFO)
Batas spekulasi di Chrome.

Setelan moderate dan conservative—yang bergantung pada interaksi pengguna—bekerja dengan cara Pertama Masuk, Keluar Pertama (FIFO): setelah mencapai batas, spekulasi baru akan menyebabkan spekulasi terlama dibatalkan dan diganti dengan 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 dispekulasi ulang, sehingga mendorong spekulasi terlama. Dalam kasus ini, spekulasi sebelumnya akan meng-cache semua resource yang dapat di-cache dalam Cache HTTP untuk URL tersebut, sehingga berspekulasi lebih lama akan menghasilkan biaya yang lebih rendah. Oleh karena itu, batas tersebut ditetapkan ke nilai minimum yang sederhana sebesar 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 menggunakan baterai lemah.
  • Batasan memori.
  • Jika setelan "Pramuat halaman" dinonaktifkan (yang juga secara eksplisit dinonaktifkan oleh ekstensi Chrome seperti uBlock Origin).
  • Halaman dibuka di tab latar belakang.

Chrome juga tidak merender iframe lintas origin pada 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 di 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 kali menjadi navigasi berikutnya bagi sebagian besar pengguna. Selain itu, aturan dokumen dengan moderate atau conservative dapat digunakan untuk berspekulasi saat pengguna berinteraksi dengan link.
  • Aturan spekulasi yang dimasukkan secara dinamis: Hal ini dapat didasarkan pada logika aplikasi, dipersonalisasi untuk pengguna, atau berdasarkan heuristik lainnya.

Tindakan yang mendukung penyisipan dinamis berdasarkan tindakan seperti mengarahkan kursor, atau mengklik link ke bawah—seperti yang dilakukan banyak library sebelumnya dengan <link rel=prefetch>—direkomendasikan untuk melihat aturan dokumen, karena hal ini memungkinkan browser menangani banyak kasus penggunaan Anda.

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

Header HTTP Speculation-Rules

Dukungan Browser

  • 121
  • 121
  • x
  • x

Sumber

Aturan spekulasi juga dapat ditayangkan menggunakan header HTTP Speculation-Rules, bukan menyertakannya langsung di HTML dokumen. Hal ini memudahkan deployment 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 resource merupakan resource lintas asal, lulus pemeriksaan CORS.

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

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

Aturan spekulasi dan SPA

Aturan spekulasi hanya didukung untuk navigasi halaman penuh yang dikelola oleh browser, dan tidak 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 apa yang disebut "navigasi ringan" ini dapat diambil sebelumnya oleh aplikasi di luar aturan spekulasi, tetapi tidak dapat dipra-render.

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 mengetahui 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, cara yang berbeda 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 Browser

  • 121
  • 121
  • x
  • x

Sumber

Saat mengambil data atau melakukan pra-rendering halaman, parameter URL tertentu (secara teknis dikenal sebagai parameter penelusuran) mungkin tidak penting bagi halaman yang sebenarnya ditayangkan 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 ditampilkan dari server. Artinya, page1.html?utm_content=123 dan page1.html?utm_content=456 akan menayangkan halaman yang sama dari server, sehingga halaman yang sama dapat digunakan kembali dari cache.

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

Proposal No-Variasi-Search memungkinkan server menentukan parameter yang tidak menghasilkan perbedaan dengan resource yang dikirimkan, 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 pengambilan data (meskipun kami ingin mendukung pra-rendering ini juga).

Aturan spekulasi mendukung penggunaan expects_no_vary_search untuk menunjukkan tempat header HTTP No-Vary-Search diharapkan akan ditampilkan. Melakukan hal itu dapat lebih membantu untuk 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 mana pun sebelum pengambilan data selesai, browser mungkin tidak menerima halaman /products. Dalam hal ini, browser tidak tahu apakah akan berisi header HTTP No-Vary-Search. Kemudian, browser memiliki pilihan untuk mengambil link lagi, atau menunggu pengambilan data selesai untuk melihat apakah link 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 hingga pengambilan data tersebut selesai.

Batasan aturan spekulasi dan peningkatan 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 origin, tetapi sekali lagi hanya jika cookie untuk domain lintas origin tidak ada. Jika cookie ada dari pengguna yang pernah 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 guna mencegah spekulasi lintas origin untuk link lintas origin secara default diperlukan demi keamanan. Ini merupakan peningkatan dari <link rel="prefetch"> untuk tujuan lintas origin yang juga tidak akan mengirim cookie, tetapi masih mencoba pengambilan data—yang akan menyebabkan pengambilan data yang sia-sia yang 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 untuk menambahkan dukungan ini. Ikuti Masalah pekerja layanan dukungan 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

Ini 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"> secara langsung ke DOM tidak akan mendaftarkan aturan spekulasi karena harus ditambahkan seperti yang ditunjukkan sebelumnya. Misalnya, pengeditan langsung panel Elemen di Chrome DevTools untuk menambahkan elemen <script type = "speculationrules"> tidak akan mendaftarkan aturan spekulasi. Sebagai gantinya, skrip untuk menambahkan ini secara dinamis ke DOM harus dijalankan dari Konsol untuk menyisipkan aturan.

Menambahkan aturan spekulasi melalui tag manager

Untuk menambahkan aturan spekulasi menggunakan Tag Manager seperti Google Tag Manager (GTM), aturan ini harus disisipkan melalui JavaScript, bukan menambahkan elemen <script type = "speculationrules"> melalui GTM secara langsung untuk 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.

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 Kebijakan Keamanan Konten script-src jika situs menggunakan elemen ini—baik menggunakan hash maupun 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. Ini tidak mendukung aturan yang disertakan dalam HTML awal sehingga aturan perlu diinjeksi oleh JavaScript untuk situs yang menggunakan CSP ketat.

Mendeteksi dan menonaktifkan pra-rendering

Pra-rendering biasanya merupakan pengalaman positif bagi pengguna karena memungkinkan rendering halaman yang cepat—sering kali secara instan. Hal ini menguntungkan pengguna dan pemilik situs, karena halaman yang dipra-render memungkinkan pengalaman pengguna yang lebih baik yang mungkin sulit dicapai jika tidak dilakukan.

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 dengan setelan "Pramuat halaman" di chrome://settings/performance/. Selain itu, pra-rendering juga dinonaktifkan di perangkat dengan memori rendah, atau jika sistem operasi dalam mode Hemat data atau Hemat 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 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 yang gagal ditampilkan (bukan kode 200 atau 304), halaman tidak akan dipra-render dan halaman pengambilan data akan dihapus.

Jika Anda tidak ingin halaman tertentu dipra-render, ini 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 setelah halaman benar-benar dilihat, menggunakan JavaScript.

Mendeteksi pra-rendering 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 disetel ke waktu bukan 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-render seperti berikut:

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

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

Konsol di Chrome DevTools menampilkan aktivasi Start yang positif yang menunjukkan halaman 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 yang ingin Anda tunda hingga halaman benar-benar dilihat oleh pengguna.

Dengan menggunakan API ini, JavaScript frontend dapat mendeteksi dan bertindak pada halaman yang 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 Pemantauan Pengguna Nyata (RUM).

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

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 sedang melakukan pra-rendering, 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 hingga halaman pertama kali terlihat, yang akan mencakup kasus pra-rendering, dan juga saat tab dibuka di latar belakang (misalnya, dengan klik kanan dan terbuka di tab baru):

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

async function initAnalytics() {
  await whenActivated;
  // 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 Anda mungkin perlu menggunakan document.prerendering dan prerenderingchange untuk menargetkan halaman pra-rendering secara khusus.

Mengukur performa

Untuk mengukur metrik performa, Analytics harus mempertimbangkan apakah lebih baik mengukurnya berdasarkan waktu aktivasi daripada waktu muat halaman yang akan dilaporkan oleh API browser.

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

Dari 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 pra-rendering untuk metrik tersebut dalam atribut Metric.navigationType jika halaman telah dipra-render sepenuhnya atau sebagian.

Mengukur pra-render

Apakah suatu halaman dipra-render dapat dilihat dengan entri activationStart selain nol dari PerformanceNavigationTiming. Peristiwa ini kemudian dapat dicatat menggunakan Dimensi Kustom, atau yang serupa saat mencatat penayangan 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');

Dengan demikian, analisis Anda dapat menunjukkan berapa banyak navigasi yang dipra-render dibandingkan dengan jenis navigasi lainnya, dan juga memungkinkan Anda menghubungkan 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 dari halaman pra-rendering untuk navigasi instan, Anda dapat memutuskan apakah perlu mengeluarkan lebih banyak upaya dalam menggunakan teknologi ini untuk memungkinkan lebih banyak navigasi yang dipra-render, atau untuk 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. Ini bisa berarti Anda melakukan pra-rendering terlalu banyak, dan menggunakan sumber daya pengguna yang berharga untuk sedikit manfaat.

Hal ini dapat diukur dengan mengaktifkan peristiwa analisis saat aturan spekulasi disisipkan—setelah memeriksa bahwa browser mendukung pra-rendering menggunakan HTMLScriptElement.supports('speculationrules')—untuk menunjukkan bahwa pra-rendering 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.)

Anda kemudian dapat membandingkan jumlah peristiwa ini, dengan tayangan halaman pra-rendering yang sebenarnya. Atau, aktifkan peristiwa lain pada aktivasi jika hal itu membuatnya lebih mudah untuk dibandingkan.

"Rasio hit yang berhasil" kemudian dapat diperkirakan dengan melihat perbedaan di antara kedua angka tersebut. Untuk halaman yang menggunakan Speculation Rules API untuk melakukan pra-rendering halaman, Anda dapat menyesuaikan aturan dengan tepat untuk memastikan Anda mempertahankan rasio hit yang tinggi. Hal ini bertujuan mempertahankan keseimbangan antara penggunaan resource pengguna untuk membantu mereka, dibandingkan dengan penggunaannya secara tidak perlu.

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

Jangan lupa untuk juga melihat halaman yang tidak memiliki pra-rendering, karena hal tersebut dapat menunjukkan bahwa halaman tersebut tidak memenuhi syarat untuk pra-rendering, bahkan dari kolom URL. Hal tersebut mungkin berarti Anda 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 pada 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 pra-rendering.

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 terkait repo GitHub atau menggunakan issue tracker kami. Selain itu, kami berharap dapat mendengar dan membagikan studi kasus tentang API baru yang menarik ini.

Ucapan terima kasih

Gambar thumbnail oleh Marc-Olivier Jodoin di Unsplash