O calendário de lançamentos dos browsers mudou esta semana, e mudou para todos ao mesmo tempo. A Mozilla lançou o Firefox 155 a 1 de setembro, duas semanas antes da data original de 15 de setembro, como primeira versão de uma nova cadência de duas semanas. A Google promoveu o Chrome 154 ao canal Beta a 2 de setembro, ao abrigo do seu próprio novo calendário, e o Chrome 153 Stable chega a 8 de setembro. A Microsoft foi a primeira: o Edge 152, a 27 de agosto, foi o seu primeiro lançamento Stable de duas semanas.

Desde 2021, os três browsers que transportam a maior parte do tráfego web mundial lançavam, cada um, uma versão principal aproximadamente de quatro em quatro semanas. A partir deste mês, esse intervalo reduz-se para metade.

Quem anunciou o quê, e quando

Nada disto chegou sem aviso, mas os três anúncios ficaram espalhados por seis meses, e é por isso que o efeito combinado tem passado facilmente despercebido.

A Google publicou o plano no Chrome for Developers blog a 3 de março. A partir do Chrome 153, sai um novo Beta e um novo Stable de duas em duas semanas em Desktop, Android e iOS. Os canais Dev e Canary não mudam. As atualizações de segurança semanais entre versões mantêm-se. O Extended Stable, o canal a que a maioria dos administradores empresariais fixa as suas frotas, continua num ciclo de oito semanas. A própria tabela do blog mostra quanto o calendário se deslocou: o Chrome 153 Stable estava previsto para 22 de setembro e sai agora a 8 de setembro; o Chrome 154 passa de 20 de outubro para 22 de setembro.

A Microsoft seguiu-se a 11 de junho. A partir do Edge 152, a 27 de agosto, o canal Stable passa a duas semanas, e a empresa foi explícita sobre o que isso significa em volume: cada versão Stable transporta cerca de metade das alterações da antiga versão mensal. O Extended Stable mantém o ritmo de oito semanas e passa a assentar em cada quarta versão, pelo que 156, 160 e 164 são os próximos marcos Extended Stable. O conselho da Microsoft às organizações é manter um grupo-piloto em Beta ou Enterprise Preview, para que os problemas apareçam antes de o Stable chegar à produção.

A Mozilla foi a última, e a mais cautelosa. Sylvestre Ledru, diretor de engenharia da Mozilla, escreveu em julho à lista dev-platform que a empresa estava “planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026”. Em português: a planear passar o Firefox Desktop e Android de uma cadência de lançamento de 4 semanas para uma cadência de 2 semanas a partir de setembro de 2026. O The Register noticiou a mudança a 17 de julho e assinalou que a Mozilla a descreve como uma experiência que pode vir a reverter. O Mozilla Support Blog confirmou as datas a 19 de agosto: Firefox 155 a 1 de setembro como primeira versão de duas semanas, com a ressalva explícita de que uma cadência mais rápida “doesn’t mean Firefox will ship twice as many features”. Em português: não significa que o Firefox vá lançar o dobro das funcionalidades. O Firefox ESR, a via anual de suporte prolongado, não é afetado; o The Register refere que o Firefox 153 será a próxima base ESR.

O que foi de facto lançado esta semana

O Firefox 155 é um bom teste para saber se a fórmula “metade das alterações, o dobro das vezes” se confirma. As notas de lançamento de 1 de setembro enumeram a expansão da Smart Window, assistida por IA, aos EUA, Canadá e França, um contador de rastreadores bloqueados na barra de endereço, a reordenação de contentores nas Definições, e correções para interrupções de áudio em segundo plano e para um antigo bug em Linux que impedia as máquinas de entrar em suspensão depois de uma sessão de navegação.

As alterações dirigidas a programadores, registadas no MDN, são a parte que toca os sites. A função CSS attr() funciona agora em qualquer propriedade, com valores tipados e alternativas de recurso, e não apenas em content. Duas novas funções CSS, progress() e alpha(), chegam juntamente com font-width como novo nome de font-stretch. O JavaScript ganha Promise.allKeyed() e Promise.allSettledKeyed(). As importações de módulos falhadas deixam de ficar em cache, pelo que um script que falhou numa rede instável pode ter sucesso numa nova tentativa. Do lado da rede, o Firefox 155 implementa a versão 3 do Happy Eyeballs para a corrida de ligações IPv6 e IPv4 e negoceia a versão 2 do QUIC para HTTP/3.

