Back-forward cache (atau bfcache) adalah pengoptimalan browser yang memungkinkan navigasi mundur dan maju. Secara signifikan meningkatkan pengalaman menjelajah, terutama untuk pengguna dengan jaringan atau perangkat yang lebih lambat.
Sebagai developer web, sangat penting untuk memahami cara mengoptimalkan halaman Anda untuk bfcache, sehingga pengguna dapat memperoleh manfaatnya.
Kompatibilitas browser
bfcache telah didukung di Firefox dan Safari selama bertahun-tahun, di desktop dan perangkat seluler.
Mulai versi 86, Chrome mengaktifkan bfcache untuk navigasi lintas situs di Android bagi sebagian kecil pengguna. Dalam rilis berikutnya, dukungan tambahan diluncurkan secara perlahan. Sejak versi 96, bfcache diaktifkan untuk semua pengguna Chrome di desktop dan perangkat seluler.
Dasar-dasar bfcache
bfcache adalah cache dalam memori yang menyimpan cuplikan lengkap sebuah halaman (termasuk heap JavaScript) saat pengguna keluar. Dengan seluruh halaman berada di memori, browser dapat memulihkannya dengan cepat jika pengguna memutuskan untuk kembali.
Berapa kali Anda mengunjungi situs dan mengklik link untuk membuka halaman lain, tetapi ternyata itu tidak sesuai dengan keinginan Anda lalu mengklik tombol kembali? Pada saat itu, bfcache dapat membuat perbedaan besar dalam seberapa cepat halaman sebelumnya dimuat:
Tanpa bfcache yang diaktifkan | Permintaan baru dimulai untuk memuat halaman sebelumnya, dan, bergantung pada seberapa baik halaman tersebut telah dioptimalkan untuk kunjungan berulang, browser mungkin harus mendownload ulang, memilah ulang, dan menjalankan kembali beberapa (atau semua) resource yang baru saja didownload. |
Dengan bfcache yang diaktifkan | Pemuatan halaman sebelumnya pada dasarnya instan, karena seluruh halaman dapat dipulihkan dari memori, tanpa harus membuka jaringan sama sekali. |
Lihat video cara kerja bfcache ini untuk memahami kecepatan yang dapat ditimbulkannya untuk navigasi:
Dalam video, contoh dengan bfcache sedikit lebih cepat daripada contoh tanpanya.
bfcache tidak hanya mempercepat navigasi, tetapi juga mengurangi penggunaan data, karena resource tidak perlu didownload lagi.
Data penggunaan Chrome menunjukkan bahwa 1 dari 10 navigasi di desktop dan 1 dari 5 di perangkat seluler bersifat mundur atau maju. Dengan mengaktifkan bfcache, browser dapat mengurangi transfer data dan waktu yang dihabiskan untuk memuat miliaran halaman web setiap harinya.
Bagaimana "cache" bekerja
"Cache" yang digunakan oleh bfcache berbeda dengan cache HTTP, yang memainkan perannya sendiri dalam mempercepat navigasi berulang. bfcache adalah snapshot seluruh halaman di memori, termasuk heap JavaScript, sedangkan cache HTTP hanya berisi respons untuk permintaan yang dibuat sebelumnya. Karena sangat jarang semua permintaan yang diperlukan untuk memuat halaman harus dipenuhi dari cache HTTP, kunjungan berulang yang menggunakan pemulihan bfcache selalu lebih cepat daripada navigasi non-bfcache yang paling dioptimalkan dengan baik.
Namun, membuat snapshot halaman dalam memori melibatkan beberapa kerumitan dalam hal cara terbaik untuk mempertahankan kode yang sedang berlangsung. Misalnya, bagaimana cara menangani panggilan setTimeout()
saat waktu tunggu habis saat halaman berada dalam bfcache?
Jawabannya adalah browser menjeda timer yang tertunda atau promise yang belum terselesaikan untuk halaman di bfcache, termasuk hampir semua tugas yang tertunda di task queue JavaScript, dan melanjutkan tugas pemrosesan jika halaman dipulihkan dari bfcache.
Dalam beberapa kasus, seperti untuk waktu tunggu dan promise, ini memiliki risiko yang cukup rendah, tetapi dalam kasus lain, hal ini dapat menyebabkan perilaku yang membingungkan atau tidak terduga. Misalnya, jika browser menjeda tugas yang diperlukan sebagai bagian dari postingan transaksi, hal ini dapat memengaruhi tab terbuka lainnya dari asal yang sama, karena database IndexedDB yang sama dapat diakses oleh beberapa tab secara bersamaan. Akibatnya, browser umumnya tidak akan berupaya meng-cache halaman di tengah transaksi IndexedDB atau saat menggunakan API yang mungkin memengaruhi halaman lainnya.
Untuk detail selengkapnya tentang pengaruh berbagai penggunaan API terhadap kelayakan bfcache halaman, lihat Mengoptimalkan halaman untuk bfcache.
Bfcache dan iframe
Jika halaman berisi iframe tersemat, iframe tersebut tidak memenuhi syarat untuk bfcache. Misalnya, jika Anda menavigasi ke halaman lain dalam iframe, tetapi kemudian kembali, browser akan "kembali" dalam iframe bukan di bingkai utama, namun navigasi kembali dalam iframe tidak akan menggunakan bfcache.
Frame utama juga dapat diblokir agar tidak menggunakan bfcache jika iframe tersemat menggunakan API yang memblokirnya. Kebijakan Izin yang ditetapkan di frame utama atau penggunaan atribut sandbox
dapat digunakan untuk menghindari hal ini.
bfcache dan Aplikasi Web Satu Halaman (SPA)
Karena bfcache berfungsi dengan navigasi yang dikelola browser, bfcache tidak berfungsi untuk "navigasi ringan" dalam aplikasi web satu halaman (SPA). Namun, bfcache masih dapat membantu saat kembali ke SPA, bukan melakukan inisialisasi ulang penuh aplikasi tersebut dari awal.
API untuk mengamati bfcache
Meskipun bfcache adalah pengoptimalan yang dilakukan browser secara otomatis, penting bagi developer untuk mengetahui kapan bfcache terjadi agar mereka dapat mengoptimalkan halaman mereka untuk hal itu dan menyesuaikan metrik atau pengukuran performa.
Peristiwa utama yang digunakan untuk mengamati bfcache adalah peristiwa transisi halaman pageshow
dan pagehide
, yang didukung oleh sebagian besar browser.
Peristiwa Page Lifecycle yang lebih baru—freeze
dan resume
—juga dikirim saat halaman masuk atau keluar dari bfcache, serta di beberapa situasi lain, misalnya, saat tab latar belakang berhenti berfungsi untuk meminimalkan penggunaan CPU. Peristiwa ini hanya didukung di browser berbasis Chromium.
Amati saat halaman dipulihkan dari bfcache
Peristiwa pageshow
diaktifkan tepat setelah peristiwa load
saat halaman pertama kali dimuat dan setiap kali halaman dipulihkan dari bfcache. Peristiwa pageshow
memiliki properti persisted
, yang merupakan true
jika halaman dipulihkan dari bfcache dan false
sebaliknya. Anda dapat menggunakan properti persisted
untuk membedakan pemuatan halaman reguler dari pemulihan bfcache. Contoh:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
console.log('This page was restored from the bfcache.');
} else {
console.log('This page was loaded normally.');
}
});
Di browser yang mendukung Page Lifecycle API, peristiwa resume
aktif saat halaman dipulihkan dari bfcache (tepat sebelum peristiwa pageshow
) dan saat pengguna membuka kembali tab latar belakang yang dibekukan. Jika ingin memperbarui status halaman setelah dibekukan (yang mencakup halaman dalam bfcache), Anda dapat menggunakan peristiwa resume
. Namun, jika ingin mengukur rasio hit bfcache situs, Anda harus menggunakan peristiwa pageshow
. Dalam beberapa kasus, Anda mungkin perlu menggunakan keduanya.
Untuk mengetahui detail tentang praktik terbaik pengukuran bfcache, lihat Pengaruh bfcache terhadap analisis dan pengukuran performa.
Amati saat halaman memasukkan bfcache
Peristiwa pagehide
diaktifkan saat halaman menghapus muatan atau saat browser mencoba memasukkannya ke dalam bfcache.
Peristiwa pagehide
juga memiliki properti persisted
. Jika yang ditampilkan adalah false
, Anda dapat yakin bahwa halaman tersebut tidak akan memasukkan bfcache. Namun, persisted
menjadi true
tidak menjamin halaman akan di-cache. Artinya, browser dimaksudkan untuk meng-cache halaman, tetapi mungkin ada faktor lain yang membuat cache tidak mungkin dilakukan.
window.addEventListener('pagehide', (event) => {
if (event.persisted) {
console.log('This page *might* be entering the bfcache.');
} else {
console.log('This page will unload normally and be discarded.');
}
});
Demikian pula, peristiwa freeze
diaktifkan tepat setelah peristiwa pagehide
jika persisted
adalah true
, tetapi itu hanya berarti browser dimaksudkan untuk meng-cache halaman. Akun mungkin masih harus membuangnya karena sejumlah alasan yang dijelaskan nanti.
Optimalkan halaman Anda untuk bfcache
Tidak semua halaman disimpan di bfcache, dan meskipun halaman disimpan di sana, halaman tersebut tidak akan berada di sana tanpa batas waktu. Penting bagi developer untuk memahami apa yang membuat halaman memenuhi syarat (dan tidak memenuhi syarat) untuk bfcache guna memaksimalkan rasio cache ditemukan.
Bagian berikut menguraikan praktik terbaik untuk memastikan sebanyak mungkin browser dapat meng-cache halaman Anda.
Jangan pernah gunakan peristiwa unload
Cara terpenting untuk mengoptimalkan bfcache di semua browser adalah dengan tidak pernah menggunakan peristiwa unload
. Sama sekali!
Peristiwa unload
bermasalah bagi browser karena terjadi sebelum bfcache dan banyak halaman di internet beroperasi dengan asumsi (wajar) bahwa halaman akan berhenti ada setelah peristiwa unload
diaktifkan. Hal ini menimbulkan tantangan karena banyak dari halaman tersebut juga dibuat dengan asumsi bahwa peristiwa unload
akan aktif setiap kali pengguna keluar, dan ini tidak lagi benar (dan sudah lama tidak berlaku).
Jadi, browser dihadapkan dengan dilema, mereka harus memilih antara sesuatu yang dapat meningkatkan pengalaman pengguna—tetapi juga berisiko merusak halaman.
Di desktop, Chrome dan Firefox telah memilih untuk membuat halaman tidak memenuhi syarat untuk bfcache jika mereka menambahkan pemroses unload
, yang tidak terlalu berisiko, tetapi juga mendiskualifikasi banyak halaman. Safari akan mencoba menyimpan beberapa halaman ke dalam cache dengan pemroses peristiwa unload
, tetapi untuk mengurangi potensi kerusakan, Safari tidak akan menjalankan peristiwa unload
saat pengguna keluar, sehingga peristiwa tersebut sangat tidak dapat diandalkan.
Di perangkat seluler, Chrome dan Safari akan mencoba meng-cache halaman dengan pemroses peristiwa unload
karena risiko kerusakan lebih rendah karena peristiwa unload
selalu sangat tidak dapat diandalkan di perangkat seluler. Firefox memperlakukan halaman yang menggunakan unload
sebagai tidak memenuhi syarat untuk bfcache, kecuali di iOS, yang mengharuskan semua browser menggunakan mesin rendering WebKit, sehingga berperilaku seperti Safari.
Gunakan peristiwa pagehide
, bukan peristiwa unload
. Peristiwa pagehide
diaktifkan di semua kasus saat peristiwa unload
diaktifkan, dan juga diaktifkan saat halaman dimasukkan ke dalam bfcache.
Bahkan, Lighthouse memiliki audit no-unload-listeners
, yang akan memperingatkan developer jika ada JavaScript di halaman mereka (termasuk JavaScript dari library pihak ketiga) yang menambahkan pemroses peristiwa unload
.
Karena tidak dapat diandalkan, dan dampak performa bfcache, Chrome ingin menghentikan peristiwa unload
.
Menggunakan Kebijakan Izin untuk mencegah penggunaan pengendali penghapusan muatan di halaman
Situs yang tidak menggunakan pengendali peristiwa unload
dapat memastikan bahwa situs tersebut tidak ditambahkan dengan menggunakan Kebijakan Izin.
Permission-Policy: unload=()
Hal ini juga mencegah pihak ketiga atau ekstensi memperlambat situs dengan menambahkan pengendali penghapusan muatan dan membuat situs tidak memenuhi syarat untuk bfcache.
Hanya tambahkan pemroses beforeunload
secara bersyarat
Peristiwa beforeunload
tidak akan membuat halaman Anda tidak memenuhi syarat untuk bfcache di bfcache browser modern, tetapi sebelumnya telah melakukannya dan masih tidak dapat diandalkan. Jadi, hindari menggunakannya kecuali jika benar-benar diperlukan.
Namun, tidak seperti peristiwa unload
, terdapat penggunaan yang sah untuk
beforeunload
. Misalnya, ketika Anda ingin memperingatkan
pengguna bahwa mereka telah
perubahan yang belum disimpan akan hilang jika mereka meninggalkan halaman. Dalam hal ini,
sebaiknya Anda hanya menambahkan pemroses beforeunload
saat pengguna memiliki data yang belum disimpan
perubahan, lalu segera menghapusnya setelah perubahan yang belum disimpan disimpan.
window.addEventListener('beforeunload', (event) => { if (pageHasUnsavedChanges()) { event.preventDefault(); return event.returnValue = 'Are you sure you want to exit?'; } });Kode ini menambahkan pemroses
beforeunload
tanpa syarat.
function beforeUnloadListener(event) { event.preventDefault(); return event.returnValue = 'Are you sure you want to exit?'; }; // A function that invokes a callback when the page has unsaved changes. onPageHasUnsavedChanges(() => { window.addEventListener('beforeunload', beforeUnloadListener); }); // A function that invokes a callback when the page's unsaved changes are resolved. onAllChangesSaved(() => { window.removeEventListener('beforeunload', beforeUnloadListener); });Kode ini hanya menambahkan pemroses
beforeunload
saat diperlukan (dan
akan menghapusnya jika tidak).
Minimalkan penggunaan Cache-Control: no-store
Cache-Control: no-store
adalah server web header HTTP yang dapat disetel pada respons yang menginstruksikan browser untuk tidak menyimpan respons dalam cache HTTP apa pun. Objek ini digunakan untuk resource yang berisi informasi pengguna sensitif, seperti halaman di belakang login.
Meskipun bfcache bukan cache HTTP, secara historis, saat Cache-Control: no-store
ditetapkan pada resource halaman itu sendiri (bukan subresource apa pun), browser telah memilih untuk tidak menyimpan halaman dalam bfcache. Ada upaya yang sedang dilakukan untuk mengubah perilaku ini untuk Chrome dengan cara yang menjaga privasi, tetapi untuk saat ini, semua halaman yang menggunakan Cache-Control: no-store
tidak akan memenuhi syarat untuk bfcache.
Karena Cache-Control: no-store
membatasi kelayakan halaman untuk bfcache, parameter tersebut hanya boleh ditetapkan di halaman yang berisi informasi sensitif, dan cache dalam bentuk apa pun tidak akan sesuai.
Untuk halaman yang harus selalu menampilkan konten terbaru—dan konten tersebut tidak berisi informasi sensitif—gunakan Cache-Control: no-cache
atau Cache-Control: max-age=0
. Perintah ini menginstruksikan browser untuk memvalidasi ulang konten sebelum menayangkannya dan tidak memengaruhi kelayakan bfcache halaman.
Perhatikan bahwa saat halaman dipulihkan dari bfcache, halaman tersebut akan dipulihkan dari memori, bukan dari cache HTTP. Akibatnya, perintah seperti Cache-Control: no-cache
atau Cache-Control: max-age=0
tidak dipertimbangkan, dan tidak ada validasi ulang yang dilakukan sebelum konten ditampilkan kepada pengguna.
Namun, hal ini kemungkinan masih akan menjadi pengalaman pengguna yang lebih baik karena pemulihan bfcache bersifat instan dan—karena halaman tidak lama berada di bfcache—mungkin kontennya sudah usang. Namun, jika konten Anda berubah dari menit ke menit, Anda dapat mengambil update menggunakan peristiwa pageshow
, seperti yang dijelaskan di bagian berikutnya.
Memperbarui data yang usang atau sensitif setelah pemulihan bfcache
Jika situs Anda mempertahankan status pengguna—terutama informasi pengguna yang sensitif—data tersebut perlu diperbarui atau dihapus setelah halaman dipulihkan dari bfcache.
Misalnya, jika pengguna membuka halaman checkout, lalu memperbarui keranjang belanjanya, navigasi kembali berpotensi menampilkan informasi yang sudah tidak berlaku jika halaman usang dipulihkan dari bfcache.
Contoh lain yang lebih penting adalah jika pengguna logout dari situs di komputer publik dan pengguna berikutnya mengklik tombol kembali. Hal ini berpotensi mengekspos data pribadi yang dianggap pengguna telah dihapus saat mereka logout.
Untuk menghindari situasi seperti ini, sebaiknya selalu perbarui halaman setelah peristiwa pageshow
jika event.persisted
adalah true
:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Do any checks and updates to the page
}
});
Idealnya, Anda perlu memperbarui konten di tempat, tetapi untuk beberapa perubahan, Anda mungkin ingin memaksa pemuatan ulang sepenuhnya. Kode berikut memeriksa keberadaan cookie khusus situs di peristiwa pageshow
dan memuat ulang jika cookie tidak ditemukan:
window.addEventListener('pageshow', (event) => {
if (event.persisted && !document.cookie.match(/my-cookie)) {
// Force a reload if the user has logged out.
location.reload();
}
});
Pemuatan ulang memiliki keunggulan yang tetap akan mempertahankan histori (untuk memungkinkan navigasi maju), namun pengalihan mungkin lebih sesuai dalam beberapa kasus.
Pemulihan iklan dan bfcache
Anda mungkin ingin mencoba menghindari penggunaan bfcache untuk menayangkan kumpulan iklan baru di setiap navigasi mundur/maju. Namun, selain memiliki dampak terhadap performa, perilaku tersebut masih dipertanyakan apakah perilaku tersebut menghasilkan engagement iklan yang lebih baik. Pengguna mungkin telah melihat iklan yang ingin mereka kembalikan untuk mengklik, tetapi dengan memuat ulang, dan bukan memulihkannya dari bfcache, mereka tidak dapat melakukannya. Menguji skenario ini—idealnya dengan pengujian A/B—penting sebelum membuat asumsi.
Untuk situs yang ingin memuat ulang iklan saat pemulihan bfcache, maka memuat ulang hanya iklan pada peristiwa pageshow
saat event.persisted
adalah true
memungkinkan hal ini terjadi tanpa memengaruhi performa halaman. Hubungi penyedia iklan Anda, tetapi berikut adalah satu contoh cara melakukannya dengan Tag Google Publishing.
Hindari referensi window.opener
Di browser lama, jika halaman dibuka menggunakan window.open()
dari link dengan target=_blank
, tanpa menentukan rel="noopener"
, halaman pembuka akan memiliki referensi ke objek jendela pada halaman yang dibuka.
Selain menjadi risiko keamanan, halaman dengan referensi window.opener
non-null tidak dapat dimasukkan dengan aman ke bfcache, karena dapat merusak halaman apa pun yang mencoba mengaksesnya.
Oleh karena itu, sebaiknya hindari membuat referensi window.opener
. Anda dapat melakukannya dengan menggunakan rel="noopener"
jika memungkinkan (perhatikan, ini adalah setelan default di semua browser modern). Jika situs Anda mengharuskan untuk membuka jendela dan mengontrolnya melalui window.postMessage()
atau secara langsung merujuk objek jendela, baik jendela yang terbuka maupun pembuka tidak akan memenuhi syarat untuk bfcache.
Menutup koneksi terbuka sebelum pengguna keluar
Seperti yang disebutkan sebelumnya, saat halaman dimasukkan ke dalam bfcache, halaman ini akan menjeda semua tugas JavaScript terjadwal dan melanjutkannya saat halaman dikeluarkan dari cache.
Jika tugas JavaScript terjadwal ini hanya mengakses DOM API—atau API lain yang diisolasi hanya ke halaman saat ini—maka jeda tugas ini selagi halaman tidak terlihat oleh pengguna tidak akan menimbulkan masalah.
Akan tetapi, jika tugas ini tersambung ke API yang juga dapat diakses dari laman lain di asal yang sama (misalnya: IndexedDB, Web Locks, WebSockets), hal ini bisa bermasalah karena menghentikan sementara tugas ini dapat mencegah kode di tab lain berjalan.
Akibatnya, beberapa browser tidak akan mencoba menempatkan halaman dalam bfcache dalam skenario berikut:
- Halaman dengan koneksi IndexedDB yang terbuka
- Halaman dengan fetch() atau XMLHttpRequest yang sedang berlangsung
- Halaman dengan koneksi WebSocket atau WebRTC terbuka
Jika halaman Anda menggunakan salah satu API ini, sebaiknya tutup koneksi dan hapus atau putuskan koneksi observer selama peristiwa pagehide
atau freeze
. Cara ini memungkinkan browser meng-cache halaman dengan aman tanpa risiko memengaruhi tab terbuka lainnya.
Kemudian, jika halaman dipulihkan dari bfcache, Anda dapat membuka kembali atau menghubungkan kembali ke API tersebut selama peristiwa pageshow
atau resume
.
Contoh berikut menunjukkan cara memastikan bahwa halaman yang menggunakan IndexedDB memenuhi syarat untuk bfcache dengan menutup koneksi terbuka di pemroses peristiwa pagehide
:
let dbPromise;
function openDB() {
if (!dbPromise) {
dbPromise = new Promise((resolve, reject) => {
const req = indexedDB.open('my-db', 1);
req.onupgradeneeded = () => req.result.createObjectStore('keyval');
req.onerror = () => reject(req.error);
req.onsuccess = () => resolve(req.result);
});
}
return dbPromise;
}
// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
if (dbPromise) {
dbPromise.then(db => db.close());
dbPromise = null;
}
});
// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());
Uji untuk memastikan halaman Anda dapat di-cache
Chrome DevTools dapat membantu Anda menguji halaman untuk memastikan halaman tersebut dioptimalkan untuk bfcache, dan mengidentifikasi masalah yang mungkin mencegahnya memenuhi syarat.
Untuk menguji halaman:
- Buka halaman tersebut di Chrome.
- Di DevTools, buka Application -> Back-forward Cache.
- Klik tombol Run Test. DevTools kemudian mencoba keluar dan kembali untuk menentukan apakah halaman dapat dipulihkan dari bfcache.
![Panel back-forward cache di DevTools](https://web.dev/static/articles/bfcache/image/back-forward-cache-panel-fc27405c6cd76.png?authuser=6&hl=id)
Jika pengujian berhasil, panel akan melaporkan "Dipulihkan dari back-forward cache".
![DevTools yang melaporkan halaman berhasil dipulihkan dari bfcache](https://web.dev/static/articles/bfcache/image/devtools-reporting-page-1dd392594f6b2.png?authuser=6&hl=id)
Jika tidak berhasil, panel akan menunjukkan alasannya. Jika alasannya adalah sesuatu yang dapat Anda atasi sebagai developer, panel akan menandainya sebagai Dapat ditindaklanjuti.
![DevTools melaporkan kegagalan untuk memulihkan halaman dari bfcache](https://web.dev/static/articles/bfcache/image/devtools-reporting-failur-e962032a9c1e2.png?authuser=6&hl=id)
Dalam contoh ini, penggunaan pemroses peristiwa unload
membuat halaman tidak memenuhi syarat untuk bfcache. Anda dapat memperbaikinya dengan beralih dari unload
ke pagehide
:
window.addEventListener('pagehide', ...);
window.addEventListener('unload', ...);
Lighthouse 10.0 juga menambahkan audit bfcache, yang melakukan pengujian serupa. Untuk mengetahui informasi selengkapnya, lihat dokumen audit bfcache.
Cara bfcache memengaruhi analisis dan pengukuran performa
Jika menggunakan alat analisis untuk mengukur kunjungan ke situs, Anda mungkin melihat penurunan jumlah total kunjungan halaman yang dilaporkan karena Chrome mengaktifkan bfcache untuk lebih banyak pengguna.
Faktanya, Anda mungkin sudah tidak melaporkan tayangan halaman dari browser lain yang mengimplementasikan bfcache, karena banyak library analisis populer tidak mengukur pemulihan bfcache sebagai tayangan halaman baru.
Untuk menyertakan pemulihan bfcache dalam jumlah kunjungan halaman, tetapkan pemroses untuk peristiwa pageshow
dan periksa properti persisted
.
Contoh berikut menunjukkan cara melakukannya dengan Google Analytics. Alat analisis lainnya mungkin menggunakan logika serupa:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
window.addEventListener('pageshow', (event) => {
// Send another pageview if the page is restored from bfcache.
if (event.persisted) {
gtag('event', 'page_view');
}
});
Ukur rasio hit bfcache Anda
Anda juga dapat mengukur apakah bfcache digunakan untuk membantu mengidentifikasi halaman yang tidak menggunakan bfcache. Hal ini dapat dilakukan dengan mengukur jenis navigasi untuk pemuatan halaman:
// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
'navigation_type': performance.getEntriesByType('navigation')[0].type;
});
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Send another pageview if the page is restored from bfcache.
gtag('event', 'page_view', {
'navigation_type': 'back_forward_cache';
});
}
});
Hitung rasio hit bfcache menggunakan jumlah untuk navigasi back_forward
dan navigasi back_forward_cache
.
Penting untuk menyadari bahwa ada sejumlah skenario, di luar kontrol pemilik situs, saat navigasi Mundur/Maju tidak akan menggunakan bfcache, termasuk:
- saat pengguna keluar dari browser dan memulainya lagi
- saat pengguna menduplikasi tab
- saat pengguna menutup tab dan membukanya kembali
Dalam beberapa kasus ini, jenis navigasi asli mungkin dipertahankan oleh beberapa browser, sehingga mungkin menampilkan jenis back_forward
meskipun bukan navigasi Kembali/Maju.
Bahkan tanpa pengecualian tersebut, bfcache akan dihapus setelah periode untuk menghemat memori.
Jadi, pemilik situs tidak seharusnya mengharapkan rasio hit bfcache 100% untuk semua navigasi back_forward
. Namun, mengukur rasionya dapat berguna untuk mengidentifikasi halaman yang mencegah penggunaan bfcache untuk proporsi tinggi navigasi kembali dan maju.
Tim Chrome telah menambahkan NotRestoredReasons
API untuk membantu mengungkap alasan halaman tidak menggunakan bfcache, sehingga developer dapat meningkatkan rasio hit bfcache mereka. Tim Chrome juga telah menambahkan jenis navigasi ke CrUX yang memungkinkan Anda melihat jumlah navigasi bfcache bahkan tanpa mengukurnya sendiri.
Pengukuran performa
bfcache juga dapat berpengaruh negatif terhadap metrik performa yang dikumpulkan di kolom, khususnya metrik yang mengukur waktu muat halaman.
Karena navigasi bfcache memulihkan halaman yang ada, bukan memulai pemuatan halaman baru, jumlah total pemuatan halaman yang dikumpulkan akan berkurang saat bfcache diaktifkan. Namun, yang penting adalah pemuatan halaman yang digantikan oleh pemulihan bfcache kemungkinan akan menjadi pemuatan halaman tercepat dalam set data Anda. Hal ini karena navigasi mundur dan maju, menurut definisi, merupakan kunjungan berulang, dan pemuatan halaman berulang umumnya lebih cepat daripada pemuatan halaman dari pengunjung pertama kali (karena caching HTTP, seperti yang disebutkan sebelumnya).
Hasilnya adalah pemuatan halaman yang lebih cepat di set data Anda, yang kemungkinan akan mendistorsi distribusi lebih lambat—meskipun performa yang dialami oleh pengguna mungkin telah meningkat!
Ada beberapa cara untuk mengatasi masalah ini. Salah satunya adalah memberi anotasi pada semua metrik pemuatan halaman dengan jenis navigasi masing-masing: navigate
, reload
, back_forward
, atau prerender
. Hal ini memungkinkan Anda terus memantau performa dalam jenis navigasi ini, meskipun keseluruhan distribusinya condong ke negatif. Kami merekomendasikan pendekatan ini untuk metrik pemuatan halaman yang tidak berfokus pada pengguna seperti Time to First Byte (TTFB).
Untuk metrik yang berfokus pada pengguna seperti Data Web Inti, opsi yang lebih baik adalah melaporkan nilai yang mewakili pengalaman pengguna secara lebih akurat.
Dampak pada Core Web Vitals
Core Web Vitals mengukur pengalaman pengguna di halaman web di berbagai dimensi (kecepatan pemuatan, interaktivitas, stabilitas visual), dan karena pengguna mengalami pemulihan bfcache saat navigasi lebih cepat daripada pemuatan halaman penuh, metrik Core Web Vitals harus mencerminkan hal ini. Lagi pula, pengguna tidak peduli apakah bfcache diaktifkan atau tidak, mereka hanya peduli bahwa navigasinya cepat.
Alat yang mengumpulkan dan melaporkan metrik Core Web Vitals, seperti Laporan Pengalaman Pengguna Chrome, memperlakukan pemulihan bfcache sebagai kunjungan halaman terpisah dalam set data mereka. Dan meskipun tidak ada API performa web khusus untuk mengukur metrik ini setelah bfcache dipulihkan, Anda dapat memperkirakan nilainya menggunakan API web yang ada:
- Untuk Largest Contentful Paint (LCP), gunakan delta di antara stempel waktu peristiwa
pageshow
dan stempel waktu dari frame yang digambar berikutnya, karena semua elemen dalam frame akan dilukis pada waktu yang sama. Dalam kasus pemulihan bfcache, LCP dan FCP sama. - Untuk Interaction to Next Paint (INP), tetap gunakan Performance Observer yang ada, tetapi reset nilai INP saat ini ke 0.
- Untuk Pergeseran Tata Letak Kumulatif (CLS), tetap gunakan Performance Observer yang ada, tetapi reset nilai CLS saat ini ke 0.
Untuk mengetahui detail selengkapnya tentang pengaruh bfcache terhadap setiap metrik, lihat halaman panduan metrik Core Web Vitals masing-masing. Untuk mengetahui contoh spesifik cara menerapkan versi bfcache metrik ini, lihat PR yang menambahkannya ke library JS web-vitals.
Library JavaScript web-vitals mendukung pemulihan bfcache dalam metrik yang dilaporkannya.
Referensi Tambahan
- Pembuatan Cache Firefox (bfcache di Firefox)
- Cache Halaman (bfcache di Safari)
- Back/forward cache: perilaku terekspos web (perbedaan bfcache di seluruh browser)
- penguji bfcache (menguji pengaruh API dan peristiwa yang berbeda terhadap bfcache di browser)
- Pengubah Game Performa: Cache Back/Forward Browser (studi kasus dari Smashing Magazine yang menunjukkan peningkatan signifikan Core Web Vitals dengan mengaktifkan bfcache)