Chrome melakukan perubahan untuk mengizinkan penggunaan cache kembali/maju (bfcache) untuk halaman yang menggunakan Cache-Control: no-store jika aman untuk dilakukan. Cari tahu apa artinya bagi developer.
Latar belakang
Menetapkan Cache-Control: no-store sebagai Header HTTP adalah sinyal bahwa halaman tidak boleh disimpan di cache HTTP. Ini harus digunakan untuk halaman yang berisi data sensitif—misalnya, untuk halaman saat pengguna login—tetapi perintah no-store sering digunakan di halaman tanpa data sensitif.
Dengan bfcache, kami menunda pemusnahan dan menjeda eksekusi JS, bukan menghancurkan halaman saat pengguna keluar. Jika pengguna segera kembali, kami akan membuat halaman terlihat lagi dan melanjutkan jeda eksekusi JS. Hal ini menghasilkan navigasi halaman yang hampir instan bagi pengguna.
Meskipun tidak diwajibkan oleh spesifikasi HTML, browser biasanya menggunakan Cache-Control: no-store sebagai sinyal untuk menghindari penempatan halaman di bfcache. Hal ini adalah alasan terbesar bfcache tidak digunakan, untuk sekitar 17% navigasi histori di perangkat seluler dan 7% navigasi histori di desktop. Artinya, halaman ini tidak mendapatkan manfaat dari pemulihan cepat dan harus memuat ulang halaman sepenuhnya, termasuk panggilan jaringan, eksekusi JavaScript, dan rendering.
Sering kali Cache-Control: no-store ditetapkan untuk menghindari masalah penyimpanan dalam cache saat situs berubah, tetapi alasan ini kurang relevan saat bfcache digunakan, karena halaman lengkap dipulihkan hampir seolah-olah halaman tersebut telah dibiarkan terbuka sepanjang waktu.
Cara Chrome mengubah perilaku ini
Chrome telah mengumumkan niat untuk mengubah perilaku ini, tetapi mengambil pendekatan yang hati-hati terhadap perubahan ini. Kami telah menjalankan eksperimen sejak Chrome 116 dan hingga baru-baru ini eksperimen tersebut berjalan pada 5% pemuatan halaman.
Kami meningkatkannya menjadi 10% pemuatan halaman pada 2 Oktober dan bermaksud untuk meningkatkannya lebih lanjut menjadi 20% pemuatan halaman pada November, 50% pada awal tahun depan, dan meluncurkannya sepenuhnya setelah itu, dengan pengecualian tertentu yang akan dibahas berikutnya.
Data sensitif
Meskipun analisis kami menunjukkan bahwa sebagian besar navigasi kembali atau maju tidak menyertakan data sensitif sehingga harus memenuhi syarat untuk bfcache, ada kasus saat halaman tidak boleh ditempatkan di bfcache. Misalnya, saat logout, Anda tidak akan dapat mengambil halaman login dengan menavigasi kembali atau maju.
Untuk menghindari hal ini, Chrome akan mengeluarkan halaman dari bfcache saat ada perubahan pada cookie, atau metode otorisasi lainnya.
Selain itu, penggunaan API berikut untuk halaman yang menggunakan Cache-Control: no-store akan terus membuat halaman tersebut tidak memenuhi syarat untuk bfcache:
Perhatikan bahwa ini bukan daftar lengkap API yang mencegah penggunaan bfcache, tetapi API yang memblokir bfcache di halaman Cache-Control: no-store meskipun tidak digunakan pada saat keluar dari halaman.
Waktu tunggu bfcache untuk halaman Cache-Control: no-store juga dikurangi menjadi 3 menit (dari 10 menit yang digunakan untuk halaman yang tidak menggunakan Cache-Control: no-store) untuk lebih mengurangi risiko.
Pilihan tidak ikut perusahaan
Perusahaan sering kali memiliki software yang sulit diupdate dan perangkat bersama. Kebijakan AllowBackForwardCacheForCacheControlNoStorePageEnabled dapat dinonaktifkan untuk terus mencegah penggunaan bfcache untuk halaman Cache-Control: no-store.
Menguji perubahan
Developer dapat menguji perubahan ini dengan flag berikut:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Jika salah satu pengecualian sebelumnya berlaku—misalnya, cookie berubah—hal ini akan mencegah halaman menggunakan bfcache dengan alasan "Halaman yang resource utamanya memiliki Cache-Control: no-store tidak dapat masuk ke cache kembali/maju" yang ditampilkan di penguji bfcache Chrome DevTools.
Anda dapat menggunakan halaman pengujian bfcache ini untuk menguji dengan dan tanpa tanda ini.
Yang perlu diketahui developer
Meskipun developer tidak perlu melakukan perubahan apa pun agar penggunanya dapat memanfaatkan penggunaan bfcache yang lebih besar ini, ada beberapa hal yang mungkin perlu mereka pertimbangkan sebagai hasilnya. Hal ini merupakan pertimbangan serupa yang mungkin dialami situs lain pada peluncuran awal bfcache pada Desember 2021.
Dampak terhadap performa
Alasan kami melakukan perubahan ini adalah untuk meningkatkan pengalaman halaman bagi pengguna di web. Kami melihat peningkatan yang signifikan pada Data Web Inti saat pertama kali meluncurkan bfcache, dan sekarang kami ingin menghadirkan peningkatan yang sama ke lebih banyak situs.
Pemilik situs mungkin melihat peningkatan pada Core Web Vitals saat fitur ini diluncurkan, dan dapat mengukur penggunaan bfcache di CrUX, termasuk di Dasbor CrUX.
Analisis dampak
Halaman yang dipulihkan dari bfcache "memulihkan" halaman lama (termasuk heap JavaScript) dan bukan memuat ulang halaman. Banyak penyedia analisis populer tidak mengukur pemulihan bfcache sebagai kunjungan halaman baru karena hanya memicu kunjungan halaman saat pertama kali dimuat.
Oleh karena itu, situs mungkin mengalami penurunan pemuatan halaman di analisis saat mulai menggunakan bfcache untuk pertama kalinya. Sebaiknya pertimbangkan hal ini sebagai kunjungan halaman, dengan menetapkan pemroses untuk peristiwa pageshow dan memeriksa properti persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
Menangani pembaruan saat halaman dipulihkan
Karena situs kini dapat melihat penggunaan bfcache saat sebelumnya tidak melihatnya dan saat halaman akan dimuat ulang sepenuhnya dengan data baru, developer dapat mempertimbangkan untuk memuat ulang data pada pemulihan bfcache.
Pembaruan dapat dipicu dengan cara yang serupa dengan mencatat kunjungan halaman tambahan untuk analisis menggunakan peristiwa pageshow dan memeriksa properti persisted.
Perhatikan bahwa tidak semua konten perlu diperbarui dan pengguna mungkin lebih suka "kembali" ke konten yang mereka lihat sebelumnya. Misalnya, memuat ulang daftar artikel dapat berarti pengguna tidak lagi melihat artikel yang ingin mereka lihat kembali.
Dampak terhadap iklan
Serupa dengan dampak analisis, situs mungkin mengalami penurunan tayangan iklan jika iklan hanya dimuat saat halaman dimuat. Iklan dapat diperbarui secara terprogram saat pemulihan bfcache untuk memastikan paritas dengan pemuatan halaman penuh, lagi-lagi menggunakan peristiwa pageshow dan memeriksa properti persisted, tetapi mungkin tidak selalu merupakan tindakan yang tepat. Lihat dokumentasi penyedia iklan Anda tentang cara memicu pemuatan ulang iklan.
Informasi selengkapnya tentang bfcache
Untuk informasi selengkapnya tentang bfcache, lihat panduan teknis bfcache yang komprehensif.
Masukan
Kami ingin mendengar masukan tentang perubahan ini yang dapat diberikan di pelacak masalah Chrome menggunakan komponen bfcache.
Kesimpulan
Kami senang dapat menghadirkan manfaat bfcache ke lebih banyak halaman untuk meningkatkan kualitas halaman bagi pengguna. Kami telah mempertimbangkan perubahan ini dengan cermat dan pendekatan kami berupaya meluncurkannya dengan cara yang seaman mungkin. Kami harap informasi yang diberikan di sini akan membantu developer memahami perubahan ini dan melakukan perubahan yang diperlukan untuk menghindari masalah saat hal ini terjadi.