Firefox deja el ciclo mensual: cómo cambia tu estrategia de compatibilidad en septiembre

Firefox 154, que se publica el 18 de agosto de 2026, es el último lanzamiento mensual del navegador: Mozilla pasa a un ciclo quincenal a partir de Firefox 155 (1 de septiembre de 2026), siguiendo el mismo movimiento que Chrome anunció en marzo y que Edge aplicará con la versión 152 a finales de agosto. La consecuencia práctica para equipos web es directa: los números de versión dejan de ser una señal útil de compatibilidad, y quien siga manteniendo matrices de testing basadas en "últimas tres versiones" va a gastar recursos persiguiendo un objetivo que se mueve cada quince días. En este artículo te explico qué cambió, por qué Baseline e Interop 2026 son ahora tu mejor herramienta de compatibilidad, y el framework de tres capas que usamos en Mintec para probar sitios en producción con este nuevo ritmo.

Qué está pasando exactamente: el fin del ciclo mensual

El 14 de julio de 2026, el director de Mozilla, Sylvestre Ledru, confirmó que Firefox abandonaba su ciclo tradicional de cuatro semanas. Los hechos concretos, según el calendario oficial de lanzamientos:

• Firefox 154 — 18 de agosto de 2026. Última versión con ciclo mensual.
• Firefox 155 — 1 de septiembre de 2026. Primera versión quincenal.
• A partir de ahí, una versión estable cada dos semanas, en desktop y Android.
• Mozilla lo enmarca como experimento: si la calidad o la estabilidad se resienten, pueden volver atrás.
• El canal ESR (Extended Support Release) se mantiene para entornos empresariales y regulados, con su propio ritmo de seguridad.

Firefox no es el primero. Chrome anunció su ciclo de dos semanas en marzo de 2026, y Microsoft Edge hará la transición con Edge 152 el 27 de agosto de 2026. O sea: en septiembre, los tres motores principales — Blink (Chrome/Edge) y Gecko (Firefox) — publican versiones estables cada catorce días. Safari sigue con su calendario propio, que en la práctica es anual con parches frecuentes.

¿Por qué importa esto si los usuarios reciben las actualizaciones en segundo plano? Porque el ritmo de publicación de los navegadores define el ritmo al que cambia la plataforma web que tú tienes que soportar: APIs nuevas, cambios de comportamiento, deprecaciones. Cuando un navegador publica 26 veces al año, "soportamos hasta Firefox 160" deja de ser una frase con significado.

Por qué los números de versión dejaron de ser una señal de compatibilidad

Durante años, el estándar de facto en agencias y equipos internos fue la matriz de versiones: "soportamos las últimas dos versiones de Chrome, Firefox, Safari y Edge". Ese enfoque funcionaba cuando cada navegador publicaba cada 4-8 semanas y el número de versión viajaba junto con un conjunto acotado de cambios.

Con ciclos de dos semanas, el número de versión se convierte en un indicador ruidoso: entre Firefox 154 y Firefox 155 solo hay catorce días de diferencia, y lo que importa no es "155" sino qué cambió en esa ventana. Además, los lanzamientos frecuentes aceleran el momento en que una API nueva llega a los tres motores — que es exactamente lo que busca el trabajo de interoperabilidad de los últimos años.

En 2026 esa convergencia ya es visible en dos iniciativas que deberías tener en tu radar:

• Baseline (web.dev): define cuándo una característica está disponible en todos los motores principales (Chrome, Edge, Firefox, Safari) y la marca como "Nuevamente disponible" o "Ampliamente disponible". Es el estándar de facto para decidir cuándo puedes usar una API sin polyfill. Un ejemplo reciente: la Navigation API alcanzó el estado Baseline Newly Available en 2026 con soporte en Chrome, Edge, Firefox 147 y Safari 26.2, consolidándose como el reemplazo moderno de la History API.
• Interop 2026: el proyecto conjunto de los equipos de navegadores para resolver las diferencias de comportamiento en áreas específicas — veinte áreas de foco este año, incluyendo el atributo closedby de <dialog>, la Popover API y la evolución de CSS Anchor Positioning. Cada área resuelta es una línea menos en tu lista de "workarounds por navegador".

