Peristiwa unload
akan tidak digunakan lagi secara bertahap dengan mengubah default secara bertahap sehingga pengendali unload
berhenti diaktifkan di halaman, kecuali jika halaman secara eksplisit memilih untuk mengaktifkannya kembali.
Linimasa penghentian
Kami mendapati bahwa perilaku penghapusan muatan kemungkinan akan berubah pada awal Januari 2019, saat kami mengumumkan niat untuk menerapkan back/forward cache. Sejalan dengan pekerjaan implementasi, kami melakukan penjangkauan luas yang menghasilkan penurunan yang signifikan pada penggunaan penghapusan muatan. Untuk melengkapi penjangkauan ini, kami juga mulai menawarkan cara untuk menguji efek dari penghentian penggunaan penghapusan muatan Chrome 115:
- Pengujian secara publik melalui Permission-Policy API untuk penghapusan muatan di Chrome 115 (Juli 2023)
- Pengujian lokal dengan mengaktifkan tanda di Chrome 117 (September 2023)
Setelah melalui fase penjangkauan dan uji coba ini, berikut perkiraan kami untuk penghentian penggunaan sementara:
- Fase cakupan saat penghapusan muatan akan berhenti berfungsi secara bertahap untuk 50 situs populer teratas (referensi sejak halaman ini ditulis).
- Dimulai dengan 1% pengguna dari Chrome 120 (akhir November 2023).
- Berakhir dengan 100% pengguna pada akhir Kuartal 3 2024
- Selain itu, mulai Kuartal 3 2024, kami bermaksud untuk memulai fase umum di mana penghapusan muatan secara bertahap akan berhenti berfungsi di situs mana pun, dimulai dengan 1% pengguna dan berakhir dengan 100% pengguna pada akhir Kuartal 1 2025.
Perlu diperhatikan bahwa kami juga menawarkan menu opsi untuk tidak ikut jika jadwal penghentian sementara ini tidak memberikan waktu yang cukup untuk melakukan migrasi dari penghapusan muatan. Tujuan kami adalah menggunakan penghentian sementara ini untuk menginformasikan linimasa untuk fase terakhir (penghentian penghapusan muatan secara permanen). Ketidakikutsertaan ini akan dihapus atau dikurangi.
![Linimasa penghentian penghapusan muatan.](https://developer.chrome.com/static/docs/web-platform/deprecating-unload/image/unload-deprecation-timeline.png?authuser=6&hl=id)
Latar belakang
unload
dirancang untuk diaktifkan saat dokumen dihapus muatannya. Secara teori, ini dapat digunakan untuk menjalankan kode setiap kali pengguna keluar dari halaman, atau sebagai callback sesi.
Skenario saat peristiwa ini paling sering digunakan mencakup:
- Menyimpan data pengguna: Simpan data sebelum menutup halaman.
- Melakukan tugas pembersihan: Menutup resource yang terbuka sebelum meninggalkan halaman.
- Mengirim analisis: Mengirim data yang terkait dengan interaksi pengguna di akhir sesi.
Namun, peristiwa unload
sangat tidak dapat diandalkan.
Di Chrome dan Firefox desktop, unload
cukup andal, tetapi memiliki dampak negatif pada performa situs dengan mencegah penggunaan bfcache (back/forward cache).
Di browser seluler, unload
sering kali tidak berjalan karena tab sering kali ditempatkan di latar belakang, lalu dihentikan. Oleh karena itu, browser memilih untuk memprioritaskan bfcache di perangkat seluler daripada unload
, sehingga membuatnya semakin tidak dapat diandalkan. Safari juga menggunakan perilaku ini di desktop.
Tim Chrome percaya penggunaan model seluler yang memprioritaskan bfcache lebih dari unload
di desktop akan mengganggu dan membuatnya lebih tidak dapat diandalkan di sana, padahal sebelumnya sudah cukup andal di Chrome (dan Firefox). Sebaliknya, tujuan Chrome adalah menghapus peristiwa unload
sepenuhnya. Hingga saat itu, API tersebut akan tetap dapat diandalkan di desktop bagi pengguna yang secara eksplisit memilih tidak ikut serta dalam penghentian layanan.
Mengapa peristiwa unload
tidak digunakan lagi?
Menghentikan penggunaan unload
adalah langkah penting dalam pengenalan yang jauh lebih besar terhadap web tempat kita berada sekarang. Peristiwa unload
memberikan kesan palsu tentang kontrol siklus proses aplikasi yang semakin tidak benar tentang cara kita menjelajahi web dalam dunia komputasi modern.
Sistem operasi seluler sering kali membekukan atau menghapus muatan halaman web untuk menghemat memori, dan browser desktop juga sekarang melakukan hal ini karena alasan yang sama. Bahkan tanpa intervensi sistem operasi, pengguna sendiri sering kali beralih tab dan menghentikan tab lama tanpa secara formal "meninggalkan halaman".
Menghapus peristiwa unload
karena tidak berlaku lagi merupakan suatu pengakuan bahwa kami sebagai developer web perlu memastikan paradigma kami cocok dengan yang ada di dunia nyata dan tidak bergantung pada konsep usang yang tidak lagi berlaku—seandainya mereka pernah melakukannya.
Alternatif untuk peristiwa unload
Daripada menggunakan unload
, sebaiknya gunakan:
visibilitychange
: Untuk menentukan kapan visibilitas halaman berubah. Peristiwa ini terjadi saat pengguna beralih tab, meminimalkan jendela browser, atau membuka halaman baru. Pertimbangkan statushidden
sebagai waktu terakhir yang dapat diandalkan untuk menyimpan data aplikasi dan pengguna.pagehide
: Untuk menentukan kapan pengguna keluar dari halaman. Peristiwa ini terjadi saat pengguna keluar dari halaman, memuat ulang halaman, atau menutup jendela browser. Peristiwapagehide
tidak diaktifkan saat halaman hanya diperkecil atau dialihkan ke tab lain. Perlu diperhatikan bahwa karenapagehide
tidak membuat halaman tidak memenuhi syarat untuk back-forward cache, halaman mungkin dapat dipulihkan setelah peristiwa ini diaktifkan. Jika Anda membersihkan resource apa pun pada situasi ini, resource tersebut mungkin harus dipulihkan saat halaman dipulihkan.
Peristiwa beforeunload
memiliki kasus penggunaan yang sedikit berbeda dengan unload
karena merupakan peristiwa yang dapat dibatalkan. Atribut ini sering digunakan untuk memperingatkan pengguna tentang perubahan yang belum disimpan saat pengguna menutup halaman. Peristiwa ini juga tidak dapat diandalkan karena tidak akan aktif jika tab latar belakang dihentikan. Sebaiknya batasi penggunaan beforeunload
dan hanya tambahkan secara bersyarat. Sebagai gantinya, gunakan peristiwa di atas untuk sebagian besar penggantian unload
.
Untuk mengetahui detail selengkapnya, lihat saran ini tentang tidak pernah menggunakan pengendali unload
.
Mendeteksi penggunaan unload
Ada berbagai alat untuk membantu Anda menemukan tampilan peristiwa unload
di halaman. Hal ini memungkinkan situs mengetahui apakah mereka menggunakan peristiwa ini—baik dalam kodenya sendiri atau melalui library—sehingga mungkin akan terpengaruh oleh penghentian mendatang.
Chrome DevTools
Chrome DevTools menyertakan audit back-forward-cache
untuk membantu Anda mengidentifikasi masalah yang dapat membuat halaman tidak memenuhi syarat untuk back-forward cache, termasuk penggunaan pengendali unload
.
Untuk menguji back-forward cache, ikuti langkah-langkah berikut:
Di halaman Anda, buka DevTools, lalu buka Application > Background services > Back/forward cache.
Klik Uji back-forward cache Chrome secara otomatis mengarahkan Anda ke
chrome://terms/
dan kembali ke halaman Anda. Atau, Anda dapat mengklik tombol kembali dan maju di browser.
Jika halaman Anda tidak memenuhi syarat untuk back-forward cache, tab Back/forward cache akan menampilkan daftar masalah. Di bagian Actionable, Anda dapat melihat apakah Anda menggunakan unload
:
![Alat pengujian Back-forward cache Chrome DevTools yang menunjukkan pengendali penghapus muatan digunakan](https://developer.chrome.com/static/docs/web-platform/deprecating-unload/image/chrome-devtools-forward-8640f1ef515a1.png?authuser=6&hl=id)
Reporting API
Reporting API dapat digunakan bersama dengan Kebijakan Izin hanya baca untuk mendeteksi penggunaan unload
dari pengguna situs Anda.
Untuk mengetahui detail selengkapnya, lihat Menggunakan Reporting API untuk menemukan penghapusan muatan
Bfcache notRestoredReasons
API
Properti notRestoredReasons
—yang ditambahkan ke class PerformanceNavigationTiming
—melaporkan informasi tentang apakah dokumen diblokir agar tidak menggunakan bfcache di navigasi, dan alasannya. Petunjuk penggunaan dapat ditemukan di sini. Ini adalah contoh tampilan peringatan objek respons dari pemroses unload
yang ada:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
Mengontrol akses ke unload
Chrome akan menghentikan penggunaan peristiwa unload
secara bertahap. Sementara itu, Anda dapat menggunakan berbagai alat untuk mengontrol perilaku ini dan mempersiapkan penghentian mendatang. Perhatikan bahwa Anda tidak boleh mengandalkan teknik ini dalam jangka panjang, dan Anda harus merencanakan untuk bermigrasi ke alternatif sesegera mungkin.
Opsi berikut memungkinkan Anda mengaktifkan atau menonaktifkan pengendali unload
untuk menguji cara kerja situs tanpa pengendali tersebut, sehingga Anda dapat mempersiapkan penghentian yang akan datang. Ada berbagai jenis kebijakan:
- Kebijakan Izin: Ini adalah API platform bagi pemilik situs untuk mengontrol akses ke fitur, di tingkat situs atau halaman individual, melalui penggunaan header HTTP.
- Kebijakan perusahaan: Alat bagi admin IT guna mengonfigurasi Chrome untuk organisasi atau bisnis mereka. Admin tersebut dapat dikonfigurasi melalui panel admin, seperti Konsol Google Admin.
- Flag Chrome: Hal ini memungkinkan masing-masing developer mengubah setelan penghentian penggunaan
unload
untuk menguji dampak di berbagai situs.
Kebijakan Izin
Kebijakan Izin telah ditambahkan dari Chrome 115 untuk memungkinkan situs memilih tidak menggunakan pengendali unload
dan langsung mendapatkan manfaat dari bfcache untuk meningkatkan performa situs. Lihat contoh cara menetapkannya untuk situs Anda. Hal ini memungkinkan situs mengantisipasi penghentian unload
.
Pembatasan ini akan diperluas di Chrome 117 untuk memungkinkan situs melakukan hal sebaliknya, dan memilih untuk terus mencoba mengaktifkan pengendali unload
, karena Chrome mengubah setelan default agar setelan ini tidak diaktifkan di masa mendatang. Lihat contoh berikut tentang cara tetap mengizinkan pengendali penghapusan muatan diaktifkan untuk situs Anda. Keikutsertaan ini tidak akan berlaku selamanya dan harus digunakan untuk memberikan waktu bagi situs untuk bermigrasi dari pengendali unload
.
Kebijakan perusahaan
Perusahaan yang memiliki software yang bergantung pada peristiwa unload
agar dapat berfungsi dengan benar dapat menggunakan kebijakan ForcePermissionPolicyUnloadDefaultEnabled
untuk mencegah penghentian bertahap penggunaan perangkat yang mereka kendalikan. Dengan mengaktifkan kebijakan ini, unload
akan terus disetel secara default ke aktif untuk semua origin. Halaman mungkin masih menetapkan kebijakan yang lebih ketat jika diinginkan. Seperti pilihan tidak ikut Kebijakan Izin, alat ini adalah alat untuk mengurangi potensi perubahan yang dapat menyebabkan gangguan, tetapi tidak boleh digunakan terus-menerus.
Tombol command line dan tanda Chrome
Selain kebijakan perusahaan, Anda dapat menonaktifkan penghentian penggunaan untuk setiap pengguna melalui tanda Chrome dan tombol command line:
Menyetel chrome://flags/#deprecate-unload
ini ke enabled
akan meneruskan penghentian penggunaan default dan mencegah pengendali unload
diaktifkan. Izin tersebut masih dapat diganti di setiap situs melalui Kebijakan Izin, tetapi akan terus diaktifkan secara default.
Setelan ini juga dapat dikontrol oleh tombol command line.
Perbandingan opsi
Tabel berikut merangkum berbagai penggunaan opsi yang telah dibahas sebelumnya:
Lanjutkan penghentian | Memajukan penghentian (dengan pengecualian) | Mencegah penghentian penggunaan untuk mengamankan waktu migrasi | |
---|---|---|---|
Kebijakan Izin (berlaku untuk halaman/situs) |
Ya | Ya | Ya |
Kebijakan perusahaan (berlaku untuk perangkat) |
Tidak | Tidak | Ya |
Tanda Chrome (berlaku untuk masing-masing pengguna) |
Ya | Tidak | Tidak |
Tombol command line Chrome (berlaku untuk masing-masing pengguna) |
Ya | Tidak | Ya |
Kesimpulan
Pengendali unload
tidak digunakan lagi. Model ini tidak dapat diandalkan dalam waktu yang lama dan tidak dijamin akan aktif pada semua kasus di mana dokumen dihancurkan. Selain itu, pengendali unload
tidak kompatibel dengan bfcache.
Situs yang saat ini menggunakan pengendali unload
harus bersiap menghadapi penghentian mendatang ini dengan menguji pengendali unload
yang ada, menghapus atau memigrasikannya atau, sebagai upaya terakhir, menunda penghentian jika memerlukan waktu tambahan.
Ucapan terima kasih
Terima kasih kepada Kenji Baheux, Fergal Daly, Adriana Jara, dan Jeremy Wagner yang telah membantu meninjau artikel ini.
Banner besar oleh Anja Bauermann di Unsplash