Peningkatan pada Speculation Rules API

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 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 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)
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 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:

Screenshot situs demo yang dibuat di glitch yang mencantumkan sejumlah link yang diberi label buah. DevTools terbuka dan menampilkan dua link (apple.html dan orange.html) yang sudah berhasil dipra-render.
Demo aturan spekulasi

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:

Screenshot panel Bacaan Setelan WordPress dengan setelan Aturan Spekulasi. Ada dua opsi: Mode Spekulasi dengan opsi Prefetch atau Pra-rendering, dan setelan Keinginan dengan setelan Konservatif, Sedang, atau Bersemangat.
Plugin WordPress Speculation Rules

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