Em 30 segundos
A Google confirmou: vamos ter Chrome a cada duas semanas. A partir do Chrome 153, que chega ao público em 8 de setembro de 2026, sai uma versão estável nova a cada 14 dias, e não mais a cada 28. Vale para computador, Android e iPhone. O canal Extended Stable, que empresas usam para atualizar mais devagar, continua no ritmo de oito semanas.
Eu comecei a ler esse anúncio achando que era assunto de quem trabalha com infraestrutura de navegador, aquele tipo de nota técnica que a gente arquiva e nunca mais abre. Aí caiu a ficha de que essa é a peça de software que abre o meu site, o seu site e o site de todo mundo — e que ela vai passar a mudar duas vezes mais rápido.
Não é uma mudança de recurso, é uma mudança de ritmo. E ritmo é uma daquelas coisas que parecem detalhe até virarem o motivo de alguma coisa quebrar numa terça-feira.
Chrome a cada duas semanas: o que a Google anunciou
O anúncio está no blog do Chrome for Developers, assinado por Ben Mason, gerente do time de releases do Chrome, e por Deepak Ravichandran, engenheiro da Google. O texto é direto: o ciclo de quatro semanas do canal estável vira um ciclo de duas semanas, começando pelo Chrome 153, em 8 de setembro.
Vale explicar o que é "canal", porque a palavra aparece o tempo todo nessas notas. O Chrome não é distribuído em uma versão só: existe o Canary (versão diária, instável, para quem gosta de perigo), o Dev, o Beta (quase pronta) e o Stable, que é a que chega automaticamente no computador da sua mãe. É só esse último que muda de ritmo. Dev e Canary continuam exatamente como estavam.
A justificativa da dupla é que entregas menores incomodam menos: embora as versões sejam mais frequentes, o escopo menor minimiza a interrupção e simplifica a depuração pós-lançamento
, escreveram, dizendo estar confiantes de que o padrão de estabilidade se mantém.
Eu entendo o argumento e até acho que ele faz sentido — é mais fácil descobrir o que quebrou quando entraram vinte mudanças do que quando entraram quarenta. Mas ele resolve o problema da Google, não necessariamente o de quem está do outro lado, recebendo essas versões.
De 28 para 14 dias entre uma versão e a próxima
O número que ficou na minha cabeça é esse: 14 dias. É o intervalo entre uma versão estável e a seguinte a partir de setembro. Antes eram 28.
Parece pouco dito assim, mas experimente traduzir para o calendário de uma equipe pequena. Uma empresa que reservava um dia por mês para conferir se o site continua se comportando bem no navegador novo agora tem esse compromisso caindo duas vezes por mês. Quem não reservava nada — que, sejamos honestos, é a maioria — passa a ter o dobro de oportunidades de descobrir um problema pelo caminho mais caro, que é o cliente reclamando.
O Extended Stable é a válvula de escape que a Google manteve: oito semanas entre atualizações, pensado para empresas com departamento de TI e política de homologação. Curiosamente, o próprio anúncio recomenda o canal de duas semanas como a opção mais segura, porque correções de falhas chegam antes. É uma escolha entre receber remendo rápido e ter tempo para testar, e a Google está sugerindo o primeiro.
Para dimensionar o alcance disso no Brasil, olhei os dados do Statcounter: em agosto de 2026, o Chrome respondia por 79,95% dos acessos no país, somando celular e computador. Não existe "meus usuários usam outro navegador". Eles usam esse.
A janela de teste que sobra — e o que ainda não ficou claro
A parte mais prática do anúncio é o cronograma do Chrome 153, e ele responde a pergunta que eu faria primeiro: sobra quanto tempo para testar? O código da versão foi congelado em 17 de agosto, o beta saiu em 19 de agosto, o corte final do estável foi em 25 de agosto e a versão chega ao público em 8 de setembro.
Ou seja: entre poder instalar o beta e ele virar o navegador de todo mundo, existem cerca de três semanas. A recomendação da Google é usar exatamente essa janela — testar seu site no beta antes que a versão vire padrão.
É um conselho razoável, e é aqui que eu fico com uma dúvida honesta. Testar no beta pressupõe alguém com tempo, com o navegador beta instalado e com uma lista do que conferir. Quem tem um e-commerce de dez pessoas não tem esse alguém. A Google diz o que fazer, mas não diz como uma equipe pequena encaixa isso a cada duas semanas — e, sinceramente, essa parte não é obrigação da Google resolver.
Outra coisa que o anúncio não detalha é o efeito acumulado. Vinte mudanças por versão vezes duas versões por mês continua dando quarenta mudanças por mês. O escopo de cada entrega diminui, o total não. O que muda é que, quando algo der errado, a lista de suspeitos é menor. Isso é bom para depurar e indiferente para a chance de acontecer.
Por que isso importa para quem tem um site no ar
Quando um navegador muda, ele raramente derruba um site inteiro. O estrago típico é bem mais discreto: um botão que parou de responder no celular, um campo de endereço que não aceita mais o formato antigo, um script de pagamento que passou a demorar três segundos a mais para carregar. Nada disso gera um aviso. Gera desistência.
E esse é o ponto que me parece mais concreto para uma empresa brasileira de porte médio que vende ou capta pelo site. Ninguém liga para avisar que o formulário de orçamento parou de enviar no Chrome novo. A pessoa tenta, não funciona, fecha a aba e procura o concorrente. O sinal que sobra é uma queda no número de pedidos que só aparece no fim do mês, quando alguém compara com o mês anterior e acha que "as vendas caíram um pouco".
Com uma versão nova a cada duas semanas, a distância entre "o navegador mudou" e "eu descobri que algo quebrou" vira o problema real. Não dá para testar tudo antes, e a maioria das empresas não vai testar mesmo. O que dá para fazer é encurtar o tempo de descoberta: acompanhar os erros que acontecem no navegador de quem está usando o site de verdade, e saber em que tela a pessoa travou. É esse tipo de coleta que a gente faz no Nav Analytics, e que eu passei a olhar com outros olhos depois de ler esse anúncio.
Se você quiser um ponto de partida antes disso, vale acompanhar também os sinais de desempenho que o próprio Google usa como régua — eu escrevi sobre o que mudou nos Core Web Vitals em 2026 há pouco tempo, e as duas coisas conversam: uma versão nova do navegador pode mexer no tempo de resposta das suas telas sem que ninguém tenha tocado no seu código.
Não é uma notícia sobre navegador, é uma notícia sobre calendário. A partir de 8 de setembro, o chão em que o seu site roda passa a se mover duas vezes mais rápido — e quem só descobre problema por reclamação vai descobrir com o dobro da frequência.
Fontes
- Get features faster with Chrome's two-week release cycle — Chrome for Developers
- Google speeds up Chrome updates with new security-focused release cycle — Help Net Security
- Chrome Browser: Moving to a 2-Week Release Cycle — Android Enterprise Community
- Browser Market Share Brazil — Statcounter Global Stats