Tim Chrome telah mengerjakan beberapa update menarik pada Speculation Rules API yang digunakan untuk meningkatkan performa navigasi dengan melakukan pengambilan data atau bahkan melakukan pra-rendering navigasi mendatang. Peningkatan tambahan ini kini semuanya tersedia dari Chrome 122 (dengan beberapa fitur yang tersedia dari versi sebelumnya).
Perubahan ini membuat halaman pengambilan data dan pra-rendering menjadi jauh lebih mudah di-deploy dan tidak boros, yang kami harap akan mendorong penggunaan lebih lanjut.
Fitur tambahan
Pertama adalah penjelasan tentang penambahan baru yang kami tambahkan ke Speculation Rules API dan cara menggunakannya. Setelah ini, kami akan menampilkan demo sehingga Anda dapat melihat cara kerjanya.
Aturan dokumen
Sebelumnya, Speculation Rules API bekerja dengan menentukan daftar URL untuk pengambilan data atau pra-rendering:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Aturan spekulasi bersifat semi-dinamis karena skrip aturan spekulasi baru dapat ditambahkan, dan skrip lama dihapus untuk menghapus spekulasi tersebut (perhatikan bahwa memperbarui daftar urls
skrip aturan spekulasi yang ada tidak memicu perubahan dalam spekulasi). Namun, situs masih memiliki pilihan URL, baik dengan mengirimnya dari server pada waktu permintaan halaman, atau dengan membuat daftar ini secara dinamis melalui JavaScript sisi klien.
Aturan daftar tetap menjadi opsi untuk kasus penggunaan yang lebih sederhana (dengan navigasi berikutnya berasal dari sekumpulan kecil yang jelas), atau kasus penggunaan yang lebih canggih (dengan daftar URL dihitung secara dinamis berdasarkan heuristik apa pun yang ingin digunakan pemilik situs, lalu disisipkan ke dalam halaman).
Sebagai alternatif, kami dengan senang hati menawarkan opsi baru untuk menemukan link otomatis menggunakan aturan dokumen. Cara ini bekerja dengan mencari URL dari dokumen itu sendiri berdasarkan kondisi where
. Hal ini dapat didasarkan pada link itu sendiri:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout/*"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Pemilih CSS juga dapat digunakan sebagai alternatif, atau bersama dengan, kecocokan href untuk menemukan link di halaman saat ini:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Hal ini memungkinkan satu kumpulan aturan spekulasi untuk digunakan di seluruh situs, alih-alih memiliki aturan khusus per halaman, sehingga lebih mudah bagi situs untuk menerapkan aturan spekulasi.
Tentu saja, melakukan pra-rendering semua link pada halaman pasti akan sia-sia, jadi dengan kemampuan baru ini, kami telah memperkenalkan setelan eagerness
.
Keberanian
Dalam jenis spekulasi apa pun, ada kompromi antara presisi dan perolehan, dan waktu tunggu. Pra-rendering semua link saat pemuatan halaman berarti Anda hampir dapat dipastikan akan melakukan pra-rendering link yang diklik pengguna (dengan asumsi mereka mengklik link situs yang sama pada halaman), dan dengan waktu pengerjaan sebanyak mungkin, tetapi dengan potensi pemborosan bandwidth yang sangat besar.
Di sisi lain, pra-rendering hanya setelah pengguna mengklik link akan mencegah pemborosan, tetapi akibatnya, waktu tunggunya akan berkurang jauh. Artinya, pra-rendering tidak mungkin selesai sebelum browser beralih ke halaman tersebut.
Setelan eagerness
memungkinkan Anda menentukan kapan spekulasi harus dijalankan, yang memisahkan kapan untuk berspekulasi dari URL mana yang akan digunakan untuk melakukan spekulasi. Setelan eagerness
tersedia untuk aturan sumber list
dan document
, serta memiliki empat setelan, dengan heuristik berikut untuk Chrome:
immediate
: Ini digunakan untuk berspekulasi sesegera mungkin, yaitu, segera setelah aturan spekulasi diamati.eager
: Saat ini perilakunya sama dengan setelanimmediate
, tetapi di masa mendatang, kami akan menempatkannya antaraimmediate
danmoderate
.moderate
: Opsi ini melakukan spekulasi jika Anda mengarahkan kursor ke link selama 200 milidetik (atau pada peristiwapointerdown
jika lebih cepat, dan di perangkat seluler yang tidak memiliki peristiwahover
).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 sangat sederhana, berspekulasi secara lebih cepat mungkin memerlukan 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 sederhana berikut yang akan melakukan pra-rendering semua link saat mengarahkan kursor atau pointerdown sebagai penerapan aturan spekulasi dasar—namun andal—:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Batas Chrome
Meskipun dengan pilihan eagerness
, Chrome memiliki batasan untuk mencegah penggunaan API ini secara berlebihan:
eagerness |
Prefetch | Pra-rendering |
---|---|---|
immediate /eager |
50 | 10 |
moderate /conservative |
2 (FIFO) | 2 (FIFO) |
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 yang paling lama dibatalkan dan diganti dengan spekulasi yang lebih baru untuk menghemat memori.
Fakta bahwa spekulasi moderate
dan conservative
dipicu oleh pengguna memungkinkan kita menggunakan batas 2 yang lebih sederhana untuk menghemat memori. Setelan immediate
dan eager
tidak dipicu oleh tindakan pengguna sehingga memiliki batas yang lebih tinggi karena browser tidak dapat mengetahui setelan mana yang diperlukan dan kapan setelan tersebut diperlukan.
Spekulasi yang dibatalkan dengan didorong keluar dari antrean FIFO dapat dipicu lagi—misalnya dengan mengarahkan kursor ke tautan tersebut lagi—yang akan mengakibatkan URL tersebut dispekulasikan ulang. Dalam kasus ini, spekulasi sebelumnya kemungkinan akan menyebabkan browser meng-cache beberapa sumber daya dalam Cache HTTP untuk URL tersebut, sehingga mengulangi spekulasi akan menghasilkan jaringan yang jauh lebih sedikit dan begitu juga biaya waktu.
Batas immediate
dan eager
juga dinamis. Menghapus elemen skrip aturan spekulasi menggunakan tingkat kesiapan ini akan menciptakan kapasitas dengan membatalkan spekulasi yang dihapus tersebut. URL ini juga dapat berspekulasi ulang jika disertakan dalam skrip URL baru dan batasnya belum tercapai.
Chrome juga akan mencegah spekulasi digunakan dalam kondisi tertentu termasuk:
- Simpan-Data.
- Penghemat energi.
- Batasan memori.
- Jika setelan "Pramuat halaman" dinonaktifkan (yang juga dinonaktifkan secara eksplisit oleh ekstensi Chrome seperti uBlock Origin).
- Halaman dibuka di tab latar belakang.
Semua kondisi ini bertujuan untuk mengurangi dampak spekulasi yang berlebihan jika akan merugikan pengguna.
source
opsional
Chrome 122 menjadikan kunci source
opsional karena hal ini dapat disimpulkan dari keberadaan kunci url
atau where
. Oleh karena itu, kedua aturan spekulasi ini identik:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Header HTTP Speculation-Rules
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 bersifat relatif dengan URL file JSON aturan spekulasi. Hal ini mungkin sangat berguna jika Anda perlu memilih beberapa—atau semua—link origin yang sama.
Penggunaan cache yang lebih baik
Kami telah melakukan sejumlah peningkatan pada penyimpanan cache di Chrome sehingga pengambilan data (atau bahkan pra-rendering) dokumen akan menyimpan dan menggunakan kembali sumber daya dalam cache HTTP. Ini berarti berspekulasi masih bisa memberikan manfaat di masa depan, bahkan jika spekulasi itu tidak digunakan.
Hal ini juga membuat spekulasi ulang (misalnya, untuk aturan dokumen dengan setelan kecepatan moderate
) jauh lebih murah, karena Chrome akan menggunakan cache HTTP untuk resource yang dapat di-cache.
Kami juga mendukung proposal No-Vary-Search
baru untuk lebih meningkatkan penggunaan kembali cache.
Dukungan No-Vary-Search
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. Catatan: saat ini, fitur ini hanya didukung di Chrome (dan browser berbasis Chromium) untuk spekulasi navigasi pengambilan data.
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.
Demo
Kami telah membuat demo di https://speculative-rules.glitch.me/common-fruits.html yang dapat digunakan untuk melihat aturan dokumen dengan cara kerja setelan keinginan moderate
:
Buka DevTools, klik panel Application. Kemudian, di bagian Background services, klik Speculative load, lalu panel Speculations, dan urutkan berdasarkan kolom Status.
Saat mengarahkan kursor ke buah, Anda akan melihat halaman tersebut melakukan pra-rendering. Mengkliknya akan menampilkan waktu LCP yang jauh lebih cepat daripada salah satu resep, yang tidak dipra-render. Demo ini juga dijelaskan dalam video berikut:
Anda juga dapat membaca postingan blog aturan spekulasi proses debug sebelumnya untuk mengetahui informasi selengkapnya tentang cara menggunakan DevTools untuk men-debug aturan spekulasi.
Dukungan platform untuk aturan spekulasi
Meskipun aturan spekulasi relatif sederhana untuk diimplementasikan dengan memasukkan aturan ke dalam elemen <script type="speculationrules">
, dukungan platform dapat menjadikannya urusan sekali klik. Kami telah bekerja sama dengan berbagai platform dan partner untuk mempermudah peluncuran aturan spekulasi.
Kami juga berupaya keras untuk menstandarkan API melalui Web Incubator Community Group (WICG) agar browser lain juga dapat menerapkan API menarik ini jika mereka mau.
WordPress
Tim WordPress Core Performance (termasuk developer dari Google), membuat plugin Aturan Spekulasi. Plugin ini memungkinkan penambahan dukungan aturan dokumen dengan sekali klik yang sederhana ke situs WordPress apa pun. Plugin ini juga tersedia untuk diinstal melalui plugin WordPress Performance Lab, yang juga harus Anda pertimbangkan untuk diinstal karena plugin ini akan terus memberikan info terbaru tentang plugin performa terkait dari tim Anda.
Ada dua grup setelan yang tersedia: setelan Mode spekulasi dan setelan Keinginan:
Untuk penyiapan yang lebih rumit—misalnya, untuk mengecualikan URL tertentu agar tidak diambil data atau dipra-render—baca dokumentasi.
Akamai
Akamai adalah salah satu penyedia CDN terkemuka di dunia, dan mereka telah aktif bereksperimen dengan Speculation Rules API selama beberapa waktu. Akamai telah merilis dokumentasi tentang cara pelanggan dapat mengaktifkan API ini di setelan CDN mereka. Mereka juga sebelumnya telah membagikan hasil mengesankan yang mungkin diperoleh dengan API baru ini.
NitroPack
NitroPack adalah solusi pengoptimalan performa yang menggunakan Navigation AI kustomnya untuk memprediksi halaman mana yang akan ditambahkan ke aturan spekulasi, yang bertujuan memberikan lama pengerjaan yang lebih lama daripada mengarahkan kursor ke link, tetapi tidak perlu berspekulasi secara berlebihan pada semua link yang diamati. Lihat dokumentasi Nitropack Speculation Rules API untuk informasi selengkapnya. Solusi inovatif ini menunjukkan bahwa masih banyak aturan daftar lama yang dapat ditawarkan saat dipasangkan dengan wawasan khusus situs.
Tim Chrome juga bekerja sama dengan NitroPack dalam webinar untuk Speculation Rules API bagi mereka yang mencari informasi lebih lanjut, termasuk diskusi yang baik tentang pertimbangan yang diperlukan antara berspekulasi lebih awal dan sering, serta terlambat dan lebih jarang.
Astro
Astro menambahkan halaman pra-rendering menggunakan Speculation Rules API di 4.2 secara eksperimental, memungkinkan developer yang menggunakan Astro mengaktifkan fitur ini dengan mudah, sekaligus kembali ke pengambilan data standar untuk browser yang tidak mendukung Speculation Rules API. Baca dokumentasi pra-rendering klien untuk informasi selengkapnya.
Kesimpulan
Penambahan pada Speculation Rules API memungkinkan penggunaan fitur performa baru yang menarik untuk situs secara jauh lebih sederhana, dengan lebih sedikit risiko membuang-buang resource dengan spekulasi yang tidak digunakan. Sangat menarik melihat berbagai platform sudah mulai memanfaatkan API ini. Kami berharap API ini dapat digunakan secara lebih luas pada tahun 2024, sehingga menghasilkan performa yang lebih baik bagi pengguna akhir.
Selain peningkatan performa yang diberikan Speculation Rules API, kami juga tidak sabar untuk melihat peluang baru apa saja yang terbuka. View Transitions adalah API baru yang memungkinkan developer menentukan transisi antar-navigasi dengan lebih mudah. Fitur ini saat ini tersedia untuk Aplikasi Web Satu Halaman (SPA), tetapi versi multi-halaman sedang dalam proses (dan tersedia di belakang tanda di Chrome). Pra-rendering adalah add-on alami pada fitur tersebut untuk memastikan tidak ada penundaan, yang akan mencegah peningkatan pengalaman pengguna yang dimaksudkan untuk diberikan oleh transisi. Kami telah melihat situs yang bereksperimen dengan kombinasi ini.
Kami berharap dapat mengadopsi Speculation Rules API lebih lanjut sepanjang tahun 2024, dan akan terus memberi tahu Anda tentang peningkatan lebih lanjut yang kami lakukan pada API ini.
Ucapan terima kasih
Thumbnail oleh Robbie Down di Unsplash