A partir de setembro de 2026, o Chrome passará a lançar uma nova versão estável a cada duas semanas. O intervalo entre milestones, que era de quatro semanas desde 2021, será cortado pela metade. A mudança começa com o Chrome 153, previsto para chegar ao canal Stable em 8 de setembro, e vale para desktop, Android e iOS.
Para quem desenvolve para a web, isso não significa reescrever o frontend a cada quinze dias nem reservar uma cadeira extra na daily para o navegador. Significa que recursos, correções e eventuais incompatibilidades podem alcançar os usuários em uma cadência mais rápida. A janela para perceber um problema continua existindo, mas acompanhar o canal Beta deixa de ser uma boa intenção perdida no backlog e passa a ser parte mais importante da rotina.
O que realmente muda no calendário do Chrome
O novo ciclo cria uma versão Beta e uma versão Stable a cada duas semanas. Segundo o Google, cada Beta continuará chegando três semanas antes de sua promoção para Stable. Como os milestones serão mais frequentes, haverá versões em teste sobrepostas: enquanto uma se aproxima do público geral, a próxima já estará avançando pelo canal Beta.
O Chrome 153 inaugura o calendário. Sua versão Beta está prevista para 19 de agosto, seguida pelo lançamento estável em 8 de setembro. O Chrome 154 deve chegar ao Beta em 2 de setembro e ao Stable em 22 de setembro. Os canais Dev e Canary não terão mudança de cadência.
Também é importante separar milestones de atualizações menores. O Chrome já distribui correções de segurança semanalmente, então o navegador não ficava congelado por quatro semanas entre duas versões principais. O que acelera agora é a numeração principal e o pacote de mudanças promovido pelos canais de desenvolvimento.
Versões menores podem facilitar o diagnóstico
A justificativa do time do Chrome é que releases menores reduzem a chance de uma atualização concentrar mudanças demais e tornam mais simples investigar regressões depois do lançamento. A lógica faz sentido: quando menos alterações atravessam a porta de uma vez, fica mais fácil relacionar um bug a uma mudança específica.
Isso não elimina risco. Uma regressão pequena continua sendo grande para o produto que depende exatamente do comportamento afetado. O ganho potencial está na granularidade do ciclo, não em alguma promessa de navegador sem bugs. Para equipes web, o efeito prático depende de conseguir testar antes que a versão estável chegue aos usuários.
Colocar o Chrome Beta no CI fica mais útil
O próprio Google recomenda testar aplicações no canal Beta. Em um projeto com Playwright, dá para manter o navegador estável como referência e adicionar um projeto separado para o Beta. Assim, uma falha antecipada não bloqueia necessariamente todo deploy, mas aparece com contexto suficiente para a equipe investigar antes da promoção para Stable.
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{
name: 'chrome-stable',
use: {
...devices['Desktop Chrome'],
channel: 'chrome',
},
},
{
name: 'chrome-beta',
use: {
...devices['Desktop Chrome'],
channel: 'chrome-beta',
},
},
],
});O exemplo pressupõe que os canais correspondentes estejam instalados no ambiente de teste. A documentação do Playwright informa suporte aos canais oficiais chrome e chrome-beta, além dos canais Dev e Canary. Vale manter o Playwright atualizado, porque cada versão acompanha builds específicos dos navegadores.
Não é obrigatório duplicar toda a suíte. Uma abordagem razoável é rodar no Beta os fluxos críticos, como login, checkout, upload, reprodução de mídia e recursos que usam APIs recentes do navegador. Se o custo de CI permitir, a cobertura completa oferece mais segurança; se não permitir, priorizar os caminhos que derrubam receita ou operação já produz um sinal útil.
Mais Chrome não significa mais compatibilidade entre navegadores
Uma API chegar mais rápido ao Chrome Stable não faz com que ela apareça automaticamente no Firefox e no Safari. Esse detalhe fica ainda mais relevante quando a novidade parece pronta porque funciona no navegador usado pela maior parte da equipe.
Antes de adotar um recurso, vale consultar o status de interoperabilidade e definir qual é o nível de suporte do projeto. O Baseline ajuda nesse ponto ao classificar recursos como de disponibilidade limitada, recém-disponíveis em todos os navegadores principais ou amplamente disponíveis. Feature detection, fallback e progressive enhancement continuam sendo ferramentas melhores do que inferir capacidade pelo número da versão ou pelo user agent.
E quem depende de um ciclo mais lento?
O canal Extended Stable continuará com o ciclo de oito semanas. Ele existe principalmente para administradores corporativos e projetos que incorporam o Chromium e precisam de mais tempo para validar atualizações. A mudança para duas semanas também não significa que todos os usuários receberão uma nova versão no mesmo minuto: o Chrome usa distribuição gradual e pode interromper o rollout quando encontra problemas.
Para aplicações públicas, porém, contar apenas com um ambiente corporativo controlado pode esconder a velocidade com que o Stable comum muda. Monitorar erros de JavaScript, falhas em testes sintéticos e variações nas métricas de negócio por versão do navegador ajuda a distinguir uma regressão do produto de uma mudança externa.
O ajuste que vale fazer antes de setembro
Equipes que já atualizam dependências de teste, acompanham o Beta e evitam depender de comportamento não padronizado provavelmente sentirão pouca diferença. Para as demais, o novo calendário é um bom motivo para revisar três pontos:
- quais fluxos críticos podem ser executados regularmente no Chrome Beta;
- como erros e métricas são segmentados por versão do navegador;
- quais recursos recentes dependem apenas do Chrome e quais já têm suporte interoperável.
O intervalo menor não pede uma operação completamente nova. Pede feedback mais cedo e menos confiança naquele teste manual feito meses atrás em um navegador que já ganhou vários milestones desde então. O Chrome vai acelerar; a parte saudável é fazer o sinal de compatibilidade chegar antes do bug ao usuário.