Устаревшее событие выгрузки

Demián Renzulli

Barry Pollard

Опубликовано: 10 августа 2023 г., Последнее обновление: 23 июня 2025 г.

Событие unload будет постепенно упразднено путем постепенного изменения значения по умолчанию таким образом, чтобы обработчики unload перестали срабатывать на страницах, если только страница явно не согласится повторно включить их.

Хронология устаревания

Мы отметили, что поведение unload, скорее всего, будет подвержено изменениям еще в январе 2019 года, когда мы объявили о своем намерении реализовать кэширование назад/вперед . Параллельно с работой по внедрению мы провели большую разъяснительную работу, которая привела к значительному снижению использования unload . В дополнение к этой разъяснительной работе мы также начали предлагать способы проверки эффекта от отмены unload из Chrome 115:

• В реальных условиях тестирование с использованием API Permission-Policy для выгрузки в Chrome 115 (июль 2023 г.)
• Локальное тестирование путем включения флага в Chrome 117 (сентябрь 2023 г.)

В течение 2024 года мы решили ряд проблем, препятствовавших началу внедрения.

Вот текущая временная шкала устаревания для события unload :

После завершения развертывания на 50 лучших сайтах мы сделаем паузу и дадим этому время на обработку в течение одного-двух этапов, а затем получим дополнительное одобрение для развертывания на всех источниках в течение следующих 8 этапов (или около 32 недель), что предварительно будет выглядеть следующим образом:

Обратите внимание, что мы также предлагаем меню опций отказа в случае, если эта временная шкала устаревания не предоставляет достаточно времени для перехода от выгрузки. Наша цель — использовать эту мягкую устаревку , чтобы информировать временную шкалу для последней фазы ( жесткая устаревка выгрузки ), в которой эти отказы будут удалены или сокращены.

Фон

unload был разработан для срабатывания при выгрузке документа. Теоретически его можно использовать для запуска кода в любое время, когда пользователь покидает страницу, или в качестве обратного вызова по окончании сеанса.

Сценарии, в которых это событие использовалось чаще всего, включают:

• Сохранение данных пользователя : сохраните данные перед тем, как покинуть страницу.
• Выполнение задач очистки : закрытие открытых ресурсов перед закрытием страницы.
• Отправка аналитики : отправка данных, связанных с взаимодействиями пользователя, в конце сеанса.

Однако событие unload крайне ненадежно .

В настольных браузерах Chrome и Firefox unload достаточно надежна, но она отрицательно влияет на производительность сайта, поскольку не позволяет использовать bfcache (прямой кэш) .

В мобильных браузерах unload часто не запускается, так как вкладки часто уходят в фоновый режим и затем закрываются. По этой причине браузеры предпочитают отдавать приоритет bfcache на мобильных устройствах над unload , что делает их еще более ненадежными. Safari также использует это поведение на десктопе.

Команда Chrome считает, что использование мобильной модели приоритета bfcache над unload на десктопе будет разрушительным, делая его более ненадежным и там, хотя ранее это было достаточно надежно в Chrome (и Firefox). Вместо этого цель Chrome — полностью удалить событие unload . До тех пор оно останется надежным на десктопе для тех, кто явно отказался от устаревания.

Почему следует отказаться от события unload ?

Отказ от unload — это ключевой шаг в гораздо большем признании Интернета, в котором мы живем сейчас. Событие unload дает ложное ощущение контроля над жизненным циклом приложения, что все больше не соответствует тому, как мы просматриваем Интернет в современном компьютерном мире.

Мобильные операционные системы часто замораживают или выгружают веб-страницы для экономии памяти, и браузеры настольных компьютеров делают это все чаще и по тем же причинам. Даже без вмешательства операционной системы пользователи сами часто переключаются между вкладками и закрывают старые вкладки, формально не "покидая страницы".

Удаление события unload как устаревшего — это признание того, что нам, веб-разработчикам, необходимо обеспечить соответствие нашей парадигмы реальному миру и не зависеть от устаревших концепций, которые больше не актуальны, если когда-либо были таковыми.

Альтернативы unload событий

Вместо unload рекомендуется использовать:

• visibilitychange : определить, когда изменяется видимость страницы. Это событие происходит, когда пользователь переключает вкладки, сворачивает окно браузера или открывает новую страницу. Рассматривайте hidden состояние как последнее надежное время для сохранения данных приложения и пользователя.
• pagehide : определить, когда пользователь покинул страницу. Это событие происходит, когда пользователь покидает страницу, перезагружает страницу или закрывает окно браузера. Событие pagehide не срабатывает, когда страница сворачивается или переключается на другую вкладку. Обратите внимание, что, поскольку pagehide не делает страницу непригодной для кэширования вперед/назад, возможно, страница может быть восстановлена ​​после срабатывания этого события. Если вы очищаете какие-либо ресурсы в этом событии, то их, возможно, придется восстановить при восстановлении страницы.

Событие beforeunload имеет немного другой вариант использования для unload , поскольку это отменяемое событие. Его часто используют для предупреждения пользователей о несохраненных изменениях при переходе на другую страницу. Это событие также ненадежно, так как оно не сработает, если фоновая вкладка будет закрыта. Рекомендуется ограничить использование beforeunload и добавлять его только условно . Вместо этого используйте ранее упомянутые события для большинства замен unload .

