Опубликовано: 21 января 2026 г.
Начиная с Chrome 144, процесс обновления устанавливаемых веб-приложений, имеющих манифест веб-приложения , был оптимизирован, став более детерминированным, предсказуемым и эффективным. В этом посте описывается текущий подход и изменения, внесенные для его улучшения.
Предыдущий подход (до Chrome 144)
До версии Chrome 144 веб-приложения не имели специального события для упреждающего запуска обновлений. Вместо этого обновления могли происходить, когда разработчики изменяли манифест приложения или связанные с ним значки. Процесс обновления начинается, когда пользовательский агент получает манифест , используя ссылку на манифест , что обычно происходит, когда пользователь посещает сайт или запускает приложение (с этим манифестом по ссылке). Чтобы определить, требуется ли обновление, система сравнивает текущий манифест и значки с ранее записанным состоянием. Эта процедура была ресурсоемкой, поскольку всегда требовала загрузки значков из сети для выполнения сравнения растровых изображений.
Чтобы снизить нагрузку на сервер, связанную с загрузкой значков, Chrome ввел ограничение на количество проверок — до одного раза в день для каждого приложения, — но общее потребление полосы пропускания оставалось высоким. Кроме того, ограничение количества проверок до одного раза в день приводит к несоответствиям во время разработки и тестирования, а также препятствует разработчикам предоставлять надежные решения пользователям, которые не получили обновления.
При таком подходе разработчикам приходилось сталкиваться со сложностями при внедрении изменений, имеющих важное значение для безопасности , таких как обновление названия или значка приложения, часто называемых изменениями идентификатора приложения. Поскольку веб-приложения не имеют централизованного органа, подобного Google Play, для проверки обновлений, эти изменения должны быть четко представлены пользователям для подтверждения. Однако определение наиболее подходящего времени для запроса подтверждения этих изменений у пользователей оставалось сложной задачей.
В предыдущих версиях диалогового окна обновления также часто возникала путаница, поскольку утверждалось, что значки изменились, хотя для пользователя они выглядели идентично. Эта проблема была вызвана использованием прямого сравнения пикселей, которое часто выявляло незначительные различия. Хотя некоторые вариации были результатом преднамеренных изменений разработчиков, многие были вызваны динамическим перекодированием изображений CDN. Это частое чрезмерное срабатывание диалогового окна подтверждения в конечном итоге привело к отключению обновления значков в Chrome 91.
Для решения этой проблемы в Chrome для Android несколько лет назад был введен порог визуальной разницы. Это гарантирует, что подтверждение пользователя запрашивается только в том случае, если изменения значка существенны. Это усовершенствование позволило восстановить обновление значка на Android, хотя эта функция остается отключенной в Chrome на настольных компьютерах.


Ограничения и цели изменений при обновлении веб-приложений.
При разработке нового процесса обновления руководствовались следующими целями:
- Сохраняйте ожидания пользователей: поскольку идентичность приложения неразрывно связана с его происхождением, его название и значок не должны изменяться без явного согласия пользователя.
- Обеспечение функциональной согласованности: приложения должны оставаться максимально актуальными для всех пользователей, чтобы обеспечить единообразную функциональность.
- Обеспечьте предсказуемый пользовательский интерфейс и диалоги: разработчики должны иметь возможность легко предвидеть, когда пользователи столкнутся с подсказками интерфейса, касающимися обновления названий или значков приложений.
- Оптимизация использования сети: механизм обновления должен минимизировать ненужный трафик данных.
Что изменилось в Chrome 144?
Теперь обновление названия и значка является необязательным.
Раньше пользователям приходилось сталкиваться с навязчивым диалоговым окном, требующим либо удалить приложение, либо немедленно принять изменения значка и названия. Теперь это заменено более удобным для пользователя вариантом, доступным через расширенное меню из трех точек. После выбора этого варианта пользователи теперь могут полностью игнорировать эти изменения, если захотят.
Хотя большинство обновлений манифеста применяются немедленно, значки и названия приложений — элементы, имеющие важное значение для безопасности — хранятся отдельно. Это позволяет пользователям просматривать и применять эти конкретные изменения в удобное для них время.

При нажатии на кнопку «Проверить обновление приложения» отображается отредактированное диалоговое окно. Заголовок меняется в зависимости от того, какие элементы обновляются.

Иконки не загружаются, если в поле "Иконки" нет изменений.
Теперь значки считаются неизмененными, если поле icons в манифесте остается таким же, как и в последней примененной версии. В соответствии с этой новой логикой Chrome избегает загрузки значков для визуального сравнения, фактически рассматривая URL-адреса значков как Cache-Control:immutable . Для запуска обновления значков разработчикам теперь необходимо изменить либо метаданные, либо URL-адрес значка .
Снятие ограничения на количество обновлений.
Поскольку Chrome больше не загружает значки каждый раз, когда обнаруживает манифест установленного приложения, предыдущее ограничение, которое сводило проверку обновлений к одному разу в день, было снято. Теперь разработчики могут быть уверены, что обновление произойдет немедленно для всех приложений , не представляющих угрозу безопасности .
Обработка незначительных различий в значках на разных платформах.
Для улучшения пользовательского опыта Chrome теперь автоматически применяет обновления значков, которые показывают разницу менее 10% при попиксельном сравнении. Это гарантирует, что незначительные изменения, например, вызванные перекодированием CDN, не вызовут у пользователя запутанное диалоговое окно обновления.
Количество разрешенных обновлений ограничено одним разом в день, чтобы предотвратить возможные злоупотребления. Если в течение этого периода произойдут дальнейшие изменения, значок будет рассматриваться как стандартное обновление, и пользователю будет предложено подтвердить изменение.
Пример обновления значка и имени
{
"name": "Example App",
"short_name": "App",
"id": "https://www.example-app.com/",
"start_url": "https://www.example-app.com/index.html",
"scope": "https://www.example-app.com/",
"icons": [
{
"src": "https://www.example-app.com/img/app.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
}
],
... other attributes omitted ...
}
Изменение URL-адреса значка гарантирует, что пользователь увидит диалоговое окно обновления для изменения значка.
{
"name": "Example App",
"short_name": "App",
"id": "https://www.example-app.com/",
"start_url": "https://www.example-app.com/index.html",
"scope": "https://www.example-app.com/",
"icons": [
{
"src": "https://www.example-app.com/img/app-NEW-URL.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
}
],
... other attributes omitted ...
}