Não é dramático, e é precisamente essa a questão. A justificação declarada da Google é que “the smaller scope of these releases minimizes disruption and simplifies post-release debugging”. Em português: o âmbito mais reduzido destes lançamentos minimiza perturbações e simplifica a depuração pós-lançamento. E o Firefox 155 parece exatamente esse tipo de versão: um punhado de adições à plataforma, um punhado de correções, tudo pronto em duas semanas.

Porque é que os três mudaram na mesma época

A Google e a Microsoft partilham o motor Chromium, pelo que, mudando o calendário do Chrome, o do Edge iria segui-lo. O raciocínio da Mozilla, segundo o The Register, foi mais caseiro: funcionalidades concluídas ficavam semanas à espera do comboio seguinte, e a série imprevisível de versões intercalares pelo meio era mais difícil de planear do que um ritmo quinzenal fixo.

O Chrome passou de lançamentos de seis semanas para quatro em 2021 e acrescentou atualizações de segurança semanais em 2023; duas semanas é o passo seguinte na mesma direção.

O que significa para o seu negócio

O seu site encontra agora um novo motor de browser aproximadamente de duas em duas semanas. Para a maioria dos sites isto é invisível, e assim deve continuar. Os fabricantes de browsers fazem testes de compatibilidade precisamente para que uma mudança de versão não parta páginas. Se o seu site depende de um comportamento específico de um fabricante, de um polyfill que deteta números de versão ou de um widget de terceiros envelhecido, a janela entre “uma alteração entra em Beta” e “uma alteração está à frente dos seus clientes” encolheu de cerca de quatro semanas para três.

O canal Beta é o sistema de alerta precoce, e é gratuito. O Chrome lança cada Beta três semanas antes do Stable correspondente. O conselho da Microsoft às empresas aplica-se igualmente a um site de marketing: mantenha uma máquina, ou um perfil de browser, em Beta e percorra o seu checkout, os seus formulários e o seu fluxo de reservas de duas em duas semanas. Sai mais barato do que saber de um botão de pagamento avariado por um cliente.

Procure um degrau nas suas análises, não uma tendência. Se uma atualização de browser parte alguma coisa, fá-lo numa data concreta. Segmente a taxa de conversão por browser e versão na sua ferramenta de análise e procure uma queda súbita que comece num dia de lançamento e afete apenas um browser. Esse padrão é a impressão digital de um bug de compatibilidade.

Mantenha as suas próprias dependências atualizadas. Os sites que sofrem com ciclos rápidos de browser são normalmente os que correm uma framework JavaScript, um CMS ou um plugin vários anos atrasados. Os fabricantes dessas ferramentas testam contra browsers atuais, não contra o seu próprio produto de há vários anos. É este o ritmo de manutenção que incorporamos em cada site que entregamos: uma revisão de dependências em calendário fixo, e não quando algo se parte.

As frotas empresariais ficam em grande parte inalteradas, e isso importa se lhes vende. Tanto o Chrome como o Edge mantêm o Extended Stable a oito semanas, e o Firefox ESR continua anual. Se os seus clientes são utilizadores corporativos em dispositivos geridos, verão menos mudanças de motor do que o público em geral, e funcionalidades lançadas numa versão Stable de duas semanas podem demorar dois meses a chegar-lhes. Não construa uma landing page em torno de uma funcionalidade CSS acabada de sair para uma audiência que só a verá em novembro.

A nossa leitura é que isto são boas notícias para a web e um pouco mais de trabalho para quem mantém sites nela. Lançamentos mais pequenos e mais frequentes são mais fáceis de depurar e mais rápidos de corrigir. O custo é que o velho hábito de verificar a compatibilidade dos browsers “mais ou menos todos os meses” deixou de corresponder à realidade. Ponha um lembrete quinzenal no calendário; é essa a maior parte do trabalho.

← Todos os artigos