В Chrome 108 представлены два новых режима: «Экономия памяти» и «Экономия энергии» , чтобы дать пользователям больше контроля над тем, как Chrome использует системные ресурсы.
Хотя эти новые режимы в первую очередь ориентированы на пользователя, они имеют некоторые последствия, о которых важно знать веб-разработчикам, поскольку они потенциально могут повлиять на взаимодействие с пользователем вашего сайта.
В этом посте будут рассмотрены потенциальные эффекты этих новых режимов и то, что веб-разработчики могут сделать, чтобы обеспечить наилучшее качество работы.
Режим экономии памяти
Когда включен режим экономии памяти, Chrome заранее удаляет вкладки, которые в течение некоторого времени не использовались в фоновом режиме. Это освобождает память для активных вкладок, а также для других приложений, которые могут быть запущены. Пользователи могут указать Chrome не удалять вкладки для определенных сайтов; однако это предпочтения пользователя, а не то, чем вы как разработчик можете управлять.
Когда вкладка удалена, ее заголовок и значок по-прежнему отображаются в полосе вкладок, но сама страница исчезает, точно так же, как если бы вкладка была закрыта обычным способом. Если пользователь повторно посетит эту вкладку, страница будет перезагружена автоматически.
Для страниц с чисто контентом удаление и перезагрузка вкладки, скорее всего, не повлияет на взаимодействие с пользователем, но для насыщенных интерактивных сайтов со сложным пользовательским потоком перезагрузка в середине этого потока может быть чрезвычайно неприятной, если сайт не сможет восстановить страницу именно там, где остановился пользователь.
Удаление вкладок для экономии памяти — это то, что Chrome делал уже много лет, но это делалось только в ситуациях, когда в системе было нехватка памяти. Учитывая относительно редкое явление, веб-разработчики, возможно, не осознавали, что это происходит.
Начиная с Chrome 108, отбрасывание вкладок станет более распространенным, поэтому очень важно, чтобы сайты могли корректно обрабатывать такие случаи.
Лучшие практики для обработки сброса вкладок
Удаление вкладок — не новая проблема для веб-разработчиков. Пользователь всегда мог перезагрузить страницу — намеренно или случайно — перед выполнением своей задачи. Поэтому сайтам всегда было важно сохранять состояние пользователя, чтобы можно было восстановить его, если пользователь уйдет и вернется.
Самый важный вопрос заключается не в том, следует ли сохранять состояние пользователя, а в том, когда его хранить. И это важно, потому что не существует события, которое срабатывает при удалении вкладки, поэтому у разработчиков нет возможности отреагировать на тот факт, что это происходит. Вместо этого разработчикам необходимо предвидеть такую возможность и заранее подготовиться.
Лучшее время для хранения состояния пользователя:
- Периодически по мере изменения состояния.
- Всякий раз, когда вкладка находится в фоновом режиме (событие
visibilitychange).
Худшее время для хранения состояния:
- В обратном вызове события
beforeunload. - В обратном вызове события
unload.
Это худшее время для хранения состояния, поскольку эти события совершенно ненадежны и не срабатывают во многих ситуациях, в том числе при удалении вкладки.
Вы можете обратиться к диаграмме событий жизненного цикла страницы, чтобы узнать, какие события должны сработать при удалении страницы. Как видно из этой диаграммы, вкладка может перейти из «скрытого» состояния в «отброшенное» состояние без каких-либо событий.
Фактически, каждый раз, когда страница находится в «скрытом» состоянии, нет гарантии, что возникнут какие-либо другие события до того, как страница будет либо удалена браузером, либо закрыта пользователем, поэтому важно всегда сохранять любые несохраненные данные. состояние пользователя в событии visibilitychange , так как другого шанса у вас может не быть.
В следующем коде приведен пример логики для сохранения текущего состояния пользователя в очереди каждый раз, когда оно изменяется, или немедленно, если пользователь перемещает вкладку в фоновый режим или уходит:
let state = {};
let hasUnstoredState = false;
function storeState() {
if (hasUnstoredState) {
// Store `state` to localStorage or IndexedDB...
}
hasUnstoredState = false;
}
export function updateState(newState) {
state = newState;
hasUnstoredState = true;
requestIdleCallback(storeState);
}
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
storeState();
}
});
Обнаружение того, что вкладка была удалена
Как упоминалось ранее, невозможно обнаружить, что вкладка вот-вот будет удалена, но можно обнаружить, что вкладка была удалена после того, как пользователь вернется к ней и страница будет перезагружена. В таких ситуациях свойство document.wasDiscarded будет иметь значение true.
if (document.wasDiscarded) {
// The page was reloaded after a discard.
} else {
// The page was not reloaded after a discard.
}
Если вы хотите понять, как часто ваши пользователи сталкиваются с подобными ситуациями, вы можете настроить свой инструмент аналитики для сбора этой информации.
Например, в Google Analytics вы можете настроить специальный параметр события , который позволит вам определить, какой процент просмотров страниц произошел из-за отклонения вкладок:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
Если вы являетесь поставщиком аналитических услуг, возможно, вы захотите добавить это измерение в свой продукт по умолчанию.
Тестирование вашего сайта в режиме экономии памяти
Вы можете проверить, как страница обрабатывает удаление, загрузив ее, а затем посетив chrome://discards в отдельной вкладке или окне.
В пользовательском интерфейсе chrome://discards вы можете найти вкладку, которую хотите удалить из списка, а затем нажать «Срочно удалить» в столбце «Действия» .
Это приведет к удалению вкладки, что позволит вам вернуться к ней и убедиться, что страница была перезагружена в том же состоянии, в котором вы ее покинули.
Обратите внимание, что в настоящее время не существует способа автоматизировать удаление вкладок с помощью инструментов тестирования, таких как webdriver или puppeteer; однако, поскольку удаление и восстановление вкладок почти идентично перезагрузке страницы, если вы проверите, что состояние пользователя восстанавливается после перезагрузки в середине пользовательского потока, это, скорее всего, будет работать и для удаления/восстановления. Основное различие между ними заключается в том, что события beforeunload , pagehide и unload не срабатывают при удалении вкладки, поэтому, пока вы не полагаетесь на эти события для сохранения состояния пользователя, вы можете использовать перезагрузки для проверки удаления. /восстановить поведение.
Режим энергосбережения
Когда включен режим энергосбережения, Chrome экономит заряд батареи за счет уменьшения частоты обновления экрана, что влияет на точность прокрутки и анимации, а также частоту кадров видео.
В целом разработчикам не нужно ничего делать для поддержки режима Energy Saver. API CSS и JavaScript для анимации , переходов и requestAnimationFrame() автоматически адаптируются к любому изменению частоты обновления дисплея, когда этот режим включен.
Основной сценарий, в котором этот режим может быть проблематичным, — это если ваш сайт использует анимацию на основе JavaScript, которая предполагает определенную частоту обновления для всех пользователей.
Например, если ваш сайт использует циклы requestAnimationFrame() и предполагает, что между обратными вызовами пройдет ровно 16,67 миллисекунды, ваша анимация будет работать в два раза медленнее, когда включен режим энергосбережения.
Обратите внимание, что разработчикам всегда было проблематично предполагать частоту обновления по умолчанию 60 Гц для всех пользователей, поскольку это неверно для многих современных устройств.
Измерение частоты обновления дисплея
Специального веб-API для измерения частоты обновления дисплея не существует, и в целом попытки сделать это с помощью текущих API не рекомендуется .
Лучшее, что разработчики могут сделать с существующими API, — это сравнить временные метки между последовательными обратными вызовами requestAnimationFrame() . Хотя в большинстве случаев это работает для приблизительной частоты обновления в данный момент времени, оно не позволяет узнать, когда частота обновления изменится. Для этого вам придется постоянно запускать опрос requestAnimationFrame() , что противоречит цели сохранения энергии или срока службы батареи для ваших пользователей.
Тестирование вашего сайта в режиме энергосбережения
Один из способов протестировать ваш сайт в режиме энергосбережения — включить этот режим в настройках Chrome и настроить его на запуск, когда ваше устройство отключено от сети.
Если у вас нет устройства, которое можно отключить, вы также можете включить этот режим вручную, выполнив следующие действия:
- Включите флаг
chrome://flags/#battery-saver-mode-available. - Посетите
chrome://discardsи нажмите ссылку «Переключить режим экономии заряда батареи» ( важно: для работы ссылки необходимо включить флаг#battery-saver-mode-available).
После включения вы можете взаимодействовать со своим сайтом и проверять, что все выглядит так, как должно: например, что анимация и переходы выполняются с желаемой скоростью.
Краткое содержание
Хотя режимы Chrome «Экономия памяти» и «Энергосбережение» в первую очередь предназначены для пользователей, они имеют значение для разработчиков, поскольку могут негативно повлиять на удобство посещения вашего сайта, если с ними не обращаться должным образом.
В целом, эти новые режимы были разработаны с учетом существующих лучших практик разработчиков. Если разработчики следуют давним передовым практикам в Интернете, их сайты должны продолжать нормально работать в этих новых режимах.
Однако, если ваш сайт содержит какие-либо методы, описанные в этом посте, вполне вероятно, что ваши пользователи сталкиваются с проблемами, которые только усугубятся при включении этих двух режимов.
Как всегда, лучший способ убедиться в том, что вы предоставляете отличный опыт, — это протестировать свой сайт в условиях, соответствующих условиям ваших пользователей.