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

Demián Renzulli

Barry Pollard

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

График прекращения поддержки

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

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

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

• Ограниченный этап, на котором выгрузка постепенно перестанет функционировать для 50 самых популярных сайтов ( ссылка на момент написания).
  • Начиная с 1% пользователей Chrome 120 (конец ноября 2023 г.).
  • Окончание со 100 % пользователей к концу третьего квартала 2024 г.
• Кроме того, с третьего квартала 2024 года мы намерены начать общий этап, на котором выгрузка постепенно перестанет работать на любых сайтах, начиная с 1 % пользователей и заканчивая 100 % пользователей к концу первого квартала 2025 года.

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

Фон

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 , затем выберите Приложение > Фоновые службы > Кэш назад/вперед .

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-handler"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

Контролируйте доступ к unload

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

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

• Политика разрешений . Это API-интерфейс платформы, позволяющий владельцам сайтов контролировать доступ к функциям на уровне сайта или отдельной страницы с помощью HTTP-заголовков.
• Корпоративные политики : инструменты, позволяющие ИТ-администраторам настраивать 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 . Их по-прежнему можно переопределить для каждого сайта с помощью политики разрешений, но они продолжат активироваться по умолчанию.

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

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

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

Заключение

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

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

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

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

Героическое изображение Ани Бауэрманн на Unsplash