Более подробную информацию см. в этом совете о том, как никогда не использовать обработчик unload .

Обнаружение использования unload

Существуют различные инструменты, которые помогут вам найти появление события unload на страницах. Это позволяет сайтам обнаружить, используют ли они это событие — либо в своем собственном коде, либо с помощью библиотек — и поэтому могут быть затронуты предстоящим устареванием.

Инструменты разработчика Chrome

Chrome DevTools включает аудит back-forward-cache , который поможет вам выявить проблемы, которые могут помешать вашей странице быть доступной для возвратного кэширования, включая использование обработчика unload .

Чтобы протестировать возвратный кэш, выполните следующие действия:

1. На своей странице откройте DevTools , затем перейдите в Application > Background services > Back/forward cache .

2. Нажмите Тест кэша назад/вперед Chrome автоматически перенаправляет вас на chrome://terms/ и обратно на вашу страницу. В качестве альтернативы вы можете нажать кнопки браузера «назад» и «вперед».

Если ваша страница не подходит для кэширования назад/вперед, вкладка кэширования назад/вперед показывает вам список проблем. В разделе Actionable вы можете увидеть, используете ли вы unload :

API для создания отчетов

API отчетов можно использовать совместно с политикой разрешений только для чтения для обнаружения использования unload пользователями вашего веб-сайта.

Более подробную информацию см. в разделе Использование API отчетов для поиска выгрузок.

API Bfcache notRestoredReasons

Свойство notRestoredReasons — добавленное к классу PerformanceNavigationTiming — сообщает информацию о том, были ли заблокированы документы от использования bfcache при навигации и почему. Это пример того, как выглядит предупреждение объекта ответа существующего прослушивателя unload :

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

Контроль доступа для unload

Chrome постепенно отменит событие unload . В то же время вы можете использовать различные инструменты для управления этим поведением и подготовки к предстоящему устареванию. Помните, что вам не следует полагаться на эти методы в долгосрочной перспективе, и вам следует запланировать переход на альтернативы как можно скорее.

Следующие параметры позволяют вам включать или отключать обработчики unload , чтобы проверить, как ваш сайт будет работать без них, чтобы вы могли подготовиться к предстоящему устареванию. Существуют различные типы политик:

• Политика разрешений : это API-интерфейс платформы, позволяющий владельцам сайтов контролировать доступ к функциям на уровне сайта или отдельной страницы с помощью заголовков HTTP.
• Корпоративные политики : инструменты для ИТ-администраторов, позволяющие им настраивать Chrome для своей организации или бизнеса. Их можно настроить с помощью панели администратора, например, Google Admin Console .
• Флаги Chrome : это позволяет отдельному разработчику изменять настройки устаревания unload , чтобы проверить влияние на различные сайты.

Политика разрешений

Политика разрешений была добавлена ​​в Chrome 115, чтобы позволить сайтам отказаться от использования обработчиков unload и немедленно воспользоваться bfcache для повышения производительности сайта. Посмотрите эти примеры того, как настроить это для вашего сайта . Это позволяет сайтам опережать устаревание unload .

Это будет расширено в Chrome 117, чтобы позволить сайтам делать обратное и выбирать продолжение попыток запуска обработчиков unload , поскольку Chrome изменяет значение по умолчанию, чтобы они не запускались в будущем. Посмотрите эти примеры того, как продолжить разрешать обработчикам выгрузки запускаться для вашего сайта . Это согласие не останется навсегда и должно использоваться, чтобы дать сайтам время для перехода от обработчиков unload .

Политика предприятия

Предприятия, у которых есть программное обеспечение, зависящее от события unload для корректной работы, могут использовать политику ForcePermissionPolicyUnloadDefaultEnabled , чтобы предотвратить постепенное устаревание для устройств, находящихся под их контролем. При включении этой политики unload будет по-прежнему включен по умолчанию для всех источников. Страница может по-прежнему устанавливать более строгую политику, если захочет. Как и отказ от политики разрешений, это инструмент для смягчения потенциальных критических изменений, но его не следует использовать бесконечно.

Флаги Chrome и ключи командной строки

Помимо корпоративной политики, вы можете отключить устаревание для отдельных пользователей с помощью флагов Chrome и параметров командной строки:

Установка chrome://flags/#deprecate-unload на значение enabled выведет на передний план устаревание по умолчанию и предотвратит срабатывание обработчиков unload . Их по-прежнему можно переопределить на основе сайта за сайтом с помощью политики разрешений, но они продолжат срабатывать по умолчанию.

Этими настройками также можно управлять с помощью ключей командной строки .

Сравнение вариантов

В следующей таблице обобщены различные варианты использования рассмотренных ранее опций:

Заключение

Обработчики unload устарели. Они долгое время были ненадежными и не гарантированно срабатывают во всех случаях уничтожения документа. Кроме того, обработчики unload несовместимы с bfcache .

Сайты, использующие обработчики unload , должны подготовиться к предстоящему устареванию, проверив наличие существующих обработчиков unload , удалив или перенеся их или, в крайнем случае, отложив устаревание, если требуется больше времени.

Благодарности

Выражаем благодарность Кенджи Бахе, Фергалу Дейли, Адриане Харе и Джереми Вагнеру за помощь в рецензировании этой статьи.

Главное изображение от Ани Бауэрманн на Unsplash