Melakukan pra-render halaman di Chrome untuk navigasi halaman instan

Dukungan Browser

  • 109
  • 109
  • x
  • x

Tim Chrome telah mengupayakan opsi untuk mengembalikan pra-rendering penuh pada halaman mendatang yang kemungkinan akan dibuka 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 menggunakan petunjuk rel=prerender link ini tidak digunakan lagi dan digantikan dengan 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 mengirimkan pemuatan halaman instan seperti halnya 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 di masa mendatang, mekanisme pra-rendering baru ini tidak akan menggunakan sintaksis <link rel="prerender"...>, yang tetap berlaku untuk NoState Prefetch, dengan rencana untuk menghentikan penggunaan ini di masa mendatang.

Bagaimana halaman dipra-render?

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

  1. Saat Anda mengetik URL ke 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 mengetikkan istilah penelusuran di kolom URL Chrome, Chrome dapat melakukan pra-rendering halaman hasil penelusuran secara otomatis, saat diperintahkan untuk melakukannya oleh mesin telusur.
  3. Situs dapat menggunakan Speculation Rules API, untuk secara terprogram memberi tahu Chrome halaman mana yang akan dipra-render. Tindakan ini menggantikan fungsi <link rel="prerender"...> yang sebelumnya digunakan dan memungkinkan situs melakukan pra-rendering halaman secara proaktif berdasarkan aturan spekulasi di halaman. Ini bisa secara statis ada di halaman, atau dimasukkan secara dinamis oleh JavaScript sesuai keinginan pemilik halaman.

Pada 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 sepenuhnya dipra-render, statusnya saat ini akan menjadi "latar depan" dan terus dimuat, yang berarti Anda masih bisa memulai dengan baik.

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

Dampak pra-rendering

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

Contoh dampak pra-rendering.

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

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

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

Lihat bagian Mengukur performa untuk mendapatkan 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:

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

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 akan cukup yakin bahwa Anda hampir selalu membuka https://sheets.google.com.

Screenshot ini diambil dalam penginstalan Chrome yang relatif baru, dan memfilter prediksi nol keyakinan, tetapi jika Anda melihat prediktor sendiri, Anda kemungkinan 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 saran bilah alamat yang mungkin telah Anda perhatikan:

Screenshot fitur &#39;Typeahead&#39; pada kolom URL
Fitur 'Typeahead' kolom URL.

Chrome akan terus mengupdate prediktornya berdasarkan pengetikan 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 lebih dari 80% (ditampilkan dalam warna hijau), Chrome akan melakukan pra-rendering URL.

Speculation Rules API

Untuk opsi pra-rendering ketiga, developer web dapat menyisipkan 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 mulai Chrome 121), yang melakukan pra-rendering link yang ditemukan dalam dokumen berdasarkan href atau pemilih CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

Keberanian

Dukungan Browser

  • 121
  • 121
  • x
  • x

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

  • immediate: Ini digunakan untuk berspekulasi sesegera mungkin, yaitu, segera setelah aturan spekulasi diamati.
  • eager: Perilaku ini mirip dengan setelan immediate, tetapi di masa mendatang, kami akan menempatkannya antara immediate dan moderate.
  • moderate: Opsi ini melakukan spekulasi jika Anda mengarahkan kursor ke link selama 200 milidetik (atau pada peristiwa pointerdown jika lebih cepat, dan di perangkat seluler yang tidak memiliki peristiwa hover).
  • conservative: Ini berspekulasi pada pointer atau sentuh ke bawah.

eagerness default untuk aturan list adalah immediate. Opsi moderate dan conservative dapat digunakan untuk membatasi aturan list untuk URL yang dapat 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 bahwa 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 lebih cepat mungkin membutuhkan sedikit biaya dan bermanfaat bagi pengguna. Situs dengan arsitektur yang lebih kompleks dan payload halaman yang lebih berat dapat memilih untuk mengurangi pemborosan dengan lebih jarang berspekulasi sampai Anda mendapatkan lebih banyak sinyal niat yang 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 semua link saat mengarahkan kursor atau pointerdown sebagai penerapan aturan spekulasi yang dasar—namun kuat::

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

Prefetch

Aturan spekulasi juga dapat digunakan hanya untuk mengambil data halaman, tanpa pra-rendering penuh. Langkah ini sering kali dapat 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, 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 bisa dipicu lagi—misalnya dengan kembali mengarahkan kursor ke link tersebut—yang akan mengakibatkan URL tersebut dispekulasi ulang, sehingga mendorong spekulasi terlama. Dalam kasus ini, spekulasi sebelumnya akan meng-cache sumber daya yang dapat di-cache dalam Cache HTTP untuk URL tersebut, sehingga spekulasi untuk waktu yang lebih lama akan mengurangi biaya. Itulah sebabnya batasnya ditetapkan ke nilai minimum 2 yang sedang. 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.

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