La combinación de ambas con los ciclos quincenales produce una conclusión incómoda pero liberadora: deja de perseguir versiones, persigue características.

El framework de tres capas que usamos en Mintec

Cuando montamos sitios para clientes con tráfico real — sitios de comercio, portales de contenido bilingüe, aplicaciones con video pesado — la compatibilidad no se resuelve con una tabla estática. Usamos tres capas, en este orden:

La regla práctica es simple: si una API está en Baseline, la usamos sin polyfill y la cubrimos con una prueba por motor. Si no está en Baseline, la tratamos como progresiva: feature detection primero, y la versión completa solo cuando el usuario la soporta. Los números de versión solo aparecen en la capa 3, como entrada para decidir cuándo una característica promueve a soporte total.

Esto no es teoría: lo aplicamos en proyectos reales. En la migración de sitios a Astro + Cloudflare usamos detección de características para decidir qué islands cargan JavaScript en cada dispositivo; para CSS Anchor Positioning montamos @supports (anchor-name: --x) como puerta de entrada y dejamos que los navegadores sin soporte caigan al layout clásico; y con la View Transitions API definimos la transición como un enhancement que nunca bloquea el contenido. En ninguno de esos casos la decisión dependió de "¿qué versión tiene el usuario?" sino de "¿soporta la característica?".

Checklist para adaptarte al ciclo quincenal

Si tu equipo todavía vive de una matriz de versiones, este es el orden de trabajo que recomendamos:

1. Audita tu matriz actual. Si dice "últimas 3 versiones", ya está rota: en septiembre eso son seis semanas de historia por navegador. Reescríbela como "motores soportados: Blink, Gecko, WebKit, con pruebas por motor".
2. Convierte tus polyfills en deuda visible. Revisa qué APIs usas con polyfill y compáralas contra el estado de Baseline. Cada polyfill que puedas eliminar es menos JavaScript, menos mantenimiento y mejor Core Web Vitals.
3. Automatiza el testing cross-browser. Si tu pipeline de CI no corre pruebas en los tres motores, el ciclo quincenal va a convertir cada release del navegador en una lotería. Playwright con tres proyectos — chromium, firefox, webkit — es el mínimo viable.
4. Suscríbete a la señal correcta. Los release notes de Firefox, el blog de web.dev y el rastreador de Baseline te dicen qué cambió de verdad cada dos semanas, sin ruido de números de versión.
5. Protege a los clientes que no pueden moverse rápido. Para entornos regulados o empresariales, ESR sigue existiendo: ofrécelo como opción consciente, no como accidente.

Y una advertencia: el ciclo quincenal también acelera las deprecaciones. Lo que hoy funciona en Firefox 154 puede emitir warnings en 155 y desaparecer en 157. Por eso la capa 3 del framework no es opcional — sin alerta de cambios de plataforma, tu sitio se rompe en silencio y te enteras por un cliente, no por tu CI.

Lo que viene

Septiembre de 2026 es el punto de inflexión: tres motores publicando cada dos semanas, un estándar de compatibilidad maduro (Baseline) y un programa de interoperabilidad activo (Interop 2026). Para los equipos que entiendan el cambio, esto es una oportunidad: menos deuda de polyfills, menos workarounds por navegador y una plataforma web más uniforme. Para los que sigan pegados a la matriz de versiones, es una carrera de gastos que no se puede ganar.

En Mintec ya construimos así: pensando en capacidades, no en versiones. Si tu sitio arrastra una matriz de compatibilidad manual o dudas si tu stack soporta el nuevo ritmo, podemos auditar tu estrategia de navegadores y dejarte un plan de testing que no dependa de un número que cambia cada catorce días.