我们将逐步更改默认设置,以逐步弃用 unload
事件,这样一来,除非网页明确选择重新启用 unload
处理脚本,否则网页将停止触发 unload
处理脚本。
弃用时间表
我们在 2019 年 1 月宣布打算实现返回/前进缓存时就指出,卸载行为可能会发生变化。在实施工作的同时,我们还开展了广泛的宣传活动,这使得卸载用量大幅下降。为了进一步扩大宣传范围,我们还开始提供一些方法来测试从 Chrome 115 弃用卸载功能的影响:
- 在 Chrome 115 中通过用于卸载的 Permission-Policy API进行公开测试(2023 年 7 月)
- 在 Chrome 117 中启用标志进行本地测试(2023 年 9 月)
在这些宣传和试用阶段之后,我们预计逐步弃用的具体实施方式如下:
- 此阶段是指,对于前 50 个热门网站(截至本文撰写时的数据),unload 功能将逐步停止运行。
- 从 Chrome 120 开始(2023 年 11 月底),将面向 1% 的用户推出。
- 到 2024 年第 3 季度末,面向所有用户结束投放
- 此外,从 2024 年第 3 季度开始,我们打算进入一个通用阶段,在此阶段中,unload 将逐步停止在任何网站上运行,从 1% 的用户开始,到 2025 年第 1 季度末,将覆盖 100% 的用户。
请注意,我们还提供了停用选项菜单,以防此软弃用时间表无法提供足够的时间来从卸载迁移。我们的目标是通过软弃用来告知最后一个阶段(硬性弃用卸载)的时间表,在该阶段,这些停用选项将被移除或减少。
背景
unload
旨在在文档卸载时触发。从理论上讲,它可以用于在用户离开页面时运行代码,或用作会话结束回调。
此事件最常见的使用场景包括:
- 保存用户数据:请先保存数据,然后再离开此页面。
- 执行清理任务:在放弃网页之前关闭打开的资源。
- 发送分析数据:发送与会话结束时的用户互动相关的数据。
不过,unload
事件极其不可靠。
在桌面版 Chrome 和 Firefox 中,unload
相当可靠,但它会阻止使用 bfcache(往返缓存),从而对网站性能产生负面影响。
在移动浏览器中,unload
通常不会运行,因为标签页经常会进入后台,然后被终止。因此,浏览器会选择在移动设备上优先使用 bfcache,而不是 unload
,这使得它们更加不可靠。Safari 在桌面设备上也采用了这种行为。
Chrome 团队认为,在桌面设备上采用移动设备模式(即优先使用 bfcache 而非 unload
)会破坏现有模式,因为这会导致 bfcache 在桌面设备上变得更加不可靠,而之前在 Chrome(和 Firefox)中,bfcache 的表现一直相当可靠。相反,Chrome 的目标是彻底移除 unload
事件。在此之前,对于明确选择停用此功能的用户,该功能仍可在桌面设备上正常使用。
为何弃用 unload
事件?
弃用 unload
是我们在更广泛的网络层面识别我们现在所面对的一个关键步骤。unload
事件会让人误以为可以控制应用生命周期,但这与我们在现代计算世界中浏览网页的方式越来越不符。
移动操作系统会频繁冻结或卸载网页以节省内存,桌面浏览器现在也越来越多地出于同样的原因这样做。即使没有操作系统干预,用户自己也经常切换标签页并终止旧标签页,而无需正式“离开网页”。
移除已废弃的 unload
事件,是为了表明我们 Web 开发者需要确保我们的范式与现实世界相符,而不是依赖于已过时且不再适用的概念(如果它们曾经适用的话)。
unload
事件的替代方案
建议改用以下方法,而不是 unload
:
visibilitychange
:用于确定网页的公开范围何时发生变化。当用户切换标签页、最小化浏览器窗口或打开新页面时,就会发生此事件。将hidden
状态视为保存应用和用户数据的最后可靠时间。pagehide
:用于确定用户何时离开页面。当用户离开页面、重新加载页面或关闭浏览器窗口时,会发生此事件。直接将网页最小化或切换到另一标签页时,系统不会触发pagehide
事件。请注意,由于pagehide
不会使网页不符合往返缓存的要求,因此系统有可能在此事件触发后恢复网页。如果您要清理此事件中的任何资源,则可能需要在页面恢复时恢复这些资源。
beforeunload
事件的用例与 unload
略有不同,因为它是一个可取消的事件。它通常用于在用户离开时提醒用户未保存的更改。此事件也不可靠,因为如果后台标签页被终止,它将不会触发。建议限制使用 beforeunload
,仅在有条件时添加。而是应针对大多数 unload
替换使用上述事件。
如需了解详情,请参阅有关绝不使用 unload
处理程序的建议。
检测 unload
的使用情况
您可以使用不同的工具来查找网页上 unload
事件的出现情况。这样,网站就可以发现自己是否在自己的代码中或通过库使用此事件,以及是否可能会受到即将弃用的事件的影响。
Chrome DevTools
Chrome 开发者工具包含一项 back-forward-cache
审核功能,可帮助您发现可能导致网页无法储存至往返缓存的问题,包括对 unload
处理程序的使用。
如需测试往返缓存,请按以下步骤操作:
在网页上,打开开发者工具,然后依次前往应用 > 后台服务 > 前进/后退缓存。
点击测试前进/后退缓存,Chrome 会自动将您定向到
chrome://terms/
,然后返回到您的网页。或者,您也可以点击浏览器的“后退”和“前进”按钮。
如果您的网页不符合使用返回/前进缓存的条件,返回/前进缓存标签页会显示一系列问题。在可执行下,您可以查看自己是否在使用 unload
:
Reporting API
Reporting API 可与只读权限政策结合使用,以检测网站用户对 unload
的使用情况。
如需了解详情,请参阅使用 Reporting API 查找卸载
Bfcache notRestoredReasons
API
添加到 PerformanceNavigationTiming
类的 notRestoredReasons
属性会报告有关文档是否被禁止在导航中使用 bfcache 以及原因的信息。如需查看使用说明,请点击此处。以下示例展示了现有 unload
监听器的响应对象警告的外观:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
控制对 unload
的访问权限
Chrome 会逐步弃用 unload
事件。在此期间,您可以使用不同的工具来控制此行为,并为即将弃用做好准备。请注意,您不应长期依赖这些技术,而应尽快规划迁移到替代方案。
您可以通过启用或停用 unload
处理程序来测试网站在没有这些处理程序的情况下如何运行,以便为即将被弃用的处理程序做好准备。政策有不同的类型:
- 权限政策:这是一个平台 API,可供网站所有者通过使用 HTTP 标头在网站一级或单个网页一级控制对功能的访问权限。
- 企业版政策:供 IT 管理员为其组织或企业配置 Chrome 的工具。您可以通过管理控制台(例如 Google 管理控制台)进行配置。
- Chrome 标志:这让单个开发者可以更改
unload
废弃设置,以测试对各种网站的影响。
“权限”政策
Chrome 115 中新增了权限政策,以允许网站选择停用 unload
处理程序,并立即从 bfcache 中受益以提高网站性能。请参阅有关如何为您的网站设置此参数的示例。这样,网站就可以在 unload
弃用之前做好准备。
Chrome 117 中将延长此期限,以允许网站执行相反操作,并选择继续尝试触发 unload
处理脚本,因为 Chrome 将在未来将默认设置更改为不触发这些脚本。请参阅有关如何继续允许为您的网站触发卸载处理脚本的示例。此选择不会永久有效,应用于为网站留出时间来从 unload
处理程序迁移。
企业政策
如果企业的软件需要 unload
事件才能正常运行,则可以使用 ForcePermissionPolicyUnloadDefaultEnabled
政策,以防止其控制的设备逐步弃用该事件。启用此政策后,unload
将继续默认为所有来源启用。网页仍可根据需要设置更严格的政策。与停用权限政策一样,这是一种用于缓解潜在破坏性更改的工具,但不应无限期使用。
Chrome 标志和命令行开关
除了企业政策之外,您还可以通过 Chrome 标志和命令行开关为个别用户停用弃用功能:
将 chrome://flags/#deprecate-unload
此设置设为 enabled
会提前采用默认的废弃设置,并阻止 unload
处理脚本触发。您仍然可以通过“权限政策”逐个网站进行覆盖,但默认情况下仍会继续触发。
这些设置也可以通过命令行开关来控制。
选项比较
下表总结了前面讨论的选项的不同用途:
提早弃用 | 提前弃用(有例外情况) | 防止弃用,以确保有足够的时间进行迁移 | |
---|---|---|---|
“权限”政策 (适用于网页/网站) |
是 | 是 | 是 |
企业政策 (适用于设备) |
否 | 否 | 是 |
Chrome flag (适用于个别用户) |
是 | 否 | 否 |
Chrome 命令行开关 (适用于个别用户) |
是 | 否 | 是 |
总结
unload
处理脚本即将被弃用。它们长期以来一直不可靠,并且无法保证在文档销毁的所有情况下都会触发。此外,unload
处理脚本与 bfcache 不兼容。
目前使用 unload
处理脚本的网站应为即将弃用 unload
处理脚本做好准备,具体方法包括测试是否存在任何现有 unload
处理脚本、移除或迁移这些处理脚本,或者在万不得已的情况下,延迟弃用时间(如果需要更多时间)。
致谢
感谢 Kenji Baheux、Fergal Daly、Adriana Jara 和 Jeremy Wagner 帮助审阅本文。
主打图片:Unsplash 上的 Anja Bauermann