El calendario de lanzamientos de los navegadores cambió esta semana, y cambió para todos a la vez. Mozilla publicó Firefox 155 el 1 de septiembre, dos semanas antes de la fecha original del 15 de septiembre, como primera versión de una nueva cadencia de dos semanas. Google promovió Chrome 154 al canal Beta el 2 de septiembre según su propio calendario nuevo, y Chrome 153 Stable llega el 8 de septiembre. Microsoft fue el primero: Edge 152, el 27 de agosto, fue su primera versión Stable de dos semanas.
Desde 2021, los tres navegadores por los que pasa la mayor parte del tráfico web mundial publicaban cada uno una versión principal aproximadamente cada cuatro semanas. A partir de este mes, ese intervalo se reduce a la mitad.
Quién anunció qué, y cuándo
Nada de esto llegó sin aviso, pero los tres anuncios se repartieron a lo largo de seis meses, y por eso el efecto conjunto ha sido fácil de pasar por alto.
Google publicó el plan en el Chrome for Developers blog el 3 de marzo. A partir de Chrome 153, cada dos semanas salen una nueva Beta y una nueva Stable en Desktop, Android e iOS. Los canales Dev y Canary no cambian. Las actualizaciones de seguridad semanales entre hitos continúan. Extended Stable, el canal al que la mayoría de los administradores de empresa fijan sus equipos, se mantiene en un ciclo de ocho semanas. La propia tabla del blog muestra cuánto se movió el calendario: Chrome 153 Stable estaba previsto para el 22 de septiembre y ahora sale el 8 de septiembre; Chrome 154 pasa del 20 de octubre al 22 de septiembre.
Microsoft siguió el 11 de junio. Desde Edge 152, el 27 de agosto, el canal Stable pasa a dos semanas, y la compañía fue explícita sobre lo que eso significa en volumen: cada versión Stable lleva aproximadamente la mitad de los cambios de la antigua versión mensual. Extended Stable conserva su ritmo de ocho semanas y ahora recoge una de cada cuatro versiones, así que 156, 160 y 164 son los próximos hitos de Extended Stable. El consejo de Microsoft a las organizaciones es poner un grupo piloto en Beta o Enterprise Preview para que los problemas afloren antes de que Stable llegue a producción.
Mozilla fue la última, y la más cauta. Sylvestre Ledru, Director of Engineering de Mozilla, comunicó a la lista dev-platform en julio que la compañía estaba «planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.» En español: planeando pasar Firefox Desktop y Android de una cadencia de lanzamiento de cuatro semanas a una de dos semanas a partir de septiembre de 2026. The Register informó del cambio el 17 de julio y señaló que Mozilla lo describe como un experimento que podría revertir. El Mozilla Support Blog confirmó las fechas el 19 de agosto: Firefox 155 el 1 de septiembre como primera versión de dos semanas, con la advertencia explícita de que una cadencia más rápida «doesn’t mean Firefox will ship twice as many features.» En español: no significa que Firefox vaya a publicar el doble de funciones. Firefox ESR, la rama anual de soporte prolongado, no se ve afectada; The Register informa de que Firefox 153 es la próxima base de ESR.
Qué se publicó realmente esta semana
Firefox 155 es una buena prueba de si «la mitad de los cambios, el doble de veces» se cumple. Sus notas de la versión del 1 de septiembre recogen la ampliación de Smart Window, asistido por IA, a Estados Unidos, Canadá y Francia, un contador de rastreadores bloqueados en la barra de direcciones, la reordenación de contenedores en Ajustes y correcciones para las interrupciones del audio en segundo plano y para un viejo fallo de Linux que impedía a los equipos entrar en suspensión tras una sesión de navegación.
Los cambios para desarrolladores registrados en MDN son la parte que afecta a los sitios web. La función CSS attr() funciona ahora en cualquier propiedad con valores tipados y alternativas de reserva, no solo en content. Dos nuevas funciones CSS, progress() y alpha(), llegan junto con font-width como nuevo nombre de font-stretch. JavaScript gana Promise.allKeyed() y Promise.allSettledKeyed(). Las importaciones de módulos fallidas ya no se guardan en caché, de modo que un script que falló en una red inestable puede funcionar al reintentarlo. En el lado de la red, Firefox 155 implementa Happy Eyeballs versión 3 para la carrera de conexiones IPv6 e IPv4 y negocia QUIC versión 2 para HTTP/3.
No es nada espectacular, y esa es la cuestión. La justificación declarada de Google es que «the smaller scope of these releases minimizes disruption and simplifies post-release debugging.» En español: el menor alcance de estas versiones minimiza las interrupciones y simplifica la depuración posterior al lanzamiento. Firefox 155 parece exactamente ese tipo de versión: un puñado de novedades de plataforma, un puñado de correcciones, publicadas en dos semanas.
Por qué los tres se movieron en la misma temporada
Google y Microsoft comparten el motor Chromium, así que, una vez cambiado el calendario de Chrome, el de Edge iba a seguirlo. El razonamiento de Mozilla, según informa The Register, era más doméstico: había funciones terminadas esperando semanas al siguiente tren, y una serie impredecible de versiones menores entre medias era más difícil de planificar que un ritmo fijo de dos semanas.
Chrome pasó de versiones cada seis semanas a cada cuatro en 2021 y añadió actualizaciones de seguridad semanales en 2023; dos semanas es el siguiente paso en la misma dirección.
Qué significa para tu negocio
Tu sitio se encuentra ahora con un motor de navegador nuevo aproximadamente cada dos semanas. Para la mayoría de los sitios esto es invisible, y así debería seguir. Los fabricantes de navegadores hacen pruebas de compatibilidad precisamente para que un salto de versión no rompa páginas. Si tu sitio depende de un comportamiento concreto de un fabricante, de un polyfill que lee números de versión o de un widget de terceros envejecido, la ventana entre «un cambio llega a Beta» y «un cambio está delante de tus clientes» se ha reducido de unas cuatro semanas a tres.
El canal Beta es el sistema de alerta temprana, y es gratis. Chrome publica cada Beta tres semanas antes de la Stable correspondiente. El consejo de Microsoft a las empresas vale igual para un sitio de marketing: mantén una máquina, o un perfil del navegador, en Beta y recorre tu proceso de pago, tus formularios y tu flujo de reservas una vez cada dos semanas. Sale más barato que enterarte por un cliente de que el botón de pago no funciona.
Busca en tus analíticas un escalón, no una tendencia. Si una actualización del navegador rompe algo, lo hace en una fecha concreta. Segmenta la tasa de conversión por navegador y versión en tu herramienta de analítica y busca una caída repentina que empiece un día de lanzamiento y afecte a un solo navegador. Ese patrón es la huella de un fallo de compatibilidad.
Mantén al día tus propias dependencias. Los sitios que sufren con los ciclos rápidos de los navegadores suelen ser los que funcionan con un framework de JavaScript, un CMS o un plugin con varios años de retraso. Los fabricantes de esas herramientas prueban contra navegadores actuales, no contra su propio producto de hace varios años. Ese es el ritmo de mantenimiento que incorporamos a cada sitio web que entregamos: una revisión de dependencias con calendario fijo, no cuando algo se rompe.
Los parques de empresa apenas se ven afectados, y eso importa si les vendes. Tanto Chrome como Edge mantienen Extended Stable en ocho semanas, y Firefox ESR sigue siendo anual. Si tus clientes son usuarios corporativos en dispositivos gestionados, verán menos cambios de motor que el público general, y las funciones que salen en una versión Stable de dos semanas pueden tardar dos meses en llegarles. No construyas una landing page en torno a una función CSS recién estrenada para un público que no la verá hasta noviembre.
Nuestra lectura es que esto es una buena noticia para la web y algo más de trabajo para quienes mantienen sitios en ella. Las versiones más pequeñas y frecuentes son más fáciles de depurar y más rápidas de corregir. El coste es que la vieja costumbre de comprobar la compatibilidad de navegadores «más o menos una vez al mes» ya no se corresponde con la realidad. Pon un recordatorio quincenal en el calendario; eso es la mayor parte del trabajo.
