Peningkatan pada Speculation Rules API

Barry Pollard

Tim Chrome telah mengerjakan beberapa update menarik pada Speculation Rules API yang digunakan untuk meningkatkan performa navigasi dengan melakukan pengambilan data atau bahkan pra-rendering navigasi mendatang. Semua peningkatan tambahan ini kini tersedia dari Chrome 122 (dengan beberapa fitur tersedia dari versi sebelumnya).

Perubahan ini membuat halaman pengambilan data dan pra-rendering jauh lebih mudah di-deploy dan lebih hemat, yang kami harap akan mendorong adopsi lebih lanjut.

Fitur tambahan

Pertama, penjelasan tentang penambahan baru yang telah kami tambahkan ke Speculation Rules API dan cara menggunakannya. Setelah itu, kami akan menunjukkan demo agar Anda dapat melihat cara kerjanya.

Aturan dokumen

Sebelumnya, Speculation Rules API berfungsi dengan menentukan daftar URL yang akan dipramuat atau dipra-render:

<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 pada spekulasi). Namun, pilihan URL masih diserahkan kepada situs, baik dengan mengirimkannya 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 navigasi 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 secara otomatis menggunakan aturan dokumen. Cara kerjanya adalah dengan mengambil 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>

Catatan: Aturan dokumen versi sebelumnya—tersedia selama uji coba origin—memiliki href_matches yang lebih kompleks yang memerlukan sintaksis tambahan untuk mencocokkan parameter dan fragmen URL ({"href_matches": "/*\\?*#*"}). Hal ini telah disederhanakan dalam versi rilis.

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 digunakan di seluruh situs, bukan memiliki aturan spesifik per halaman, sehingga mempermudah situs untuk men-deploy aturan spekulasi.

Tentu saja, melakukan pra-render semua link di halaman pasti akan membuang-buang waktu, jadi dengan kemampuan baru ini, kami telah memperkenalkan setelan eagerness.

Keinginan

Dengan segala jenis spekulasi, ada kompromi antara presisi dan recall, serta waktu tunggu. Melakukan pra-render semua link saat halaman dimuat berarti Anda hampir pasti akan melakukan pra-render link yang diklik pengguna (dengan asumsi mereka mengklik link situs yang sama di halaman), dan dengan waktu tunggu sebanyak mungkin, tetapi dengan potensi pemborosan bandwidth yang besar.

Di sisi lain, hanya melakukan pra-rendering setelah pengguna mengklik link akan mencegah pemborosan, tetapi dengan mengorbankan waktu tunggu yang jauh lebih singkat. Artinya, pra-rendering kemungkinan tidak akan 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 melakukan spekulasi. Setelan eagerness tersedia untuk aturan sumber list dan document, serta memiliki empat setelan, yang memiliki heuristik berikut di Chrome:

• immediate: Tingkat ini digunakan untuk menerapkan spekulasi sesegera mungkin, yaitu tepat setelah aturan spekulasi diamati.
• eager: Tingkat ini saat ini berperilaku serupa dengan setelan immediate, tetapi kami akan menempatkannya di antara immediate dan moderate pada masa mendatang.
• moderate: Tingkat ini menerapkan spekulasi jika Anda mengarahkan kursor ke link selama 200 milidetik (atau pada peristiwa pointerdown jika lebih cepat, dan pada perangkat seluler yang tidak menggunakan peristiwa hover).
• conservative: Tingkat ini menerapkan spekulasi 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 sangat sederhana, spekulasi yang lebih cepat mungkin tidak akan menimbulkan banyak biaya dan bermanfaat bagi pengguna. Situs dengan arsitektur yang lebih kompleks dan payload halaman yang lebih berat mungkin lebih memilih untuk mengurangi pemborosan dengan lebih jarang berspekulasi hingga Anda mendapatkan sinyal niat yang lebih positif dari pengguna untuk membatasi pemborosan.

Perhatian: Spekulasi yang berlebihan memiliki biaya yang jelas bagi pengguna untuk biaya bandwidth, memori, dan CPU, tetapi juga untuk situs itu sendiri. Perhatikan dampak yang Anda berikan kepada pengguna saat menerapkan spekulasi. Setelan eagerness memungkinkan Anda mengurangi kemungkinan spekulasi yang sia-sia. Chrome juga menerapkan batas pada spekulasi untuk mengurangi dampak penggunaan yang berlebihan.

Opsi moderate adalah jalan tengah, dan banyak situs dapat memanfaatkan aturan spekulasi sederhana berikut yang akan melakukan pra-rendering semua link saat kursor diarahkan atau pointerdown sebagai implementasi dasar—namun efektif—dari aturan spekulasi:

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