Chrome juga akan mencegah spekulasi digunakan dalam kondisi tertentu termasuk:

  • Simpan-Data.
  • Penghemat energi saat diaktifkan dan daya baterai lemah.
  • Batasan memori.
  • Jika setelan "Pramuat halaman" dinonaktifkan (yang juga dinonaktifkan secara eksplisit 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 diaktifkan.

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

Cara menyertakan aturan spekulasi di halaman

Aturan spekulasi dapat disertakan secara statis di HTML halaman atau disisipkan secara dinamis ke halaman dengan JavaScript:

  • Aturan spekulasi yang disertakan secara statis: Misalnya, situs media berita, atau blog dapat melakukan pra-rendering artikel terbaru, jika artikel tersebut sering kali merupakan 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: Hal ini dapat didasarkan pada logika aplikasi, yang dipersonalisasi untuk pengguna, atau berdasarkan heuristik lainnya.

Pengguna yang mendukung penyisipan dinamis berdasarkan tindakan seperti mengarahkan kursor atau mengklik link—seperti yang telah dilakukan banyak library di masa lalu dengan <link rel=prefetch>—direkomendasikan untuk melihat 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 dalam subframe tidak ditindaklanjuti, dan aturan spekulasi di halaman pra-rendering hanya ditindaklanjuti setelah halaman tersebut diaktifkan.

Header HTTP Speculation-Rules

Dukungan Browser

  • 121
  • 121
  • x
  • x

Sumber

Aturan spekulasi juga dapat dikirimkan menggunakan header HTTP Speculation-Rules, daripada menyertakannya secara langsung dalam HTML dokumen. Hal ini memungkinkan deployment CDN yang lebih mudah 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 asal, lulus pemeriksaan CORS.

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

Jika ingin menggunakan URL relatif, Anda dapat menyertakan kunci "relative_to": "document" dalam aturan spekulasi. 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 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 sebagian data atau halaman—yang kemudian diproses dan ditampilkan di halaman saat ini. Data yang diperlukan untuk hal ini yang disebut "navigasi lunak" dapat pengambilan data 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 mengimbangi sebagian 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 guna membantu melihat dan men-debug API baru ini.

Beberapa aturan spekulasi

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

Daftar URL:

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

Beberapa 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 melakukan pengambilan data atau pra-rendering halaman, parameter URL tertentu (secara teknis dikenal sebagai parameter penelusuran) mungkin tidak penting untuk 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 yang ditayangkan 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-misc-Search memungkinkan server menentukan parameter yang tidak menyebabkan perbedaan pada resource yang dikirim, sehingga memungkinkan browser menggunakan kembali versi dokumen yang di-cache sebelumnya, yang hanya berbeda berdasarkan parameter ini. Ini hanya didukung di Chrome (dan browser berbasis Chromium) untuk spekulasi navigasi pengambilan data saja.

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 lebih jauh.

<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 harus menampilkan header HTTP No-Vary-Search yang menunjukkan bahwa halaman dapat digunakan untuk parameter penelusuran id apa pun.

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

Pembatasan aturan spekulasi dan peningkatan mendatang

Aturan spekulasi dibatasi untuk halaman yang dibuka dalam tab yang sama, tetapi kami sedang berupaya mengurangi batasan tersebut. Secara default, pra-rendering dibatasi untuk halaman origin yang sama.

Melakukan pra-rendering halaman lintas origin situs yang sama (misalnya, https://a.example.com dapat melakukan pra-rendering halaman pada https://b.example.com). Untuk menggunakan hal ini, halaman pra-rendering (dalam contoh ini https://b.example.com) harus memilih ikut serta dengan menyertakan header HTTP Supports-Loading-Mode: credentialed-prerender atau Chrome akan membatalkan pra-rendering.

Versi mendatang juga dapat memungkinkan pra-rendering untuk halaman lintas origin (tempat situs memilih untuk ikut serta dengan header HTTP Supports-Loading-Mode: uncredentialed-prerender yang serupa), dan mengaktifkan pra-rendering di tab baru.

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.

Batalkan aturan spekulasi

Menghapus aturan spekulasi akan mengakibatkan pra-rendering dibatalkan, tetapi saat hal ini terjadi, resource kemungkinan akan telah dihabiskan untuk memulai pra-rendering, sehingga sebaiknya tidak melakukan pra-rendering jika ada kemungkinan perlu membatalkan pra-rendering.

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 menggunakannya—baik menggunakan hash maupun nonce.

inline-speculation-rules baru dapat ditambahkan ke script-src yang memungkinkan elemen <script type="speculationrules"> yang dimasukkan dari skrip hash atau skrip non-cedera didukung. Ini tidak mendukung aturan yang disertakan dalam HTML awal sehingga aturan perlu dimasukkan oleh JavaScript untuk situs yang menggunakan CSP yang 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 dengan cara yang lain.

Namun, terkadang Anda tidak ingin pra-rendering halaman terjadi, misalnya saat halaman berubah status—baik berdasarkan permintaan awal maupun berdasarkan JavaScript yang dijalankan 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 pada perangkat dengan memori rendah, atau jika sistem operasi dalam mode Hemat Data atau Penghemat Energi. Lihat bagian Batas Chrome.

Mendeteksi dan menonaktifkan pra-rendering sisi server

Halaman pra-rendering akan dikirim dengan header HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

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

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 gagal ditampilkan (yaitu, bukan 200 atau 304), halaman tidak akan dipra-render dan semua halaman pengambilan data akan dihapus.

Jika Anda tidak ingin halaman tertentu dipra-render, ini adalah cara terbaik untuk memastikan hal ini 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-rendering di JavaScript

document.prerendering API akan menampilkan true saat halaman sedang melakukan pra-rendering. Fungsi 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 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-rendering seperti berikut:

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

Cara termudah untuk melihat apakah halaman dipra-render adalah dengan membuka DevTools setelah pra-rendering terjadi, dan mengetik performance.getEntriesByType('navigation')[0].activationStart di konsol. Jika ditampilkan nilai bukan nol, Anda tahu bahwa halaman dipra-render:

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

Saat halaman diaktifkan oleh pengguna yang membuka halaman tersebut, peristiwa prerenderingchange akan dikirim pada 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 sesuai halaman yang dipra-render.

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 kemungkinan besar halaman akan dimuat oleh pengguna. Inilah sebabnya opsi pra-rendering kolom URL Chrome hanya terjadi ketika ada probabilitas yang tinggi (lebih besar dari 80% dari waktu tersebut).

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

Hal ini dapat dilakukan dengan menggunakan Promise yang menunggu peristiwa prerenderingchange jika dokumen dalam proses 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);
  } else {
    resolve();
  }
});

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

