Dipublikasikan: 07 Maret 2025
Speculation Rules API memungkinkan pengguna mendapatkan manfaat dari peningkatan performa dengan mengambil data atau melakukan pra-rendering navigasi halaman mendatang untuk memberikan navigasi halaman yang lebih cepat—atau bahkan instan.
API ini telah dirancang secara khusus dengan mempertimbangkan kemudahan penerapan, tetapi ada beberapa pertimbangan yang perlu dipertimbangkan situs kompleks sebelum menggunakannya. Panduan ini membantu pemilik situs memahami pertimbangan ini.
Perencanaan
Sebelum menerapkan aturan spekulasi, sebaiknya pertimbangkan cara menerapkan API (karena ada beberapa pilihan), dan juga biaya spekulasi (yang akan memandu Anda menentukan halaman yang akan diprediksi).
Menentukan cara menerapkan aturan spekulasi
Salah satu keputusan pertama yang perlu Anda buat adalah cara menerapkan aturan spekulasi di situs Anda, karena ada berbagai metode yang dapat Anda gunakan:
- Langsung di HTML halaman
- Menggunakan JavaScript
- Menggunakan Header HTTP
Pada akhirnya, setiap metode memiliki efek yang sama, tetapi mungkin ada keuntungan dalam hal kemudahan penerapan dan fleksibilitas.
Situs harus memilih opsi yang paling sesuai, dan bahkan dapat menggunakan kombinasi opsi ini jika perlu. Atau, keduanya dapat diterapkan menggunakan plugin (seperti plugin Pemuatan Spekulatif untuk WordPress) atau library atau platform yang dapat membuat pilihan untuk Anda, tetapi sebaiknya Anda tetap mengetahui opsi yang tersedia.
Menyertakan aturan spekulasi langsung di HTML halaman
Aturan Spekulasi dapat diterapkan langsung di halaman dengan menyertakan elemen <script type="speculationrules"> dalam HTML-nya. Ini dapat ditambahkan pada waktu build untuk situs statis menggunakan template, atau pada waktu proses oleh server saat halaman diminta. Fungsi ini bahkan dapat dimasukkan dalam HTML oleh pekerja edge (meskipun metode header HTTP yang akan dibahas nanti dalam panduan ini mungkin lebih mudah untuk melakukannya).
Hal ini memungkinkan Anda menyertakan aturan statis di seluruh situs, tetapi aturan dokumen tetap dapat bersifat dinamis dengan memungkinkan Anda memilih URL yang akan dirender dari halaman menggunakan aturan yang akan dipicu oleh class CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Skrip sebelumnya akan melakukan pra-rendering link dengan class prerender, dan melakukan pra-pengambilan data serupa saat link memiliki class prefetch. Hal ini memungkinkan developer menyertakan class ini dalam HTML untuk memicu spekulasi.
Selain menyertakan link class ini dalam HTML awal halaman, link juga akan di-spekulasi jika class tersebut ditambahkan secara dinamis oleh aplikasi Anda, yang memungkinkan aplikasi memicu (dan menghapus) spekulasi sesuai kebutuhan. Hal ini dapat lebih sederhana daripada membuat atau menghapus aturan spekulasi yang lebih spesifik. Anda juga dapat menyertakan beberapa aturan spekulasi per halaman jika menginginkan aturan dasar yang digunakan oleh sebagian besar situs, dan aturan khusus halaman.
Atau, jika Anda perlu menggunakan aturan spekulasi yang lebih spesifik, aturan khusus halaman atau khusus template dapat mengizinkan aturan yang berbeda untuk halaman atau jenis halaman tertentu.
Terakhir, halaman yang dirender sisi server juga dapat memiliki aturan yang lebih dinamis berdasarkan informasi apa pun yang tersedia untuk server—seperti informasi analisis untuk halaman tersebut atau perjalanan pengguna umum untuk halaman tertentu.
Menambahkan aturan spekulasi menggunakan JavaScript
Alternatif untuk menyertakan aturan dalam skrip di halaman adalah dengan memasukkannya menggunakan JavaScript. Hal ini mungkin memerlukan lebih sedikit pembaruan pada template halaman. Misalnya, meminta pengelola tag memasukkan aturan dapat menjadi cara cepat untuk meluncurkan aturan spekulasi (dan juga memungkinkan untuk menonaktifkannya dengan cepat jika diperlukan).
Opsi ini juga memungkinkan aturan sisi klien dinamis berdasarkan cara pengguna berinteraksi dengan halaman. Misalnya, jika pengguna menambahkan item ke keranjang, Anda dapat melakukan pra-rendering halaman checkout. Atau, ini dapat digunakan untuk memicu spekulasi berdasarkan kondisi tertentu. Meskipun API menyertakan setelan kesiapan yang memungkinkan aturan dasar berbasis interaksi, JavaScript memungkinkan developer menggunakan logika mereka sendiri untuk menentukan kapan dan di halaman mana untuk berspekulasi.
Seperti yang disebutkan sebelumnya, pendekatan alternatif untuk menyisipkan aturan baru adalah dengan memiliki aturan dokumen dasar di halaman dan memiliki JavaScript yang memicu aturan dokumen dengan menambahkan class yang sesuai ke link yang menyebabkannya cocok dengan aturan.
Menambahkan aturan spekulasi menggunakan header HTTP
Opsi terakhir bagi developer adalah menyertakan aturan menggunakan header HTTP:
Speculation-Rules: "/speculationrules.json"
Ada beberapa persyaratan tambahan terkait cara resource aturan (/speculationrules.json dalam contoh ini) dikirim dan digunakan.
Opsi ini memungkinkan deployment yang lebih mudah oleh CDN tanpa perlu mengubah konten dokumen. Artinya, mengubah aturan spekulasi secara dinamis menggunakan JavaScript bukanlah sebuah opsi. Namun, aturan dokumen dengan pemicu pemilih CSS masih dapat mengizinkan perubahan dinamis—misalnya, dengan menghapus class prerender dari link.
Serupa dengan opsi JavaScript, menerapkan aturan spekulasi dengan header HTTP memungkinkan aturan tersebut diterapkan secara terpisah dari konten situs, yang dapat mempermudah penambahan dan penghapusan aturan tanpa perlu mem-build ulang situs sepenuhnya.
Mempertimbangkan implikasi biaya
Sebelum menerapkan aturan spekulasi, sebaiknya luangkan waktu untuk mempertimbangkan implikasi biaya bagi pengguna dan situs Anda dengan API ini. Biaya mencakup bandwidth (memerlukan biaya bagi pengguna dan situs) dan biaya pemrosesan (di sisi klien dan server).
Pertimbangkan biaya untuk pengguna
Pemuatan spekulatif berarti membuat tebakan yang tepat tentang tempat pengguna dapat membuka halaman baru. Namun, jika navigasi tersebut tidak terjadi, Anda mungkin telah membuang-buang resource. Itulah sebabnya Anda harus menyadari dampaknya terhadap pengguna, khususnya:
- Bandwidth tambahan yang digunakan untuk mendownload navigasi mendatang tersebut—terutama di perangkat seluler yang bandwidth-nya mungkin lebih terbatas.
- Biaya pemrosesan tambahan untuk merender halaman tersebut saat menggunakan pra-rendering.
Dengan prediksi yang sepenuhnya akurat, tidak ada biaya tambahan, karena pengunjung akan mengunjungi halaman tersebut selanjutnya, dengan satu-satunya perbedaan adalah biaya tersebut dimuat di awal. Namun, memprediksi masa depan dengan akurasi yang lengkap adalah hal yang mustahil, dan semakin agresif strategi spekulasi, semakin tinggi risiko pemborosan.
Chrome telah mempertimbangkan masalah ini dengan cermat dan API menyertakan sejumlah fitur yang berarti biayanya jauh lebih rendah dari yang Anda perkirakan. Khususnya dengan menggunakan kembali cache HTTP, dan tidak memuat iframe lintas origin, biaya pra-rendering navigasi di situs yang sama sering kali jauh lebih kecil daripada halaman penuh tanpa resource yang di-cache, sehingga pemuatan spekulatif menjadi lebih murah daripada yang mungkin diasumsikan.
Namun, meskipun dengan pengamanan ini, situs harus mempertimbangkan dengan cermat halaman mana yang akan di-spekulasi, dan biaya pengguna untuk spekulasi tersebut. Kandidat yang baik untuk pemuatan spekulatif mencakup halaman yang dapat diprediksi secara wajar dengan tingkat keyakinan yang tinggi (mungkin berdasarkan analisis, atau perjalanan pengguna umum) dan jika biayanya rendah (misalnya, halaman yang kurang kaya).
Anda juga dapat mempertimbangkan JavaScript yang harus ditunda hingga aktivasi. Serupa dengan memuat konten secara lambat hingga diperlukan, hal ini dapat membuat pra-rendering lebih murah, tetapi memberikan pengalaman pengguna yang jauh lebih baik. Dengan spekulasi yang lebih murah, Anda mungkin merasa nyaman untuk berspekulasi lebih sering atau dengan lebih antusias.
Jika tidak memungkinkan, sebaiknya gunakan strategi yang kurang agresif menggunakan aturan kesediaan yang moderat atau konservatif. Atau, Anda dapat menggunakan pengambilan data, yang memiliki biaya yang jauh lebih rendah daripada pra-rendering saat keyakinan rendah, lalu mengupgrade ke pra-rendering penuh jika keyakinan meningkat—misalnya, saat kursor diarahkan ke link atau benar-benar diklik.
Pertimbangkan beban backend tambahan
Selain mempertimbangkan biaya tambahan dari pengguna, pemilik situs harus mempertimbangkan biaya infrastruktur mereka sendiri. Jika setiap halaman menghasilkan dua, tiga, atau bahkan lebih banyak pemuatan halaman, biaya backend dapat meningkat dengan menggunakan API ini.
Memastikan halaman dan resource Anda dapat di-cache akan secara signifikan mengurangi jumlah beban origin, sehingga mengurangi risiko secara keseluruhan. Jika digabungkan dengan CDN, server origin Anda akan mengalami beban tambahan minimal—meskipun pertimbangkan kenaikan biaya CDN.
Server atau CDN juga dapat digunakan untuk mengontrol hasil spekulasi seperti yang diidentifikasi oleh header HTTP tujuan keamanan. Misalnya, produk Speed Brain Cloudflare hanya mengizinkan spekulasi yang sudah di-cache di server edge CDN, dan tidak akan mengirim permintaan kembali ke origin.
Namun, karena pemuatan spekulatif biasanya digunakan untuk pemuatan halaman dengan origin yang sama, pengguna akan memiliki resource bersama di cache browser mereka—dengan asumsi bahwa resource tersebut dapat di-cache—jadi sekali lagi, spekulasi biasanya tidak semahal pemuatan halaman penuh.
Menemukan keseimbangan antara berspekulasi terlalu banyak atau terlalu sedikit
Kunci untuk memaksimalkan Speculation Rules API adalah menemukan keseimbangan antara berspekulasi terlalu banyak—yaitu, saat biaya dibayar tanpa perlu dan spekulasi tidak digunakan—dan terlalu konservatif—baik terlalu sedikit, atau terlalu terlambat sehingga sedikit manfaat yang diperoleh.
Jika biayanya murah (misalnya, halaman kecil yang dihasilkan secara statis dan di-cache di node edge CDN), Anda dapat lebih agresif dengan spekulasi.
Namun, untuk halaman yang lebih besar dan lebih kaya yang mungkin tidak dapat di-cache di edge CDN, Anda harus lebih berhati-hati. Demikian pula, halaman yang memerlukan banyak resource dapat menghabiskan bandwidth jaringan atau daya pemrosesan yang dapat berdampak negatif pada halaman saat ini. Tujuan API adalah meningkatkan performa, jadi regresi performa jelas bukan yang kita inginkan. Ini adalah alasan lain untuk membatasi pra-rendering hingga maksimal satu atau dua halaman (perhatikan juga bahwa Chrome membatasi hingga dua atau sepuluh pra-rendering sekaligus, bergantung pada kesiapan).
Langkah-langkah untuk menerapkan aturan spekulasi
Setelah memutuskan cara menerapkan aturan spekulasi, Anda perlu merencanakan apa yang akan dibicarakan dan cara meluncurkannya. Situs yang lebih sederhana, seperti blog pribadi statis, mungkin dapat langsung melakukan pra-rendering penuh halaman tertentu, tetapi situs yang lebih kompleks memiliki kompleksitas tambahan yang perlu dipertimbangkan.
Mulai dengan pengambilan data sebelumnya
Pengambilan data biasanya relatif aman untuk diterapkan di sebagian besar situs dan ini adalah pendekatan awal yang dilakukan oleh banyak orang, termasuk peluncuran skala besar seperti Cloudflare dan WordPress.
Masalah utama yang perlu diperhatikan adalah jika pengambilan data sebelumnya pada URL akan menyebabkan perubahan status dan biaya sisi server, terutama untuk halaman yang tidak dapat di-cache. Idealnya, perubahan status —misalnya, pengambilan data halaman /logout—tidak boleh diterapkan sebagai link GET, tetapi sayangnya hal ini tidak jarang terjadi di web.
URL tersebut dapat dikecualikan secara khusus dari aturan:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Pengambilan data dapat dibatasi untuk navigasi umum dari satu halaman ke halaman lain, atau untuk semua link dengan origin yang sama saat mengarahkan kursor atau mengklik menggunakan setelan eagerness moderate atau conservative. Setelan conservative memiliki risiko terendah, tetapi juga potensi reward terendah. Jika Anda memulai dari versi tersebut, sebaiknya tingkatkan ke moderate setidaknya, tetapi idealnya lebih dari itu ke eager akan memberikan lebih banyak manfaat performa (lalu upgrade lebih lanjut ke prerender jika memungkinkan).
Pra-rendering berisiko rendah
Spekulasi pengambilan data lebih mudah di-deploy, tetapi manfaat performa terbaik untuk API adalah dengan pra-rendering. Hal ini dapat memiliki beberapa pertimbangan tambahan jika halaman tidak dikunjungi segera setelah berspekulasi (yang akan kita bahas di bagian berikutnya), tetapi dengan pra-render moderate atau conservative, navigasi yang cenderung terjadi segera setelahnya mungkin merupakan langkah berikutnya yang berisiko relatif rendah.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Mengambil halaman umum terlebih dahulu untuk meningkatkan kualitas pra-rendering non-eager
Salah satu taktik umum adalah melakukan pramuat halaman berikutnya yang lebih sedikit dan sering dikunjungi saat pemuatan dengan setelan eager (baik dengan menentukannya dalam daftar URL atau menggunakan selector_matches), lalu melakukan pra-rendering dengan setelan moderate. Karena pengambilan data HTML kemungkinan telah selesai pada saat kursor diarahkan ke link, hal ini memberikan peningkatan dibandingkan hanya pra-rendering saat kursor diarahkan tanpa pengambilan data.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Pra-rendering sebelumnya
Meskipun aturan dokumen moderate memungkinkan penggunaan API dengan risiko relatif rendah dengan kemudahan penerapan yang terkait, hal ini sering kali tidak cukup waktu untuk pra-rendering penuh. Untuk mencapai navigasi instan yang diizinkan API ini, Anda mungkin perlu melakukan lebih dari itu dan melakukan pra-rendering halaman dengan lebih cepat.
Hal ini dicapai dengan daftar URL statis (seperti contoh pengambilan data sebelumnya) atau dengan selector_matches yang mengidentifikasi sejumlah kecil URL (idealnya satu atau dua halaman), dengan aturan dokumen yang mencakup URL lainnya:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Hal ini mungkin memerlukan analisis traffic untuk memberikan peluang terbaik dalam memprediksi navigasi berikutnya secara akurat. Memahami perjalanan pelanggan yang biasa melalui situs Anda juga dapat membantu mengidentifikasi kandidat yang baik untuk pemuatan spekulatif.
Beralih ke pra-rendering yang lebih cepat juga dapat menimbulkan lebih banyak pertimbangan seputar analisis, iklan, dan JavaScript serta kebutuhan untuk memperbarui halaman yang dipra-render, atau bahkan untuk membatalkan atau memuat ulang spekulasi pada perubahan status.
Analytics, iklan, dan JavaScript
Saat menggunakan pra-rendering, situs yang lebih kompleks juga harus mempertimbangkan dampaknya terhadap analisis. Anda biasanya tidak ingin mencatat tampilan halaman (atau iklan) ke dalam log saat halaman di-spekulasi, dan hanya saat spekulasi diaktifkan.
Beberapa penyedia analisis (seperti Google Analytics) dan penyedia iklan (seperti Tag Google Publisher) sudah mendukung aturan spekulasi, dan tidak akan mencatat kunjungan ke dalam log hingga halaman diaktifkan. Namun, penyedia atau analisis kustom lain yang telah Anda terapkan mungkin memerlukan pertimbangan tambahan.
Anda dapat menambahkan pemeriksaan ke JavaScript untuk mencegah eksekusi bit kode tertentu hingga halaman diaktifkan atau terlihat, dan bahkan menggabungkan seluruh elemen <script> dalam pemeriksaan tersebut. Jika halaman menggunakan tag manager untuk memasukkan skrip tersebut, Anda mungkin dapat mengatasi semuanya sekaligus dengan menunda skrip tag manager itu sendiri.
Demikian pula, pengelola izin adalah peluang untuk menunda skrip pihak ketiga hingga aktivasi dan Google telah bekerja sama dengan berbagai platform pengelola izin untuk membuatnya mendukung pra-rendering. Kami juga akan dengan senang hati membantu orang lain yang ingin melakukan hal yang sama. PubTech adalah salah satu perusahaan yang menawarkan pilihan kepada developer untuk menjalankan atau memblokir JavaScript-nya selama pra-rendering.
Untuk kode aplikasi, Anda juga dapat menambahkan perubahan untuk menunda eksekusi kode hingga aktivasi, terutama jika halaman tidak memerlukan kode JavaScript untuk dirender. Ini adalah opsi yang lebih cepat dan aman, tetapi berarti semua kode akan berjalan sekaligus saat diaktifkan. Hal ini dapat menyebabkan banyak pekerjaan pada waktu aktivasi yang dapat memengaruhi INP, terutama karena halaman mungkin terlihat dimuat sepenuhnya dan siap untuk berinteraksi.
Selain itu, jika ada konten yang bergantung pada JavaScript (misalnya, konten yang dirender sisi klien), penundaan ini akan mengurangi dampak positif pada LCP dan CLS yang dapat dihasilkan pra-rendering. Pendekatan yang lebih ditargetkan untuk memungkinkan lebih banyak JavaScript berjalan selama fase pra-rendering akan menghasilkan pengalaman yang lebih baik, tetapi mungkin tidak terlalu mudah diterapkan.
Memulai dengan menunda banyak tag skrip sepenuhnya dapat menjadi strategi yang baik untuk situs yang lebih kompleks pada awalnya. Namun, untuk mendapatkan manfaat maksimal dari API, mengizinkan JavaScript sebanyak mungkin untuk berjalan selama pra-rendering harus menjadi sasaran utama.
Situs yang memiliki masalah analisis atau iklan juga dapat memulai dengan pengambilan data, yang tidak terlalu menjadi masalah, sambil mempertimbangkan hal yang perlu dilakukan untuk mendukung pra-rendering.
Memperbarui spekulasi pra-rendering
Saat melakukan pra-rendering halaman sebelum navigasi, ada risiko bahwa halaman yang dipra-render menjadi tidak berlaku lagi. Misalnya, situs e-commerce halaman yang dipra-render dapat menyertakan keranjang checkout—baik keranjang item yang penuh atau bahkan hanya penghitung yang menampilkan jumlah item di keranjang di halaman lain. Jika lebih banyak item ditambahkan ke keranjang, lalu halaman yang dirender sebelumnya dibuka, pengguna akan bingung melihat status checkout lama.
Ini bukan masalah baru dan saat pengguna membuka beberapa tab di browser, mereka akan mengalami masalah yang sama. Namun, dengan halaman yang diprarender, hal ini lebih mungkin terjadi dan lebih tidak terduga karena pengguna tidak sengaja memulai pra-render.
Broadcast Channel API adalah salah satu cara untuk mengizinkan satu halaman di browser menyiarkan update seperti ini ke halaman lain. Tindakan ini juga akan menyelesaikan masalah beberapa tab. Halaman yang dirender sebelumnya dapat memproses pesan siaran—meskipun tidak dapat mengirim pesan siaran sendiri hingga diaktifkan.
Atau, halaman yang dirender sebelumnya dapat mendapatkan update menggunakan server (menggunakan fetch() berkala, atau koneksi WebSocket), tetapi dengan potensi keterlambatan update.
Membatalkan atau memuat ulang spekulasi pra-rendering
Memperbarui halaman pra-rendering adalah pendekatan yang direkomendasikan untuk terus menggunakan halaman pra-rendering sekaligus menghindari kebingungan bagi pengguna. Jika tidak memungkinkan, Anda dapat membatalkan spekulasi.
Hal ini juga dapat digunakan untuk tetap berada dalam batas Chrome jika situs ingin melakukan pra-rendering halaman lain yang lebih mungkin dikunjungi.
Untuk membatalkan spekulasi, Anda harus menghapus aturan spekulasi dari halaman—atau menghapus class atau kriteria pencocokan lainnya jika menggunakan pendekatan tersebut. Atau, halaman yang di-spekulasi dapat memanggil window.close() jika mendeteksi bahwa halaman tersebut tidak lagi terbaru. Namun, jika halaman dapat mendeteksi hal ini, opsi yang lebih baik adalah memperbarui statusnya agar kembali ke versi terbaru.
Anda juga dapat menyisipkan kembali aturan ini (atau kriteria pencocokan) sehingga halaman dapat dipra-render ulang (meskipun sekali lagi, memperbarui halaman yang ada biasanya merupakan opsi yang lebih baik karena lebih hemat). Setelah aturan spekulasi dihapus, penyisipan ulang harus diselesaikan dalam microtask baru atau nanti, agar browser dapat melihat penghapusan dan membatalkan spekulasi. Salah satu pendekatan untuk menghapus dan menghapus semua skrip aturan spekulasi ditunjukkan dalam contoh berikut:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Menghapus aturan akan membatalkan pretender (atau pengambilan data sebelumnya) yang ada, tetapi memasukkan kembali aturan hanya akan berspekulasi tentang aturan langsung atau cepat (termasuk aturan daftar URL yang menggunakan default langsung). Namun, spekulasi moderat atau konservatif akan dihapus, tetapi tidak otomatis dipicu ulang hingga link diakses lagi.
Opsi muat ulang ini tidak terbatas pada aturan yang disisipkan JavaScript. Aturan statis yang disertakan dalam HTML juga dapat dihapus atau diubah dengan cara yang sama, karena ini adalah perubahan DOM standar. Aturan spekulasi HTTP tidak dapat dihapus, tetapi kriteria pencocokan (misalnya, class prerender) dapat dihapus, dan ditambahkan kembali oleh JavaScript.
Chrome juga mempertimbangkan untuk menambahkan dukungan Clear-Site-Header agar respons server dapat membatalkan pra-rendering (misalnya, saat permintaan keranjang update dibuat).
Mengukur dampak
Setelah menerapkan aturan spekulasi, Anda harus mengukur keberhasilan dan tidak hanya berasumsi bahwa aplikasi akan otomatis lebih cepat. Seperti yang disebutkan sebelumnya, spekulasi berlebih sebenarnya dapat menyebabkan regresi performa jika klien atau server bekerja terlalu keras.
Saat menerapkan dengan beberapa langkah (pramuat, pra-rendering berisiko rendah, lalu pra-rendering awal), Anda harus mengukur dengan setiap langkah.
Cara mengukur kesuksesan
Aturan spekulasi akan memiliki dampak positif pada metrik performa utama seperti LCP (dan mungkin juga pada CLS dan INP), tetapi hal ini mungkin tidak terlihat jelas dalam keseluruhan metrik tingkat situs. Hal ini karena situs mungkin sebagian besar terdiri dari jenis navigasi lain (misalnya, halaman landing) atau karena navigasi dengan origin yang sama sudah cukup cepat sehingga peningkatan yang signifikan pada navigasi tersebut mungkin tidak memengaruhi metrik persentil ke-75 seperti yang dilaporkan dalam Laporan Pengalaman Pengguna Chrome (CrUX).
Anda dapat menggunakan jenis navigasi halaman di CrUX untuk memeriksa persentase navigasi yang merupakan navigate_cache atau prerender dan apakah persentase tersebut meningkat dari waktu ke waktu. Namun, untuk analisis mendetail, Anda mungkin perlu menggunakan Real User Monitoring untuk menyegmentasikan data ke dalam navigasi yang diprediksi untuk melihat seberapa cepatnya dibandingkan dengan navigasi lainnya.
Cara mengukur penggunaan dan pemborosan
Pertimbangan penting lainnya adalah mengukur apakah Anda berspekulasi di halaman yang benar. Hal ini menghindari pemborosan, dan memastikan Anda menargetkan halaman terbaik untuk mendapatkan manfaat dari API ini.
Sayangnya, halaman yang memulai spekulasi tidak dapat langsung melihat status upaya spekulasi. Selain itu, upaya tidak dapat dianggap telah dipicu karena browser dapat menahan spekulasi dalam keadaan tertentu. Oleh karena itu, hal ini harus diukur di halaman itu sendiri. Hal ini juga memerlukan pemeriksaan dua API untuk melihat apakah halaman sedang berspekulasi atau telah berspekulasi:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Halaman ini kemudian dapat mencatat upaya spekulasi ke server backend.
Salah satu kerumitan terkait analisis adalah penyedia (seperti Google Analytics) yang mengetahui pra-rendering dan mengabaikan panggilan analisis hingga halaman diaktifkan—bahkan panggilan peristiwa terpisah. Oleh karena itu, pengguna Google Analytics harus menggunakan opsi logging sisi server lainnya.
Hal ini juga dapat dilakukan di sisi klien, dengan setiap halaman yang diprarender mencatat prerender dalam penyimpanan bersama, dan halaman panggilan membacanya. localStorage berfungsi paling baik karena dapat dibaca saat keluar dari halaman (perhatikan bahwa sessionStorage tidak dapat digunakan karena memiliki penanganan khusus untuk halaman yang diprarender). Namun, perlu diketahui bahwa localStorage tidak aman secara transaksional dan halaman lain mungkin memperbarui ini secara bersamaan jika beberapa halaman diprarender. Demo ini menggunakan hash unik dan entri individual untuk menghindari masalah ini.
Kesimpulan
Aturan spekulasi menawarkan kemungkinan peningkatan performa yang signifikan pada performa halaman Anda. Panduan ini memberikan saran tentang pertimbangan saat menerapkan API ini untuk menghindari potensi masalah, dan juga mendapatkan hasil maksimal dari API.
Perencanaan awal implementasi akan menghindari pengerjaan ulang. Khusus untuk situs yang lebih kompleks, harus diikuti dengan peluncuran multi-langkah yang dimulai dengan pengambilan data sebelum beralih ke pra-rendering berisiko rendah, lalu pra-rendering awal. Terakhir, penting untuk mengukur peningkatan, serta penggunaan dan pemborosan apa pun untuk memastikan Anda menggunakan API secara optimal.