Batas Chrome

Meskipun dengan pilihan eagerness, Chrome memiliki batas untuk mencegah penggunaan berlebihan API ini:

eagerness	Prefetch	Pra-render
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.

Fakta bahwa spekulasi moderate dan conservative dipicu oleh pengguna memungkinkan kita menggunakan nilai minimum 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 mana yang diperlukan dan kapan diperlukan.

Spekulasi yang dibatalkan dengan dikeluarkan dari antrean FIFO dapat dipicu lagi—misalnya dengan mengarahkan kursor ke link tersebut lagi—yang akan menyebabkan URL tersebut di-spekulasi ulang. Dalam hal ini, spekulasi sebelumnya kemungkinan akan menyebabkan browser menyimpan beberapa resource dalam Cache HTTP untuk URL tersebut, sehingga mengulangi spekulasi akan mengurangi biaya jaringan dan waktu.

Batas immediate dan eager juga bersifat dinamis. Menghapus elemen skrip aturan spekulasi menggunakan tingkat kegigihan ini akan menciptakan kapasitas dengan membatalkan spekulasi yang dihapus tersebut. URL ini juga dapat di-spekulasi ulang jika disertakan dalam skrip URL baru dan batasnya belum tercapai.

Chrome juga akan mencegah spekulasi digunakan dalam kondisi tertentu, termasuk:

• Save-Data.
• Penghemat energi.
• Batasan memori.
• Jika setelan "Preload halaman" dinonaktifkan (yang juga dinonaktifkan secara eksplisit oleh ekstensi Chrome seperti uBlock Origin).
• Halaman yang dibuka di tab latar belakang.

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

source opsional

Chrome 122 membuat kunci source bersifat opsional karena 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 dikirim menggunakan header HTTP Speculation-Rules, bukan menyertakannya langsung dalam HTML dokumen. Hal ini memungkinkan deployment yang lebih mudah oleh CDN tanpa perlu mengubah konten dokumen itu sendiri.

Header HTTP Speculation-Rules ditampilkan dengan dokumen, dan mengarah ke lokasi file JSON yang berisi aturan spekulasi:

Speculation-Rules: "/speculationrules.json"

Peringatan: Karena ini adalah header terstruktur, tanda kutip sangat penting dan harus disertakan dalam nilai header.

Resource ini harus menggunakan jenis MIME yang benar dan, jika merupakan resource lintas-asal, lulus pemeriksaan CORS.

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

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

Penggunaan kembali cache yang lebih baik

Kami telah melakukan sejumlah peningkatan pada penyimpanan dalam cache di Chrome sehingga pengambilan data (atau bahkan pra-rendering) dokumen akan menyimpan dan menggunakan kembali resource di cache HTTP. Artinya, spekulasi masih dapat memberikan manfaat di masa mendatang, meskipun spekulasi tersebut tidak digunakan.

