Опубликовано: 10 августа 2023 г., Последнее обновление: 29 января 2026 г.
Событие unload будет постепенно устаревать путем постепенного изменения значения по умолчанию таким образом, чтобы обработчики unload переставали срабатывать на страницах, если страница явно не решит снова включить их.
Хронология устаревания
Мы отметили, что поведение функции выгрузки, вероятно, будет подвержено изменениям уже в январе 2019 года, когда мы объявили о своем намерении внедрить кэширование «назад/вперед» . Параллельно с работой по внедрению мы провели масштабную информационную кампанию, которая привела к значительному снижению использования функции выгрузки . В дополнение к этой кампании мы также начали предлагать способы проверки эффекта отказа от функции выгрузки в Chrome 115:
- В ходе тестирования на практике с использованием API Permission-Policy для функции unload в Chrome 115 (июль 2023 г.)
- Локальное тестирование путем включения соответствующего флага в Chrome 117 (сентябрь 2023 г.)
В течение 2024 года мы устранили ряд проблем, препятствовавших началу внедрения, а в течение 2025 года осуществили деактивацию на 50 крупнейших сайтах.
| Важный этап | Важная дата | Топ-50 сайтов | % других национальностей |
|---|---|---|---|
| 135 | 26 марта 2025 г. | 1 ( www.google.com ) | 0 |
| 139 | 30 июля 2025 г. | 5 | 0 |
| 140 | 27 августа 2025 г. | 10 | 0 |
| 141 | 24 сентября 2025 г. | 25 | 0 |
| 142 | 22 октября 2025 г. | 50 | 0 |
Теперь, когда мы завершили вывод из эксплуатации 50 крупнейших сайтов, мы получили дополнительное разрешение на внедрение этой функции во всех точках происхождения в течение 8 этапов (или примерно 32 недель), как подробно описано в следующей таблице.
| Важный этап | Важная дата | Топ-50 сайтов | Процент загрузок страниц Chrome для всех сайтов |
|---|---|---|---|
| 146 | 10 марта 2026 г. | 50 | 1 |
| 147 | 7 апреля 2026 г. | 50 | 5 |
| 148 | 5 мая 2026 г. | 50 | 10 |
| 149 | 2 июня 2026 г. | 50 | 20 |
| 150 | 30 июня 2026 г. | 50 | 40 |
| 151 | 28 июля 2026 г. | 50 | 60 |
| 152 | 25 августа 2026 г. | 50 | 80 |
| 153 | 22 сентября 2026 г. | 50 | 100 |
The full rollout is based on page loads (with consistency over time), rather than individual users or sites to avoid impacting impacting users or sites more than others as detailed in the Intent to Deprecate .
Обратите внимание, что мы также предлагаем меню вариантов отказа на случай, если этот график прекращения поддержки не предоставит достаточно времени для перехода от unload. Наша цель — использовать этот мягкий отказ от поддержки для определения сроков заключительного этапа ( полного прекращения поддержки unload ), в ходе которого эти варианты отказа будут удалены или сокращены.
Фон
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 handler).
Для проверки работы кэша при перемотке вперед/назад выполните следующие действия:
На своей странице откройте Инструменты разработчика , затем перейдите в раздел Приложение > Фоновые службы > Кеш "Назад/вперед" .
Нажмите кнопку «Проверить кэш» (назад/вперед). Chrome автоматически перенаправит вас на
chrome://terms/и вернет на вашу страницу. В качестве альтернативы вы можете нажать кнопки «Назад» и «Вперед» в браузере.
Если ваша страница не подходит для кэширования "назад/вперед", на вкладке "Кэширование "назад/вперед"" отображается список проблем. В разделе "Действующие действия" вы можете увидеть, используете ли вы 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 .
- Флаги Chrome : Это позволяет отдельному разработчику изменять параметр устаревания функции
unloadдля проверки его влияния на различные сайты.
Политика разрешений
В Chrome 115 добавлена политика разрешений, позволяющая сайтам отказаться от использования обработчиков unload и сразу же воспользоваться преимуществами bfcache для повышения производительности сайта. Примеры настройки этой политики для вашего сайта можно найти здесь. Это позволит сайтам опередить устаревание функции unload .
В Chrome 117 эта функция будет расширена, чтобы позволить сайтам делать обратное и включать опцию продолжения попыток запуска обработчиков unload , поскольку Chrome в будущем изменит настройки по умолчанию, чтобы они не запускались. См. эти примеры того, как разрешить запуск обработчиков выгрузки для вашего сайта. Эта опция не будет действовать вечно и должна использоваться, чтобы дать сайтам время отказаться от обработчиков выгрузки unload
Корпоративная политика
Предприятия, чье программное обеспечение зависит от события unload для корректной работы, могут использовать политику ForcePermissionPolicyUnloadDefaultEnabled , чтобы предотвратить постепенное прекращение поддержки этого события для устройств, находящихся под их контролем. При включении этой политики unload по умолчанию будет включена для всех источников. Страница может по-прежнему устанавливать более строгую политику, если захочет. Как и отказ от политики разрешений, это инструмент для смягчения потенциальных критических изменений, но его не следует использовать постоянно.
Флаги Chrome и параметры командной строки
Помимо корпоративной политики, вы можете отключить устаревание для отдельных пользователей, используя флаги Chrome и параметры командной строки:
Установка параметра chrome://flags/#deprecate-unload в enabled приведет к срабатыванию обработчиков unload по умолчанию и предотвратит их запуск. Их по-прежнему можно переопределить для каждого сайта отдельно с помощью политики разрешений, но они будут продолжать срабатывать по умолчанию.
Этими настройками также можно управлять с помощью параметров командной строки .
Сравнение вариантов
В следующей таблице приведено краткое описание различных вариантов использования, рассмотренных ранее:
| Ускорьте процесс амортизации. | Перенести амортизацию на более ранний срок (с исключениями). | Предотвратите устаревание, чтобы обеспечить время для миграции. | |
|---|---|---|---|
| Политика разрешений (Применяется к страницам/сайтам) | Да | Да | Да |
| Корпоративная политика (применяется к устройствам) | Нет | Нет | Да |
| Флаги Chrome (применяется к отдельным пользователям) | Да | Нет | Нет |
| Параметры командной строки Chrome (применяется к отдельным пользователям) | Да | Нет | Да |
Заключение
Обработчики unload устаревают. Они долгое время были ненадежны и не гарантируют срабатывания во всех случаях уничтожения документа. Кроме того, обработчики unload несовместимы с bfcache .
Предприятиям, использующим unload терминалы, следует подготовиться к предстоящему прекращению их поддержки, проверив существующие unload , удалив или перенеся их, или, в крайнем случае, отложив прекращение поддержки, если потребуется больше времени.
Благодарности
Благодарим Кенджи Бахе, Фергала Дейли, Адриану Хару и Джереми Вагнера за помощь в рецензировании этой статьи.
Главное изображение предоставлено Аней Бауэрманн на Unsplash.