Chrome melakukan perubahan untuk mengizinkan penggunaan back/forward cache (bfcache) untuk halaman yang menggunakan Cache-Control: no-store jika ini aman untuk dilakukan. Cari tahu 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 diperlukan oleh spesifikasi HTML, browser biasanya menganggap 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 disetel untuk menghindari masalah penyimpanan dalam cache saat situs berubah, tetapi alasan ini kurang relevan saat bfcache digunakan, karena halaman lengkap dipulihkan hampir seolah-olah dibiarkan terbuka selama ini.
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 meningkatkan ini menjadi 10% dari pemuatan halaman pada 2 Oktober dan bermaksud meningkatkannya lebih lanjut menjadi 20% dari pemuatan halaman pada bulan November, 50% di awal tahun depan, meluncurkan ini sepenuhnya segera setelahnya, dengan pilihan untuk tidak ikut yang dibahas selanjutnya.
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, halaman login tidak dapat diambil dengan menavigasi maju atau mundur.
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 jika API tersebut tidak digunakan 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.
Memilih tidak ikut untuk 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 harus 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. Pertimbangan ini adalah hal serupa yang mungkin dialami situs lain dalam peluncuran awal bfcache pada Desember 2021.
Dampak pada 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 pada pemulihan halaman
Karena situs sekarang dapat melihat penggunaan bfcache saat mereka tidak melihat ini sebelumnya dan saat halaman akan dimuat ulang sepenuhnya dengan data baru, developer mungkin ingin 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 pada 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 Issue Tracker 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.