Chrome 153 перешёл на релизы каждые две недели: что это меняет для сайтов

8 сентября 2026 года команда Chrome запустила новый ритм обновлений: начиная с Chrome 153, Stable-релизы браузера выходят каждые две недели вместо прежнего четырёхнедельного цикла. Chrome 153 одновременно начал развёртываться на Desktop, Android и iOS.

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

Что именно изменилось с Chrome 153

Google уже ускорял цикл Chrome: в 2021 году браузер перешёл на четырёхнедельный ритм. Теперь интервал между основными Stable-релизами сокращён ещё вдвое.

По официальному объявлению Chrome for Developers, для веб-разработчиков это означает, что функции будут попадать в Stable каждые две недели, а объём изменений в одном релизе станет меньше. Такой подход упрощает поиск причины регрессии: когда между двумя версиями меньше изменений, легче сузить круг подозреваемых изменений.

Почему Google ускоряет релизы

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

Это не означает, что каждое исправление безопасности обязано ждать очередного двухнедельного milestone. Chrome и раньше выпускал отдельные обновления и патчи. Речь о том, что основной Stable-цикл теперь тоже стал короче.

Что это меняет для разработчика сайта

Главное практическое изменение — тестировать сайт только после выхода очередной большой версии становится менее удобной стратегией. Когда Stable обновляется каждые две недели, разумнее раньше замечать несовместимости в Beta.

• Проверять ключевые пользовательские сценарии в Chrome Beta до выхода версии в Stable.
• Не ограничиваться открытием главной страницы: тестировать формы, меню, модальные окна, оплату, личный кабинет и JavaScript-интерактив.
• Фиксировать ошибки консоли и сетевые сбои, чтобы отличать проблему браузера от проблемы темы, плагина или стороннего сервиса.
• Для проектов с автотестами добавить актуальные Stable и Beta версии в матрицу браузерного тестирования.

Для WordPress это особенно актуально на проектах с большим количеством JavaScript: Elementor, сложные WooCommerce-интерфейсы, кастомные виджеты, сторонние чаты, аналитика и платёжные формы могут зависеть от браузерного поведения сильнее, чем простая статическая страница.

Меньше изменений за релиз — не значит нулевой риск

Двухнедельный цикл не делает обновления автоматически безопасными для любого сайта. Он лишь уменьшает средний объём изменений, который попадает в один milestone. Регрессия всё равно может возникнуть из-за CSS, JavaScript API, особенностей рендеринга, расширений браузера или стороннего кода.

Поэтому полезнее не «бояться обновления Chrome», а иметь повторяемый процесс проверки. Если после обновления сломалась форма или интерфейс, сначала нужно воспроизвести проблему в чистом профиле, проверить DevTools и сравнить поведение в других браузерах.

Chrome 154 Beta уже доступен

Одновременно с запуском нового цикла Google сообщил, что Chrome 154 Beta уже доступен для тестирования. Его Stable-релиз запланирован на 22 сентября 2026 года.

Это хорошо показывает новый темп: у команды сайта появляется короткое окно между Beta и следующим Stable milestone. Для критичных проектов имеет смысл сделать проверку Beta частью обычной поддержки, а не отдельным авралом после жалоб пользователей.

Что с корпоративными пользователями

Для организаций, которым сложно принимать функциональные изменения каждые две недели, Chrome сохраняет Extended Stable. В официальном объявлении указано, что крупные feature-обновления Extended Stable приходят каждые восемь недель, при этом исправления безопасности продолжают переноситься на регулярной основе.

То есть новый двухнедельный цикл не означает, что enterprise-инфраструктура обязана одинаково быстро принимать каждую функциональную версию. Но тестовые процессы всё равно нужно привязать к выбранному каналу обновлений.

Нужно ли владельцу WordPress что-то срочно менять

Нет отдельной настройки WordPress, которую нужно включить из-за Chrome 153. Сам WordPress не управляет циклом браузера. Зато полезно проверить, насколько быстро вы замечаете браузерные регрессии.

Если сайт регулярно дорабатывается, разумный минимум — проверять основные сценарии после обновлений браузеров и перед крупными рекламными запусками. Для проектов с активной разработкой лучше добавить Beta в тестирование заранее.

Если на существующем сайте уже есть нестабильные формы, мобильное меню, ошибки JavaScript или конфликтующие плагины, более частые браузерные обновления не создают эти проблемы, но могут быстрее их проявить. В таких случаях полезна точечная доработка WordPress с проверкой причины, а не случайная замена плагинов.

Как я бы выстроил проверку проекта

1. Определить 5–10 критичных действий пользователя: заявка, поиск, вход, корзина, checkout, загрузка файлов и другие важные сценарии.
2. Проверять их в текущем Stable и актуальном Chrome Beta.
3. Сохранять воспроизводимый сценарий ошибки и данные DevTools.
4. Проверять, проявляется ли проблема в Firefox/Safari/Edge, если это релевантно аудитории.
5. Исправлять причину на уровне темы, плагина или кастомного кода и повторять тест.

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

Официальные источники

• Chrome for Developers — Fresher features, faster fixes: The two-week release cycle is here, 8 сентября 2026
• Chrome for Developers — Chrome 152 release notes, 25 августа 2026
• Chrome for Developers — Chrome 154 Beta

Если нужно проверить существующий сайт на браузерные ошибки, JavaScript-регрессии и проблемные пользовательские сценарии, можно описать задачу A.S Groups — сначала разберём причину, затем определим точечный объём доработки.