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.
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 sebagai obselete adalah sebuah pengakuan bahwa kita sebagai developer web perlu memastikan paradigma kita sesuai dengan yang ada di dunia nyata dan tidak bergantung pada konsep usang yang tidak lagi berlaku—sebisa mungkin.
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 statushiddensebagai 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. Peristiwapagehidetidak diaktifkan saat halaman hanya diperkecil atau dialihkan ke tab lain. Perlu diperhatikan bahwa karenapagehidetidak 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 direalisasikan karena tidak akan aktif jika tab latar belakang dimatikan. 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.
Mercusuar
Lighthouse memiliki audit no-unload-listeners, yang memperingatkan developer jika ada JavaScript di halaman mereka (termasuk JavaScript dari library pihak ketiga) menambahkan pemroses peristiwa unload.
Chrome DevTools
Chrome DevTools menyertakan audit back-foward-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:
Reporting API
Reporting API dapat digunakan bersama dengan Kebijakan Izin hanya baca untuk mendeteksi penggunaan unload dari pengguna situs Anda.
Untuk detail selengkapnya, lihat usUsing 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:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
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
unloaduntuk 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 flag Chrome dan command line swtich:
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