Back dan forward cache

Philip Walton
Barry Pollard

Back-forward cache (atau bfcache) adalah pengoptimalan browser yang memungkinkan navigasi mundur dan maju secara instan. Fitur ini meningkatkan pengalaman penjelajahan secara signifikan, terutama untuk pengguna dengan jaringan atau perangkat yang lebih lambat.

Halaman ini menjelaskan cara mengoptimalkan halaman Anda untuk bfcache di semua browser.

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 saat pengguna menutupnya. Dengan seluruh halaman dalam memori, browser dapat memulihkannya dengan cepat jika pengguna memutuskan untuk kembali, daripada perlu mengulangi semua permintaan jaringan yang diperlukan untuk memuat halaman.

Video berikut menunjukkan seberapa banyak bfcache dapat mempercepat navigasi:

Penggunaan bfcache akan membuat halaman dimuat jauh lebih cepat selama navigasi mundur dan maju.

Data penggunaan Chrome menunjukkan bahwa 1 dari 10 navigasi di desktop dan 1 dari 5 navigasi di perangkat seluler adalah maju atau mundur. Oleh karena itu, bfcache berpotensi menghemat banyak waktu dan penggunaan data.

Cara kerja "cache"

"Cache" yang digunakan oleh bfcache berbeda dengan cache HTTP, yang berperan sendiri dalam mempercepat navigasi berulang. bfcache adalah snapshot dari keseluruhan halaman di memori, termasuk heap JavaScript, sedangkan cache HTTP hanya berisi respons atas permintaan yang dibuat sebelumnya. Karena sangat jarang semua permintaan yang diperlukan untuk memuat halaman agar dapat dipenuhi dari cache HTTP, kunjungan berulang menggunakan pemulihan bfcache selalu lebih cepat daripada navigasi non-bfcache yang dioptimalkan terbaik sekalipun.

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 setiap timer yang tertunda atau promise yang belum terselesaikan untuk halaman dalam bfcache, termasuk hampir semua tugas yang tertunda dalam antrean tugas JavaScript, dan melanjutkan tugas pemrosesan jika halaman dipulihkan dari bfcache.

Dalam beberapa kasus, seperti untuk waktu tunggu dan promise, risiko ini cukup rendah, tetapi dalam kasus lain, hal ini dapat menyebabkan perilaku yang membingungkan atau tidak terduga. Misalnya, jika browser menjeda tugas yang diperlukan untuk 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 biasanya tidak akan mencoba menyimpan halaman ke dalam cache di tengah transaksi IndexedDB atau saat menggunakan API yang mungkin memengaruhi halaman lain.

Untuk detail selengkapnya tentang pengaruh penggunaan API terhadap kelayakan bfcache halaman, lihat Mengoptimalkan halaman untuk bfcache.

bfcache dan Aplikasi Web Satu Halaman (SPA)

Karena berfungsi dengan navigasi yang dikelola browser, bfcache tidak berfungsi untuk "navigasi ringan" dalam aplikasi satu halaman (SPA). Namun, {i>bfcache<i} masih dapat membantu saat meninggalkan dan kembali ke SPA.

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 halamannya dan menyesuaikan metrik atau pengukuran performa sesuai dengan itu.

Peristiwa utama yang digunakan untuk mengamati bfcache adalah peristiwa transisi halaman pageshow dan pagehide, yang didukung oleh sebagian besar browser.

Peristiwa Siklus Proses Halaman yang lebih baru, freeze dan resume, juga dikirim saat halaman masuk atau keluar dari bfcache, serta dalam beberapa situasi lain, misalnya, saat tab latar belakang berhenti merespons untuk meminimalkan penggunaan CPU. Peristiwa 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, yaitu true jika halaman dipulihkan dari bfcache dan false jika tidak. 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 Cara bfcache memengaruhi analisis dan pengukuran performa.

Mengamati saat halaman memasukkan bfcache

Peristiwa pagehide aktif saat halaman dihapus muatannya atau saat browser mencoba memasukkannya ke dalam bfcache.

Peristiwa pagehide juga memiliki properti persisted. Jika statusnya false, Anda dapat yakin bahwa halaman tersebut tidak akan memasukkan bfcache. Namun, persisted menjadi true tidak menjamin halaman akan disimpan dalam cache. Artinya, browser intends menyimpan halaman ke dalam cache, tetapi mungkin ada faktor lain yang membuat halaman tidak dapat disimpan dalam 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 aktif tepat setelah peristiwa pagehide jika persisted adalah true, tetapi itu hanya berarti browser intends menyimpan halaman dalam cache. Anda mungkin masih harus membuangnya karena beberapa alasan yang akan dijelaskan nanti.

