El ciclo de lanzamiento de dos semanas de Chrome comienza con la versión estable Chrome 153 el 8 de septiembre de 2026, lo que reduce el intervalo entre lanzamientos principales de cuatro a dos semanas. Para los usuarios, el cambio debería pasar más desapercibido: versiones más pequeñas, menos lanzamientos masivos. Para los equipos web, esto supone el doble de versiones «estables» y «beta» que probar, mientras que las actualizaciones de seguridad semanales continúan por separado.
Ciclo de lanzamiento de Chrome cada dos semanas: qué cambios está introduciendo Google
Google El 3 de marzo de 2026 se anunció que Chrome Stable y Chrome Beta pasarían de un ciclo de lanzamiento de cuatro semanas a uno de dos semanas a partir de septiembre de 2026. Chrome 153 es el punto de partida para la versión Stable en ordenador, Androide y iOS, y está previsto que Chrome 154 se lance el 22 de septiembre de 2026.
Las versiones Dev y Canary no han sufrido cambios. Esto es importante porque muchos equipos de ingeniería ya consideran a Canary como un canal de alerta temprana con muchas interferencias y a Dev como una señal preliminar más aproximada previa a la versión Beta; el impacto operativo se concentra principalmente en las versiones Stable y Beta, donde los responsables de producto, los jefes de control de calidad y los administradores de empresa suelen tomar las decisiones de seguir adelante o no.
Chrome ya se había acelerado una vez anteriormente. En 2021, Google pasó a establecer los hitos de la versión estable en un ciclo de cuatro semanas. El cambio previsto para 2026 reduce ese plazo a la mitad de nuevo, por lo que el número de versión principal del navegador avanzará aproximadamente el doble de veces que lo hacía con el modelo de cuatro semanas.
La intención de búsqueda en este caso es principalmente informativa, aunque con un toque práctico: quieres saber qué cambios se van a producir, si afectan a tu página web o a tu organización, y qué debes ajustar antes de que lleguen esas fechas. La respuesta breve es sencilla. Si lanzas, pruebas, proteges o gestionas software que se ejecuta en Chrome, tu calendario de lanzamientos se ha vuelto más ajustado.
Lo que no cambia: las actualizaciones de seguridad siguen teniendo su propio canal
Un error habitual es confundir las fases de desarrollo de Chrome con la frecuencia de los parches de seguridad. No lo hagas. Google introdujo en 2023 las actualizaciones de seguridad semanales para la versión estable con el fin de reducir el lapso de tiempo entre las correcciones públicas y la protección de los usuarios, y el ciclo de lanzamiento quincenal de Chrome es independiente de ese modelo de actualizaciones de seguridad semanales.
En agosto de 2026, el blog de seguridad de Google indicó que Chrome se encontraba «en proceso de transición» hacia versiones principales cada dos semanas, al tiempo que se mantenían las actualizaciones de seguridad semanales. También señaló que Google estaba llevando a cabo una prueba piloto con dos lanzamientos de seguridad por semana. Esa prueba piloto es relevante para los equipos de seguridad, pero no es lo mismo que las versiones principales del navegador cada dos semanas.
En el ámbito de las TI empresariales, esta distinción influye en las conversaciones sobre riesgos. Una actualización de seguridad puede incluirse dentro de un mismo hito, mientras que una actualización de hito puede conllevar cambios en el comportamiento de la plataforma, cambios en la API del navegador, cambios en el comportamiento del diseño y funciones en desuso. Tu política de parches y tu política de pruebas de compatibilidad no deberían ser el mismo documento con diferentes títulos.
Si tu organización ya se está replanteando el refuerzo de la seguridad de los navegadores, la gestión de identidades y los procesos de aplicación de parches, la misma lógica se aplica a toda la infraestructura; la velocidad de los navegadores es una razón más por la que Los servicios en la nube y la planificación de la seguridad deben avanzar de forma conjunta, y no en reuniones trimestrales independientes.
El cambio de calendario en la práctica para los equipos de control de calidad
Estos son los cálculos concretos. Con el modelo de cuatro semanas, un equipo que realizara un seguimiento de todos los hitos de la versión «Stable» se enfrentaba a unos 13 hitos importantes de Chrome al año. En un modelo de dos semanas, esa cifra asciende a unas 26. Si superar la prueba de funcionamiento requiere 6 horas de trabajo de ingeniero por hito, el coste anual pasa de unas 78 horas a 156 horas, a menos que se automatice el proceso, se reduzca el alcance o se acepten más riesgos.
Esa cifra es cruda, pero útil. No incluye las compilaciones fallidas, las reuniones de clasificación de incidencias, los retrasos en la aprobación por parte del cliente ni ese molesto error del viernes por la tarde que solo aparece en un WebView en Android. Los equipos de verdad perciben el ritmo en la fragmentación del calendario, no solo en horas.
Chrome for Testing resulta de gran ayuda. El 2 de septiembre de 2026, su página de disponibilidad incluía las versiones Estable 152.0.7977.75, Beta 153.0.8010.12, Dev 154.0.8025.0 y Canary 155.0.8038.0, lo que proporcionaba a los equipos de control de calidad binarios con versiones fijas en todos los canales. Esto resulta muy valioso para Selenium, Playwright y los procesos de integración continua (CI), ya que reduce la incertidumbre de que «a mí me funciona en mi Chrome».
| Artículo | Ciclo de cuatro semanas | Ciclo de dos semanas en 2026 | Por qué es importante |
|---|---|---|---|
| Hitos estables por año | Alrededor de 13 | Alrededor de 26 | Las decisiones de regresión se producen con el doble de frecuencia |
| Ejemplo de la primera versión estable | La era de Chrome 152 antes de la transición | Chrome 153, el 8 de septiembre de 2026 | Marca el momento de la transición operativa |
| Próximo hito previsto para la versión «Stable» | Aproximadamente cuatro semanas después | Chrome 154, el 22 de septiembre de 2026 | Muestra de inmediato el nuevo ritmo de dos semanas |
| Opción más lenta de Enterprise | Versión «Extended Stable» disponible | Un nuevo hito cada 8 semanas | Útil para las organizaciones que no pueden seguir el ritmo |
El escollo del que nadie quiere hablar: «probamos Chrome» suele significar «probamos la versión a la que Chrome se haya actualizado automáticamente en el portátil del departamento de control de calidad». Eso ya era un descuido antes. Con el ciclo de lanzamiento de dos semanas de Chrome, se convierte en una verdadera fuente de falsa confianza, ya que las versiones Beta y Estable, así como los equipos de los usuarios, pueden divergir más rápidamente.
Cómo adaptar las pruebas en el navegador sin duplicar la plantilla
No es necesario comprobarlo todo el doble de veces con la misma lista de comprobación manual. Sinceramente, ese es el camino más rápido hacia un equipo de control de calidad agotado y hacia defectos que siguen sin detectarse. Lo mejor es dividir las pruebas según el riesgo: las comprobaciones relacionadas con el navegador se realizan en cada hito, mientras que el contenido de bajo riesgo y los flujos del CMS se mantienen en un calendario más razonable.
- Fijar las versiones del navegador en CI. Utiliza Chrome para realizar las pruebas en lugar de recurrir al navegador instalado en el ordenador.
- Seguimiento: «Stable», «Beta» y una señal temprana. Para la mayoría de los equipos, «Stable» más «Beta» es lo mínimo; «Dev» permite detectar problemas antes si tu producto tiene un gran peso en el front-end.
- Clasifica las pruebas según el riesgo del navegador. El diseño, el desplazamiento, la autenticación, los pagos, la subida de archivos, los contenidos multimedia, las extensiones y las API web merecen ser prioritarios.
- Reserva una franja horaria de dos semanas para la clasificación de pacientes. Es mejor hacer un repaso periódico de 30 minutos que llevarse una sorpresa cada mes.
- Notifica únicamente los errores reproducibles y específicos de una versión. Anota la versión exacta de Chrome, el sistema operativo y el tipo de dispositivo antes de dedicar tiempo a su desarrollo.
Los equipos de front-end deben prestar especial atención al comportamiento de la representación. La versión beta de Chrome 153, lanzada el 20 de agosto de 2026 para Windows, Mac y Linux, incluía cambios en la plataforma web, como los contenedores de desplazamiento de un solo eje, un detalle que puede resultar importante para las pruebas de regresión de maquetación en los sitios web de los clientes.
Las aplicaciones renderizadas en el servidor no son una excepción. Si tu aplicación depende de los tiempos de hidratación, los puntos de ruptura adaptativos, el posicionamiento fijo, las redirecciones de pago o los scripts de análisis del lado del cliente, una cadencia más rápida del navegador puede poner de manifiesto supuestos poco sólidos. El renovado interés en Renderización del lado del servidor en los marcos de trabajo de 2026 hace que la cobertura de regresión del navegador sea más relevante, y no menos, ya que el usuario sigue completando la experiencia en un navegador real.
La dotación de personal es la cuestión más complicada. En 2026, escasas son las directrices oficiales de Google específicas sobre la expansión de la matriz de Selenium o Playwright, los presupuestos para pruebas de regresión de las extensiones y el impacto en la dotación de personal de control de calidad en las instalaciones del cliente. La base verificable es la duplicación de la frecuencia de los hitos de las versiones Estable y Beta, más la versión Estable Extendida como opción empresarial más lenta; todo lo demás es una decisión de la dirección de ingeniería.
Qué significa esto para las extensiones y los sitios web de los clientes
Los desarrolladores de extensiones se enfrentan a un ciclo de actualizaciones más riguroso. La documentación de las extensiones de Chrome publicó las novedades de Chrome 153 el 3 de agosto de 2026, entre las que se incluye la nueva browser.publicSuffix API. Una nueva API es una buena noticia si puedes utilizarla, pero también implica que los equipos de desarrollo de extensiones deben decidir cuándo adoptarla, crear un polyfill o esperar.
Los sitios web de los clientes se enfrentan a un riesgo diferente. La mayoría no dejará de funcionar porque Chrome haya cambiado el ritmo de sus versiones. Dejan de funcionar porque nadie se hace responsable de ese pequeño matiz que hay entre «el sitio supera nuestras pruebas» y «los clientes del cliente utilizan navegadores que se actualizan automáticamente en dispositivos reales».
Una agencia pequeña o un equipo interno pueden gestionar el ciclo de lanzamiento de dos semanas de Chrome si se muestran disciplinados. Sin embargo, un conjunto extenso de micrositios, gestores de etiquetas, widgets de pago, banners de cookies y scripts de terceros incrustados es otra historia. En ese punto, las pruebas en navegadores se convierten en una cuestión de gestión de la cartera.
Existe un paralelismo útil con el software empresarial a medida: la frecuencia de lanzamiento solo funciona cuando la titularidad está clara. Si ya te encargas del mantenimiento de herramientas internas, los mismos principios en los que se basa Crear un CRM que se adapte a los flujos de trabajo de tu empresa Aplicar al control de calidad del navegador: definir quién es el responsable del flujo de trabajo, del riesgo y de los criterios de aceptación.
Hay un contraargumento que merece ser tenido en cuenta. Las versiones más pequeñas de Chrome podrían reducir realmente las molestias. Google afirma que el ciclo de dos semanas tiene como objetivo lanzar versiones de menor alcance, lo que reduce las molestias y la depuración posterior al lanzamiento en comparación con los lotes más grandes de cuatro semanas. Lo acepto, hasta cierto punto; los lotes más pequeños son más fáciles de gestionar, pero solo si tu equipo está pendiente de cada lote.
Opción Enterprise: «Extended Stable» es la válvula de seguridad
La documentación de Chrome Enterprise indica que la versión «Extended Stable» está pensada para aquellas organizaciones que «no pueden adaptarse a un ciclo de lanzamiento de dos semanas». En 2026, la versión «Extended Stable» lanzará una nueva versión cada ocho semanas, y las correcciones de seguridad importantes se retroaplicarán durante seis semanas más.
Esa opción no es un pase libre para ignorar la compatibilidad. Lo que hace es ganar tiempo. Las empresas sujetas a normativa, los centros educativos, las redes sanitarias y los grandes centros de atención telefónica pueden preferir la versión «Extended Stable», ya que una regresión del navegador en miles de ordenadores gestionados resulta muy costosa y tiene un impacto muy visible.
La contrapartida es la velocidad. Recibes un flujo más lento de cambios en las versiones, aunque las correcciones de seguridad importantes se retroaplican durante un tiempo, pero no te encuentras exactamente en la misma situación que los usuarios de Chrome para consumidores. Si tu página web pública está dirigida a todo el mundo, limitarte a probar solo la versión «Extended Stable» sería un error.
En el caso de las organizaciones más grandes, el ciclo de lanzamiento de dos semanas de Chrome puede poner de manifiesto una falta de personal. Si un ingeniero de control de calidad se encargaba de manera informal de la certificación del navegador, además de otras cinco tareas, el doble de hitos hará que esa distribución de tareas parezca poco sólida. Algunos equipos lo resolverán con automatización; otros pueden necesitar ayuda externa, y el mercado de Ampliación de la plantilla de TI en 2026 existe, en parte, porque las operaciones de liberación son cada vez más rápidas.
Plan de acción previo al lanzamiento de la versión estable de Chrome 153
Chrome 153 entró en fase beta para ordenador el 20 de agosto de 2026, y la versión estable 153.0.8010.24 de Chrome para iOS se publicó el 1 de septiembre de 2026 con mejoras en la estabilidad y el rendimiento. Para el 8 de septiembre, los equipos que se preocupan por la compatibilidad ya deberían tener Chrome 153 en una línea de pruebas, sin esperar a que lleguen las quejas de los clientes.
Empieza por los procesos cuyo fallo pueda suponer un coste económico o un daño a la reputación. El proceso de pago, el inicio de sesión, el registro, los paneles de control, la publicación desde el panel de administración, la reproducción de vídeos, los mapas, las herramientas de consentimiento y la gestión de archivos merecen prioridad frente a las páginas informativas de menor importancia. Los ciclos de lanzamiento más cortos castigan los planes de pruebas poco concretos.
Utiliza la versión Beta como canal de alerta. En el ciclo de lanzamiento de dos semanas de Chrome, el valor de la versión Beta aumenta porque se reduce el tiempo que transcurre entre «lo hemos detectado» y «los usuarios ya lo tienen». Si esperas a la versión Estable para empezar a realizar pruebas, estás optando por reaccionar en lugar de prepararte.
Mi opinión desde el punto de vista práctico: la mayoría de los equipos web profesionales deberían incorporar a su ritual de sprint una revisión rápida de los hitos en Chrome. No se trata de una ceremonia, sino de una comprobación real: qué versión del navegador es la siguiente, qué ha cambiado, qué pruebas automatizadas se han ejecutado, qué flujos manuales aún requieren revisión manual y quién da el visto bueno si el cliente lo solicita.
Preguntas frecuentes
¿Cuándo empieza el ciclo de lanzamiento de dos semanas de Chrome?
Google ha anunciado que el punto de partida será la versión estable de Chrome 153, el 8 de septiembre de 2026, para ordenador, Android e iOS. Según el nuevo calendario, está previsto que Chrome 154 se lance el 22 de septiembre de 2026.
¿Sigue recibiendo Chrome actualizaciones de seguridad semanales?
Sí. Las actualizaciones de seguridad semanales de la versión estable, introducidas en 2023 para reducir el intervalo entre parches, continúan de forma independiente de la cadencia de dos semanas de las versiones principales.
¿También cambian los canales Dev y Canary de Chrome?
No. Según el comunicado de Google de 2026, los canales Dev y Canary no sufren cambios. El cambio en la periodicidad se aplica a las versiones Stable y Beta.
¿Deberían los equipos de Selenium y Playwright probar más versiones de Chrome?
Muchos deberían, como mínimo, fijar las versiones «Stable» y «Beta» en las pruebas automatizadas que utilicen Chrome for Testing. Las directrices oficiales sobre la ampliación de la matriz son limitadas, por lo que el alcance adecuado depende del riesgo del navegador de tu aplicación y de la tolerancia a las versiones.
¿Qué es Chrome Enterprise Extended Stable?
«Extended Stable» es el canal empresarial más lento, destinado a aquellas organizaciones que no pueden adaptarse a un ciclo de lanzamiento de dos semanas. En 2026, lanzará una nueva versión cada 8 semanas, y las correcciones de seguridad importantes se retroaplicarán durante 6 semanas más.
ES 
EN 
FR