Optimalkan halaman Anda untuk pemuatan instan saat menggunakan tombol kembali dan maju di browser.
Back-forward cache (atau bfcache) adalah pengoptimalan browser yang memungkinkan navigasi mundur dan maju secara instan. Fitur ini meningkatkan pengalaman penjelajahan secara signifikan bagi pengguna, terutama mereka yang memiliki jaringan atau perangkat yang lebih lambat.
Sebagai developer web, sangat penting untuk memahami cara mengoptimalkan halaman Anda untuk bfcache di semua browser, sehingga pengguna dapat memperoleh manfaatnya.
Kompatibilitas browser
bfcache telah didukung di Firefox dan Safari selama bertahun-tahun, di desktop dan 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 ringkasan lengkap halaman (termasuk heap JavaScript) saat pengguna keluar. Dengan seluruh halaman dalam memori, browser dapat memulihkannya dengan cepat dan mudah jika pengguna memutuskan untuk kembali.
Berapa kali Anda mengunjungi situs dan mengklik link untuk membuka halaman lain, dan kemudian menyadari bahwa itu bukan yang Anda inginkan, lalu mengklik tombol kembali? Pada saat itu, bfcache dapat membuat perbedaan besar dalam kecepatan pemuatan halaman sebelumnya:
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, mengurai ulang, dan mengeksekusi ulang beberapa (atau semua) resource yang baru saja didownload. |
Dengan bfcache diaktifkan | Pemuatan halaman sebelumnya pada dasarnya bersifat instan, karena seluruh halaman dapat dipulihkan dari memori, tanpa harus masuk ke jaringan sama sekali |
Lihat video cara kerja bfcache ini untuk memahami kecepatan yang dapat dilakukannya ke navigasi:
Dalam video di atas, contoh dengan bfcache sedikit lebih cepat daripada contoh tanpa bfcache.
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 navigasi di perangkat seluler adalah maju atau mundur. Dengan mengaktifkan bfcache, browser dapat menghilangkan transfer data dan waktu yang dihabiskan untuk memuat miliaran halaman web setiap harinya.
Cara kerja "cache"
"Cache" yang digunakan oleh bfcache berbeda dengan cache HTTP (yang juga berguna dalam mempercepat navigasi berulang). bfcache adalah snapshot dari keseluruhan halaman dalam 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 dapat dipenuhi dari cache HTTP, kunjungan berulang menggunakan pemulihan bfcache selalu lebih cepat daripada navigasi non-bfcache yang paling dioptimalkan dengan baik.
Namun, membuat snapshot halaman di memori memerlukan beberapa kompleksitas terkait cara terbaik untuk mempertahankan kode yang sedang berlangsung. Misalnya, bagaimana cara menangani panggilan setTimeout()
saat waktu tunggu habis saat halaman berada di bfcache?
Jawabannya adalah browser akan menjeda timer yang tertunda atau promise yang belum terselesaikan—pada dasarnya semua tugas yang tertunda dalam antrean tugas JavaScript—dan melanjutkan tugas pemrosesan saat (atau jika) halaman dipulihkan dari bfcache.
Dalam beberapa kasus, hal ini berisiko rendah (misalnya, waktu tunggu habis atau promise), tetapi dalam kasus lain, hal ini dapat menyebabkan perilaku yang sangat membingungkan atau tidak terduga. Misalnya, jika browser menjeda tugas yang diperlukan sebagai bagian dari transaksi IndexedDB, hal tersebut dapat memengaruhi tab terbuka lainnya di asal yang sama (karena database IndexedDB yang sama dapat diakses oleh beberapa tab secara bersamaan). Akibatnya, browser umumnya tidak akan mencoba menyimpan halaman ke dalam cache di tengah transaksi IndexedDB atau menggunakan API yang mungkin memengaruhi halaman lain.
Untuk detail selengkapnya tentang pengaruh berbagai penggunaan API terhadap kelayakan bfcache halaman, lihat Mengoptimalkan halaman untuk bfcache di bawah.
bfcache dan Aplikasi Web Satu Halaman (SPA)
Bbfcache berfungsi dengan navigasi yang dikelola browser. Oleh karena itu, SPA tidak berfungsi dengan apa yang disebut "navigasi lunak" dalam SPA tetapi salah satu nilai jual utama SPA adalah jenis navigasi itu harus cepat. Namun, bfcache pasti dapat membantu saat kembali ke SPA daripada melakukan inisialisasi ulang penuh aplikasi tersebut dari awal.
API untuk mengamati bfcache
Meskipun bfcache adalah pengoptimalan yang dilakukan secara otomatis oleh browser, penting bagi developer untuk mengetahui kapan hal ini terjadi agar mereka dapat mengoptimalkan halaman mereka untuk hal itu dan menyesuaikan metrik atau pengukuran performa sebagaimana mestinya.
Peristiwa utama yang digunakan untuk mengamati bfcache adalah peristiwa transisi halaman—pageshow
dan pagehide
—yang telah ada selama bfcache memiliki dan didukung di hampir semua semua browser yang digunakan saat ini.
Peristiwa Siklus Proses Halaman yang lebih baru—freeze
dan resume
juga dikirim saat halaman masuk atau keluar dari bfcache, serta dalam beberapa situasi lainnya. Misalnya, saat tab latar belakang
berhenti berfungsi untuk meminimalkan penggunaan CPU. Perhatikan bahwa peristiwa Siklus Proses Halaman saat ini
hanya didukung di browser berbasis Chromium.
Mengamati saat halaman dipulihkan dari bfcache
Peristiwa pageshow
aktif tepat setelah peristiwa load
, yaitu saat halaman pertama kali dimuat dan setiap kali halaman dipulihkan dari bfcache. Peristiwa pageshow
memiliki properti persisted
yang akan menjadi true
jika halaman dipulihkan dari bfcache (dan false
jika tidak). Anda dapat menggunakan properti persisted
untuk membedakan pemuatan halaman reguler dengan 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
juga akan diaktifkan saat halaman dipulihkan dari bfcache (tepat sebelum peristiwa pageshow
), meskipun peristiwa ini juga akan aktif saat pengguna mengunjungi kembali tab latar belakang yang dibekukan.
Jika ingin memperbarui status halaman setelah dibekukan (yang mencakup halaman dalam bfcache), Anda dapat menggunakan peristiwa resume
, tetapi jika ingin mengukur rasio hit bfcache situs, Anda harus menggunakan peristiwa pageshow
. Dalam beberapa kasus, Anda mungkin
perlu menggunakan keduanya.
Mengamati saat halaman memasukkan bfcache
Peristiwa pagehide
adalah pasangan dari peristiwa pageshow
. Peristiwa pageshow
diaktifkan saat halaman dimuat secara normal atau dipulihkan dari bfcache.
Peristiwa pagehide
aktif saat halaman dihapus muatannya secara normal atau saat
browser mencoba memasukkannya ke dalam bfcache.
Peristiwa pagehide
juga memiliki properti persisted
, dan jika berupa false
,
Anda dapat yakin bahwa halaman tidak akan memasukkan bfcache. Namun, jika properti persisted
adalah true
, hal ini tidak menjamin halaman akan disimpan dalam cache.
Artinya, browser intends menyimpan halaman ke dalam cache, tetapi mungkin ada faktor
yang membuat halaman tidak dapat di-cache.
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
akan diaktifkan segera setelah peristiwa pagehide
(jika properti persisted
peristiwa adalah true
), tetapi sekali lagi, hal ini hanya berarti bahwa browser intends menyimpan halaman dalam cache. Anda mungkin masih harus menghapusnya karena beberapa alasan yang dijelaskan di bawah.
Mengoptimalkan halaman untuk bfcache
Tidak semua halaman disimpan dalam bfcache, dan meskipun disimpan di sana, halaman tidak akan terus ada di sana. Sangat penting bagi developer untuk memahami apa yang membuat halaman memenuhi syarat (dan tidak memenuhi syarat) untuk bfcache guna memaksimalkan rasio cache-hit mereka.
Bagian berikut menguraikan praktik terbaik untuk memungkinkan browser dapat menyimpan halaman Anda dalam cache.
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 untuk browser karena terjadi sebelum bfcache dan banyak halaman di internet beroperasi dengan asumsi (wajar) bahwa halaman tidak akan terus 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 menavigasi keluar, yang tidak
lagi benar (dan belum berlaku sejak lama).
Jadi, browser dihadapkan pada dilema, sehingga mereka harus memilih di antara hal yang dapat meningkatkan pengalaman pengguna—tetapi mungkin 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 dengan pemroses peristiwa unload
ke dalam cache, tetapi untuk mengurangi potensi kerusakan, Safari tidak akan menjalankan peristiwa unload
saat pengguna keluar, sehingga membuat peristiwa ini 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 fakta bahwa 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.
Daripada menggunakan peristiwa unload
, gunakan peristiwa pagehide
. Peristiwa pagehide
aktif dalam semua kasus ketika peristiwa unload
saat ini diaktifkan, dan juga aktif 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) menambahkan pemroses peristiwa unload
.
Karena ketidakandalannya, dan dampak performa untuk bfcache, Chrome ingin menghentikan peristiwa unload
.
Menggunakan Kebijakan Izin untuk mencegah pengendali penghapusan muatan digunakan di halaman
Situs yang tidak menggunakan pengendali peristiwa unload
dapat memastikan peristiwa tersebut tidak ditambahkan menggunakan Kebijakan Izin dari Chrome 115.
Permission-Policy: unload()
Hal ini 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 hal ini terjadi dan masih tidak dapat diandalkan, jadi hindari menggunakannya kecuali jika benar-benar diperlukan.
Namun, tidak seperti peristiwa unload
, ada penggunaan yang sah untuk beforeunload
. Misalnya, saat Anda ingin memperingatkan pengguna bahwa perubahan
yang belum disimpan akan hilang jika mereka meninggalkan halaman. Dalam hal ini, sebaiknya Anda hanya menambahkan pemroses beforeunload
saat pengguna memiliki perubahan yang belum disimpan, lalu menghapusnya segera setelah perubahan yang belum disimpan disimpan.
window.addEventListener('beforeunload', (event) => { if (pageHasUnsavedChanges()) { event.preventDefault(); return event.returnValue = 'Are you sure you want to exit?'; } });
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); });
Minimalkan penggunaan Cache-Control: no-store
Cache-Control: no-store
adalah server web header HTTP yang dapat ditetapkan pada respons yang menginstruksikan browser untuk tidak menyimpan respons dalam cache HTTP apa pun. Atribut ini harus digunakan untuk resource yang berisi informasi pengguna sensitif, misalnya halaman di balik login.
Meskipun bfcache bukan cache HTTP, secara historis, saat Cache-Control: no-store
ditetapkan pada resource halaman itu sendiri (bukan di subresource apa pun), browser telah memilih untuk tidak menyimpan halaman dalam bfcache. Ada upaya yang sedang dilakukan guna mengubah perilaku ini untuk Chrome dengan cara yang menjaga privasi, namun saat ini halaman apa pun yang menggunakan Cache-Control: no-store
tidak akan memenuhi syarat untuk bfcache.
Karena Cache-Control: no-store
membatasi kelayakan halaman untuk bfcache, cache hanya boleh ditetapkan di halaman yang berisi informasi sensitif yang tidak sesuai untuk menyimpan dalam jenis cache apa pun.
Untuk halaman yang ingin selalu menayangkan konten terbaru—dan konten tersebut tidak berisi informasi sensitif—gunakan Cache-Control: no-cache
atau Cache-Control: max-age=0
. Perintah ini memerintahkan browser untuk memvalidasi ulang konten sebelum menayangkannya, dan tidak memengaruhi kelayakan bfcache halaman.
Perhatikan bahwa saat halaman dipulihkan dari bfcache, halaman akan dipulihkan dari memori, bukan dari cache HTTP. Oleh karena itu, perintah seperti Cache-Control: no-cache
atau Cache-Control: max-age=0
tidak dipertimbangkan, dan tidak ada validasi ulang yang terjadi sebelum konten ditampilkan kepada pengguna.
Namun, pengalaman pengguna ini kemungkinan masih lebih baik, karena pemulihan bfcache dilakukan secara instan dan—karena halaman tidak berada dalam bfcache untuk waktu yang lama—konten tidak mungkin usang. Namun, jika konten berubah dari menit ke menit, Anda dapat mengambil update menggunakan peristiwa pageshow
, seperti yang diuraikan di bagian berikutnya.
Memperbarui data yang tidak berlaku 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 yang sudah tidak berlaku 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 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
}
});
Meskipun idealnya Anda akan memperbarui konten di tempat, untuk beberapa perubahan, Anda dapat memaksa pemuatan ulang penuh. Kode berikut memeriksa keberadaan cookie khusus situs di peristiwa pageshow
dan akan dimuat 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();
}
});
Muat ulang memiliki keuntungan yaitu masih akan mempertahankan histori (untuk memungkinkan navigasi maju), tetapi 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 performa, dipertanyakan apakah perilaku tersebut menghasilkan engagement iklan yang lebih baik atau tidak. Pengguna mungkin melihat iklan yang ingin mereka klik lagi, tetapi dengan memuat ulang, bukan memulihkannya dari bfcache yang tidak dapat mereka lakukan. Menguji skenario ini—idealnya dengan pengujian A/B—penting sebelum membuat asumsi.
Untuk situs yang ingin memperbarui iklan saat memulihkan bfcache, lalu memuat ulang iklan saja di peristiwa pageshow
jika event.persisted
adalah true
memungkinkan hal ini terjadi tanpa memengaruhi performa halaman. Hubungi penyedia iklan Anda, tetapi berikut 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 dari halaman yang dibuka.
Selain menjadi risiko
keamanan, halaman dengan referensi
window.opener
non-null tidak dapat dimasukkan dengan aman ke bfcache karena hal tersebut dapat merusak
halaman apa pun yang mencoba mengaksesnya.
Oleh karena itu, sebaiknya hindari membuat referensi window.opener
. Anda dapat melakukannya menggunakan rel="noopener"
jika memungkinkan (perhatikan, sekarang ini adalah setelan default di semua browser modern). Jika situs Anda mengharuskan membuka jendela dan
mengontrolnya melalui
window.postMessage()
atau langsung mereferensikan objek jendela, baik jendela yang terbuka maupun
pembuka tidak akan memenuhi syarat untuk bfcache.
Selalu tutup koneksi yang terbuka sebelum pengguna menutupnya
Seperti yang disebutkan di atas, saat halaman dimasukkan ke dalam bfcache, semua tugas JavaScript yang dijadwalkan akan dijeda, lalu dilanjutkan saat halaman dikeluarkan dari cache.
Jika tugas JavaScript yang dijadwalkan ini hanya mengakses DOM API—atau API lain yang terisolasi hanya untuk halaman saat ini—menjeda tugas ini saat halaman tidak terlihat oleh pengguna tidak akan menyebabkan masalah.
Namun, jika tugas ini terhubung ke API yang juga dapat diakses dari halaman lain dengan asal yang sama (misalnya: IndexedDB, Web Locks, WebSockets, dll.), hal ini dapat menimbulkan masalah karena menjeda 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 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 selalu tutup koneksi dan hapus atau putuskan koneksi observer selama peristiwa pagehide
atau freeze
. Dengan begitu, browser dapat meng-cache halaman dengan aman tanpa risiko memengaruhi tab terbuka lainnya.
Kemudian, jika halaman dipulihkan dari bfcache, Anda dapat membuka atau menghubungkan kembali ke API tersebut (dalam peristiwa pageshow
atau resume
).
Contoh berikut menunjukkan cara memastikan halaman Anda memenuhi syarat untuk bfcache saat menggunakan IndexedDB 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 is leaving.
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 disimpan dalam cache
Chrome DevTools dapat membantu Anda menguji halaman guna memastikan halaman telah dioptimalkan untuk bfcache, dan mengidentifikasi masalah yang mungkin membuat halaman tidak memenuhi syarat.
Untuk menguji halaman tertentu, buka halaman tersebut di Chrome, lalu di DevTools, buka Application > Back-forward Cache. Selanjutnya, klik tombol Run Test dan DevTools akan mencoba keluar dan kembali untuk menentukan apakah halaman tersebut dapat dipulihkan dari bfcache.
Jika berhasil, panel akan melaporkan "Dipulihkan dari back-forward cache":
Jika tidak berhasil, panel akan menunjukkan bahwa halaman tidak dipulihkan dan mencantumkan alasannya.
Jika alasannya adalah sesuatu yang dapat diatasi oleh Anda sebagai developer, hal tersebut juga akan ditunjukkan:
Pada screenshot di atas, penggunaan pemroses peristiwa unload
mencegah halaman memenuhi syarat untuk bfcache. Anda dapat memperbaikinya dengan beralih dari unload
ke pagehide
:
window.addEventListener('unload', ...);
window.addEventListener('pagehide', ...);
Lighthouse 10.0 juga menambahkan audit bfcache, yang melakukan pengujian serupa dengan yang dilakukan DevTools, dan juga memberikan alasan mengapa halaman tidak memenuhi syarat jika audit gagal. Lihat dokumen audit bfcache untuk informasi selengkapnya.
Cara bfcache memengaruhi analisis dan pengukuran performa
Jika melacak kunjungan ke situs Anda menggunakan alat analisis, Anda mungkin akan melihat penurunan jumlah total kunjungan halaman yang dilaporkan karena Chrome terus mengaktifkan bfcache untuk lebih banyak pengguna.
Bahkan, kemungkinan Anda sudah kurang melaporkan kunjungan halaman dari browser lain yang menerapkan bfcache karena sebagian besar library analisis populer tidak melacak pemulihan bfcache sebagai kunjungan halaman baru.
Jika Anda tidak ingin jumlah kunjungan halaman berkurang karena Chrome mengaktifkan
bfcache, Anda dapat melaporkan pemulihan bfcache sebagai kunjungan halaman (direkomendasikan) dengan memproses
peristiwa pageshow
dan memeriksa properti persisted
.
Contoh berikut menunjukkan cara melakukannya dengan Google Analytics; logikanya harus serupa dengan alat analisis lainnya:
// 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');
}
});
Mengukur rasio hit bfcache Anda
Anda juga dapat melacak 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';
});
}
});
Dengan melihat rasio navigasi back_forward
terhadap back_forward_cache
, rasio bfcache dapat dihitung.
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
Dalam beberapa kasus ini, jenis navigasi asli mungkin dipertahankan oleh beberapa browser, sehingga dapat menampilkan jenis back_forward
meskipun ini bukan navigasi Mundur/Maju.
Bahkan tanpa pengecualian tersebut, bfcache akan dihapus setelah periode tertentu untuk menghemat memori.
Jadi, pemilik situs tidak mengharapkan rasio hit bfcache 100% untuk semua
navigasi back_forward
. Namun, mengukur rasionya dapat berguna untuk
mengidentifikasi halaman tempat halaman itu sendiri mencegah penggunaan bfcache untuk
proporsi navigasi mundur dan maju yang tinggi.
Tim Chrome sedang mengerjakan
NotRestoredReasons
API
untuk membantu mengungkap alasan tidak digunakannya bfcache untuk membantu developer
memahami alasan tidak digunakannya cache, dan apakah ini adalah hal yang dapat mereka
kerjakan untuk meningkatkan kualitas situs mereka.
Pengukuran performa
bfcache juga dapat berdampak 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 maju dan mundur, menurut definisi, adalah kunjungan berulang, dan pemuatan halaman berulang umumnya lebih cepat daripada pemuatan halaman dari pengunjung pertama kali (karena cache HTTP, seperti yang disebutkan sebelumnya).
Hasilnya adalah lebih sedikit pemuatan halaman yang cepat di set data Anda, yang kemungkinan akan mendistorsi distribusi lebih lambat—meskipun performa yang dialami pengguna mungkin telah meningkat.
Ada beberapa cara untuk mengatasi masalah ini. Salah satunya adalah menganotasi semua metrik pemuatan halaman dengan jenis navigasi masing-masing: navigate
, reload
, back_forward
, atau prerender
. Dengan demikian, Anda dapat
terus memantau performa dalam jenis navigasi tersebut—meskipun
distribusi keseluruhan cenderung negatif. Pendekatan ini direkomendasikan 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 lebih akurat dalam merepresentasikan pengalaman pengguna.
Dampak pada Data Web Inti
Data Web Inti mengukur pengalaman pengguna di halaman web di berbagai dimensi (kecepatan pemuatan, interaktivitas, stabilitas visual), dan karena pengguna mengalami pemulihan bfcache sebagai navigasi yang lebih cepat daripada pemuatan halaman tradisional, metrik Data Web Inti harus menunjukkan hal ini. Lagi pula, pengguna tidak peduli apakah bfcache diaktifkan atau tidak, mereka hanya peduli bahwa navigasinya cepat.
Alat seperti Laporan Pengalaman Pengguna Chrome, yang mengumpulkan dan melaporkan tentang metrik Data Web Inti memperlakukan pemulihan bfcache sebagai kunjungan halaman terpisah dalam set data mereka.
Meskipun belum ada API performa web khusus untuk mengukur metrik ini setelah pemulihan bfcache, nilainya dapat diperkirakan menggunakan API web yang ada.
- Untuk Largest Contentful Paint (LCP), Anda dapat menggunakan delta antara
stempel waktu peristiwa
pageshow
dan stempel waktu frame yang digambar berikutnya (karena semua elemen dalam frame akan digambar secara bersamaan). Perhatikan bahwa dalam kasus pemulihan bfcache, LCP dan FCP akan sama. - Untuk Penundaan Input Pertama (FID), Anda dapat menambahkan kembali pemroses peristiwa (yang sama dengan yang digunakan oleh FID polyfill) di peristiwa
pageshow
, dan melaporkan FID sebagai penundaan input pertama setelah pemulihan bfcache. - Untuk Pergeseran Tata Letak Kumulatif (CLS), Anda dapat terus menggunakan Performance Observer yang ada; yang harus Anda lakukan adalah mereset nilai CLS saat ini ke 0.
Untuk detail selengkapnya tentang pengaruh bfcache terhadap setiap metrik, lihat setiap halaman panduan metrik Data Web Inti. Untuk contoh spesifik cara menerapkan versi bfcache metrik ini dalam kode, lihat PR yang menambahkannya ke library JS vital web.
Referensi Tambahan
- Cache Firefox (bfcache di Firefox)
- Cache Halaman (bfcache di Safari)
- Back/forward cache: perilaku yang terekspos web (perbedaan bfcache di berbagai browser)
- penguji bfcache (uji pengaruh API dan peristiwa yang berbeda terhadap bfcache di browser)
- Performance Game Changer: Back/Forward Cache Browser (studi kasus dari Smashing Magazine yang menunjukkan peningkatan Core Web Vitals yang dramatis dengan mengaktifkan bfcache)