Mengoptimalkan halaman untuk bfcache

Tidak semua halaman disimpan dalam bfcache, dan meskipun disimpan di sana, halaman tidak akan terus ada di sana. Halaman berikut menjelaskan apa saja yang menjadikan halaman memenuhi syarat untuk bfcache, dan merekomendasikan praktik terbaik untuk memaksimalkan kemampuan browser dalam meng-cache halaman guna mendapatkan rasio cache yang lebih baik.

Gunakan pagehide, bukan unload

Cara terpenting untuk mengoptimalkan bfcache di semua browser adalah dengan tidak pernah menggunakan pemroses peristiwa unload. Sebagai gantinya, proses pagehide karena diaktifkan saat halaman memasuki bfcache dan setiap kali unload diaktifkan.

unload adalah fitur lama, yang awalnya dirancang untuk memicu setiap kali pengguna keluar dari halaman. Hal ini tidak lagi berlaku, tetapi banyak halaman web masih beroperasi dengan asumsi bahwa browser menggunakan unload dengan cara ini, dan setelah unload terpicu, halaman yang dihapus muatannya akan berhenti ada. Hal ini berpotensi merusak bfcache jika browser mencoba meng-cache halaman yang tidak dimuat.

Di desktop, Chrome dan Firefox membuat halaman dengan pemroses unload tidak memenuhi syarat untuk bfcache, yang mengurangi risiko, tetapi juga menyebabkan banyak halaman tidak di-cache dan oleh karena itu dimuat ulang jauh lebih lambat. Safari mencoba meng-cache beberapa halaman dengan pemroses peristiwa unload, tetapi untuk mengurangi potensi kerusakan, Safari tidak menjalankan peristiwa unload saat pengguna menutupnya, sehingga membuat pemroses unload tidak dapat diandalkan.

Di perangkat seluler, Chrome dan Safari mencoba meng-cache halaman dengan pemroses peristiwa unload, karena ketidakandalan unload di perangkat seluler membuat risiko kerusakan lebih rendah. Firefox Seluler 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.

Untuk menentukan apakah ada JavaScript di halaman Anda yang menggunakan unload, sebaiknya gunakan audit no-unload-listeners di Lighthouse.

Untuk mengetahui informasi tentang rencana Chrome untuk menghentikan penggunaan unload, lihat Penghentian peristiwa penghapusan muatan.

Menggunakan Kebijakan Izin untuk mencegah pengendali penghapusan muatan digunakan di halaman

Beberapa skrip dan ekstensi pihak ketiga dapat menambahkan pengendali penghapusan muatan ke halaman, sehingga memperlambat situs sehingga tidak memenuhi syarat untuk bfcache. Untuk mencegah hal ini di Chrome 115 dan yang lebih baru, gunakan Kebijakan Izin.

Permission-Policy: unload()

Hanya tambahkan pemroses beforeunload secara bersyarat

Peristiwa beforeunload tidak membuat halaman Anda tidak memenuhi syarat untuk bfcache. Namun, tindakan ini tidak dapat diandalkan, jadi sebaiknya hanya gunakan saat benar-benar diperlukan.

Contoh kasus penggunaan untuk beforeunload adalah memperingatkan pengguna bahwa mereka memiliki perubahan yang belum disimpan yang akan hilang jika mereka keluar dari halaman. Dalam hal ini, sebaiknya tambahkan pemroses beforeunload hanya ketika pengguna memiliki perubahan yang belum disimpan, lalu hapus segera setelah perubahan yang tidak disimpan disimpan, seperti dalam kode berikut:

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. ID ini digunakan untuk resource yang berisi informasi pengguna sensitif, seperti halaman di balik login.

Meskipun bfcache bukan cache HTTP, browser secara historis telah mengecualikan halaman dari bfcache saat Cache-Control: no-store ditetapkan di resource halaman (tetapi tidak pada subresource mana pun). Chrome sedang berupaya mengubah perilaku ini sekaligus menjaga privasi pengguna, tetapi secara default, halaman yang menggunakan Cache-Control: no-store tidak memenuhi syarat untuk bfcache.

Untuk mengoptimalkan bfcache, gunakan Cache-Control: no-store hanya pada halaman yang berisi informasi sensitif yang tidak boleh di-cache.

Untuk halaman yang ingin selalu menayangkan konten terbaru, tetapi tidak menyertakan informasi sensitif, gunakan Cache-Control: no-cache atau Cache-Control: max-age=0. Parameter ini akan memberi tahu browser untuk memvalidasi ulang konten sebelum menayangkannya, dan tidak memengaruhi kelayakan bfcache halaman karena pemulihan halaman dari bfcache tidak melibatkan cache HTTP.