Hal ini juga membuat spekulasi ulang (misalnya, untuk aturan dokumen dengan setelan kesiapan 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 pramuat atau pra-rendering halaman, parameter URL tertentu (secara teknis dikenal sebagai parameter penelusuran) mungkin tidak penting untuk halaman yang sebenarnya dikirimkan oleh server, dan hanya digunakan oleh JavaScript sisi klien.

Misalnya, parameter UTM digunakan oleh Google Analytics untuk pengukuran kampanye, tetapi biasanya tidak menghasilkan halaman yang berbeda yang dikirim dari server. Ini berarti page1.html?utm_content=123 dan page1.html?utm_content=456 akan mengirimkan halaman yang sama dari server, sehingga halaman yang sama dapat digunakan kembali dari cache.

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

Proposal No-Vary-Search memungkinkan server menentukan parameter yang tidak menghasilkan perbedaan pada resource yang dikirim, sehingga memungkinkan browser menggunakan kembali versi dokumen yang di-cache sebelumnya yang hanya berbeda dengan parameter ini. Catatan: saat ini, fitur ini hanya didukung di Chrome (dan browser berbasis Chromium) untuk spekulasi navigasi pengambilan data sebelumnya.

Aturan spekulasi mendukung penggunaan expects_no_vary_search untuk menunjukkan tempat header HTTP No-Vary-Search diharapkan ditampilkan. Tindakan ini dapat membantu menghindari lebih lanjut 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, kami akan melakukan pramuat URL tersebut dengan cepat dan URL tersebut akan menampilkan header HTTP No-Vary-Search yang menunjukkan bahwa halaman dapat digunakan untuk parameter penelusuran id apa pun.

Namun, jika pengguna mengklik link sebelum pengambilan data selesai, browser mungkin belum menerima halaman /products. Dalam hal ini, browser tidak tahu apakah akan berisi header HTTP No-Vary-Search. Browser kemudian memiliki pilihan untuk mengambil link lagi, atau menunggu pramuat selesai untuk melihat apakah link tersebut berisi header HTTP No-Vary-Search. Setelan expects_no_vary_search memungkinkan browser mengetahui bahwa respons halaman diharapkan berisi header HTTP No-Vary-Search, dan menunggu prefetch tersebut selesai.

Demo

Kami telah membuat demo di https://speculative-rules.glitch.me/common-fruits.html yang dapat digunakan untuk melihat aturan dokumen dengan setelan kesiapan moderate yang sedang berjalan:

Demo aturan spekulasi

Buka DevTools, klik panel Application. Kemudian, di bagian Background services, klik Speculative loads, lalu panel Speculations, dan urutkan menurut kolom Status.

Saat mengarahkan kursor ke buah, Anda akan melihat halaman diprarender. 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 melihat postingan blog tentang proses debug aturan spekulasi sebelumnya untuk mengetahui informasi selengkapnya tentang cara menggunakan DevTools untuk men-debug aturan spekulasi.

Dukungan platform untuk aturan spekulasi

Meskipun aturan spekulasi relatif mudah diterapkan dengan memasukkan aturan ke dalam elemen <script type="speculationrules">, dukungan platform dapat menjadikannya sebagai tindakan 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 yang menarik ini jika mereka memilih untuk melakukannya.

WordPress

Tim Performa WordPress Core (termasuk developer dari Google), membuat plugin Speculation Rules. Plugin ini memungkinkan penambahan dukungan aturan dokumen dengan sekali klik ke situs WordPress mana pun. Plugin ini juga tersedia untuk diinstal melalui plugin WordPress Performance Lab, yang juga harus Anda pertimbangkan untuk diinstal karena akan terus memberi tahu Anda tentang plugin performa terkait dari tim.

Ada dua grup setelan yang tersedia: setelan Mode spekulasi dan Keinginan:

Plugin Aturan Spekulasi WordPress

Untuk penyiapan yang lebih rumit—misalnya, untuk mengecualikan URL tertentu agar tidak dipramuat atau diprarender—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 mengaktifkan API ini di setelan CDN mereka. Mereka juga sebelumnya telah membagikan hasil yang mengesankan yang dapat diperoleh dengan API baru ini.

NitroPack

NitroPack adalah solusi pengoptimalan performa yang menggunakan AI Navigasi kustom untuk memprediksi halaman mana yang akan ditambahkan ke aturan spekulasi, yang bertujuan untuk memberikan waktu tunggu yang lebih lama daripada mengarahkan kursor ke link, tetapi tanpa membuang-buang waktu untuk berspekulasi secara tidak perlu pada semua link yang diamati. Lihat dokumentasi Nitropack Speculation Rules API untuk mengetahui informasi selengkapnya. Solusi inovatif ini menunjukkan bahwa aturan daftar lama masih memiliki banyak hal yang dapat ditawarkan jika dikombinasikan dengan insight khusus situs.

Tim Chrome juga bekerja sama dengan NitroPack dalam webinar untuk Speculation Rules API bagi mereka yang mencari informasi selengkapnya, termasuk diskusi yang baik tentang pertimbangan yang diperlukan antara berspekulasi lebih awal dan lebih sering, serta lebih lambat dan lebih jarang.

Astro

Astro menambahkan pra-rendering halaman menggunakan Speculation Rules API di 4.2 secara eksperimental, sehingga developer yang menggunakan Astro dapat 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 mengetahui informasi selengkapnya.

Kesimpulan

Penambahan ini ke Speculation Rules API memungkinkan penggunaan fitur performa baru yang menarik ini untuk situs dengan lebih mudah, dengan risiko yang lebih kecil untuk membuang-buang resource dengan spekulasi yang tidak digunakan. Sangat menarik melihat platform yang sudah menggunakan API ini. Kami berharap dapat melihat adopsi API ini yang lebih luas pada tahun 2024, dan pada akhirnya performa yang lebih baik bagi pengguna akhir.

Selain peningkatan performa yang diberikan Speculation Rules API, kami juga menantikan peluang baru yang akan 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 balik flag di Chrome). Pra-rendering adalah add-on alami untuk fitur tersebut guna memastikan tidak ada penundaan, yang akan mencegah peningkatan pengalaman pengguna yang dimaksudkan oleh transisi. Kami telah melihat situs 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.

Ucapan terima kasih

Thumbnail oleh Robbie Down di Unsplash