initAnalytics();

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 Data Web Inti, yang diukur oleh Chrome melalui Laporan Pengalaman Pengguna Chrome, pengukuran ini dimaksudkan untuk mengukur pengalaman pengguna. Jadi, jumlah ini diukur berdasarkan waktu aktivasi. Misalnya, tindakan ini akan menghasilkan LCP 0 detik, yang menunjukkan bahwa ini adalah cara yang bagus untuk meningkatkan Data Web Inti Anda.

Dari versi 3.1.0, library web-vitals telah diupdate untuk menangani navigasi pra-rendering dengan cara yang sama seperti yang digunakan Chrome untuk mengukur Data Web Inti. Versi ini juga menandai navigasi pra-rendering untuk metrik tersebut dalam atribut Metric.navigationType.

Mengukur pra-render

Apakah halaman dipra-render dapat dilihat dengan entri activationStart bukan nol dari PerformanceNavigationTiming. Tindakan ini kemudian dapat dicatat 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 untuk menunjukkan berapa banyak navigasi yang dipra-render dibandingkan dengan jenis navigasi lainnya, dan juga memungkinkan Anda untuk 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 tindakan bisnis seperti yang ditunjukkan dalam studi kasus kami.

Saat mengukur dampak bisnis dari halaman pra-rendering untuk navigasi instan, Anda dapat memutuskan apakah perlu berinvestasi lebih banyak upaya dalam menggunakan teknologi ini untuk memungkinkan lebih banyak navigasi 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. Hal ini dapat berarti bahwa Anda melakukan pra-rendering terlalu banyak, dan menghabiskan sumber daya pengguna yang berharga demi sedikit manfaat.

Hal ini dapat diukur dengan mengaktifkan peristiwa analisis saat aturan spekulasi disisipkan—setelah memeriksa 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 dimulai atau diselesaikan seperti, seperti disebutkan sebelumnya, pra-rendering adalah petunjuk bagi browser dan mungkin 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 kunjungan halaman pra-rendering yang sebenarnya. Atau, aktifkan peristiwa lain saat aktivasi jika hal tersebut 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 hit rate yang tinggi guna menjaga keseimbangan antara menggunakan resource pengguna untuk membantu mereka, dibandingkan menggunakannya secara sia-sia.

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 dipra-render) jika ingin membedakannya.

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

Dampak pada ekstensi

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

Masukan

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

Ucapan terima kasih

Gambar thumbnail oleh Marc-Olivier Jodoin di Unsplash