Jika konten Anda berubah dari menit ke menit, ambil update menggunakan peristiwa pageshow agar halaman Anda tetap terbaru seperti yang dijelaskan di bagian berikutnya.

Memperbarui data yang tidak berlaku atau sensitif setelah pemulihan bfcache

Jika situs Anda menyimpan data status pengguna, dan terutama jika data tersebut berisi informasi pengguna yang sensitif, data tersebut harus diperbarui atau dihapus setelah halaman dipulihkan dari bfcache.

Misalnya, jika pengguna logout dari situs di komputer publik dan pengguna berikutnya mengklik tombol kembali, data lama dari bfcache mungkin mencakup data pribadi yang diperkirakan akan dihapus oleh pengguna pertama saat logout.

Untuk menghindari situasi seperti ini, 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
  }
});

Untuk beberapa perubahan, Anda mungkin ingin memaksa pemuatan ulang penuh, sehingga mempertahankan histori navigasi untuk navigasi maju. 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();
  }
});

Pemulihan iklan dan bfcache

Anda mungkin ingin mencoba menghindari penggunaan bfcache agar halaman Anda dapat menayangkan kumpulan iklan baru pada setiap navigasi mundur atau maju. Namun, hal ini buruk bagi performa situs, dan tidak meningkatkan engagement iklan secara konsisten. Misalnya, pengguna mungkin ingin kembali ke halaman untuk mengklik iklan, tetapi jika halaman dimuat ulang, bukan dipulihkan dari bfcache, iklan mungkin akan ditampilkan. Sebaiknya gunakan pengujian A/B untuk menentukan strategi terbaik bagi halaman Anda.

Untuk situs yang ingin memperbarui iklan saat pemulihan bfcache, Anda hanya dapat memperbarui iklan pada peristiwa pageshow jika event.persisted adalah true tanpa memengaruhi performa halaman, seperti dalam contoh Tag Google Publishing ini. Untuk mengetahui informasi selengkapnya tentang praktik terbaik untuk situs Anda, hubungi penyedia iklan Anda.

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 dapat merusak halaman yang mencoba mengaksesnya.

Untuk menghindari risiko ini, gunakan rel="noopener" untuk mencegah pembuatan referensi window.opener. Ini adalah perilaku default di semua browser modern. Jika situs Anda perlu membuka jendela dan mengontrolnya menggunakan window.postMessage() atau dengan langsung mereferensikan objek jendela, baik jendela yang terbuka maupun pembuka tidak memenuhi syarat untuk bfcache.

Tutup koneksi yang terbuka sebelum pengguna keluar

Seperti yang telah disebutkan sebelumnya, saat dimasukkan ke dalam bfcache, halaman akan menjeda semua tugas JavaScript yang dijadwalkan dan melanjutkannya saat halaman dikeluarkan dari cache.

Jika tugas JavaScript terjadwal ini hanya mengakses DOM API, atau API lain yang terisolasi ke halaman saat ini, menjeda tugas ini selagi halaman tidak terlihat oleh pengguna tidak menyebabkan masalah.

Namun, jika tugas ini terhubung ke API yang juga dapat diakses dari halaman lain dengan asal yang sama (misalnya: IndexedDB, Web Locks, dan WebSockets), menjeda tugas tersebut dapat merusak halaman tersebut dengan mencegah kode di halaman tersebut berjalan.

Akibatnya, beberapa browser tidak akan mencoba menempatkan halaman dalam bfcache jika memiliki salah satu dari hal berikut:

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 berisiko 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 disimpan dalam cache

Chrome DevTools dapat membantu Anda menguji halaman guna memastikan halaman dioptimalkan untuk bfcache, dan mengidentifikasi masalah yang mungkin membuat halaman tidak memenuhi syarat.

Untuk menguji halaman:

  1. Buka halaman di Chrome.
  2. Di DevTools, buka Application > Back-forward Cache.
  3. Klik tombol Run Test. DevTools kemudian mencoba menutup dan kembali untuk menentukan apakah halaman dapat dipulihkan dari bfcache.
Panel back-forward cache di DevTools
Panel Back-forward Cache di DevTools.

Jika pengujian berhasil, panel akan melaporkan "Dipulihkan dari back-forward cache". Jika tidak berhasil, panel akan menunjukkan alasannya. Untuk mengetahui daftar lengkap alasan, lihat Daftar alasan yang tidak dipulihkan untuk Chromium.

Jika alasannya adalah sesuatu yang dapat Anda tangani sebagai developer, panel akan menandainya sebagai Actionable.

DevTools melaporkan kegagalan untuk memulihkan halaman dari bfcache
Pengujian bfcache yang gagal dengan hasil yang dapat ditindaklanjuti.

Pada gambar ini, penggunaan pemroses peristiwa unload akan membuat halaman tidak memenuhi syarat untuk bfcache. Anda dapat memperbaikinya dengan beralih dari unload ke pagehide:

Anjuran
window.addEventListener('pagehide', ...);
Larangan
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 melacak kunjungan ke situs, Anda mungkin melihat penurunan jumlah total kunjungan halaman yang dilaporkan karena Chrome mengaktifkan bfcache untuk lebih banyak pengguna.

Bahkan, kemungkinan Anda sudah kurang melaporkan kunjungan halaman dari browser lain yang menerapkan bfcache, karena library analisis yang paling populer tidak melacak pemulihan bfcache sebagai kunjungan 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');
  }
});

Mengukur rasio hit bfcache Anda

Untuk mengidentifikasi halaman yang belum menggunakan bfcache, ukur jenis navigasi untuk pemuatan halaman sebagai berikut:

// 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 Anda menggunakan jumlah untuk navigasi back_forward dan navigasi back_forward_cache.

Alasan navigasi mundur atau maju tidak mungkin menggunakan bfcache mencakup perilaku pengguna berikut:

  • Menghentikan dan memulai ulang browser.
  • Menduplikasi tab.
  • Menutup dan memulihkan tab.

Dalam beberapa kasus ini, browser mungkin mempertahankan jenis navigasi asli dan menampilkan jenis back_forward meskipun ini bukan navigasi mundur atau maju. Meskipun jenis navigasi dilaporkan dengan benar, bfcache akan dihapus secara berkala untuk menghemat memori.

Karena hal ini, pemilik situs tidak dapat mengharapkan rasio hit bfcache 100% untuk semua navigasi back_forward. Namun, pengukuran rasionya dapat membantu mengidentifikasi halaman yang mencegah penggunaan bfcache.

Tim Chrome sedang mengerjakan NotRestoredReasons API untuk membantu mengungkap alasan halaman tidak menggunakan bfcache, sehingga developer dapat meningkatkan rasio hit bfcache 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 sudah ada, jumlah total pemuatan halaman yang dikumpulkan akan berkurang saat bfcache diaktifkan, bukan memulai pemuatan halaman baru. Namun, penggantian bfcache pemuatan halaman kemungkinan merupakan salah satu pemuatan halaman tercepat di set data Anda, karena pemuatan halaman yang berulang, termasuk navigasi mundur dan maju, dan biasanya lebih cepat daripada pemuatan halaman pertama kali karena adanya cache HTTP. Jadi, mengaktifkan bfcache dapat menyebabkan analisis Anda menampilkan pemuatan halaman yang lebih lambat, meskipun dapat meningkatkan performa situs bagi pengguna.

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. Hal ini memungkinkan Anda terus memantau performa dalam jenis navigasi tersebut, meskipun distribusi keseluruhan condong negatif. Kami merekomendasikan pendekatan ini untuk metrik pemuatan halaman yang tidak berpusat 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 mewakili apa yang dialami pengguna.

Dampak pada Data Web Inti

Data Web Inti mengukur pengalaman pengguna di halaman web di berbagai dimensi (kecepatan pemuatan, interaktivitas, stabilitas visual). Penting bahwa metrik Data Web Inti Anda mencerminkan fakta bahwa pengalaman pengguna dipulihkan oleh bfcache sebagai navigasi yang lebih cepat daripada pemuatan halaman default.

Alat yang mengumpulkan dan melaporkan metrik Data Web Inti, seperti Laporan Pengalaman Pengguna Chrome, menangani pemulihan bfcache sebagai kunjungan halaman terpisah dalam set data mereka. Selain itu, meskipun tidak ada API performa web khusus untuk mengukur metrik ini setelah pemulihan bfcache, Anda dapat memperkirakan nilainya menggunakan API web yang sudah ada:

  • Untuk Largest Contentful Paint (LCP), gunakan delta antara stempel waktu peristiwa pageshow dan stempel waktu frame yang digambar berikutnya, karena semua elemen dalam frame akan digambar pada saat yang sama. Dalam kasus pemulihan bfcache, LCP dan FCP adalah sama.
  • Untuk Interaction to Next Paint (INP), tetap gunakan Performance Observer yang ada, tetapi reset nilai CLS 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 detail selengkapnya tentang cara bfcache memengaruhi setiap metrik, lihat halaman panduan metrik Core Web Vitals. Untuk contoh spesifik cara menerapkan versi bfcache metrik ini, lihat PR yang menambahkannya ke library JS web-vitals.

Referensi Tambahan