Astro 7.3.1: qué cambia, benchmark real y guía de actualización

Astro 7.3.1 ya está disponible y conviene fijarse en el número completo: Astro publicó la versión 7.3.0 el 3 de septiembre de 2026 y, unas horas después, lanzó 7.3.1 para corregir un fallo que impedía iniciar o compilar proyectos que usan astro:assets. Si vas a actualizar hoy, la recomendación práctica es instalar 7.3.1 o una versión posterior, no quedarse en 7.3.0.

La actualización no cambia la forma de escribir una página Astro. Su valor está en el flujo de trabajo: mejora los builds de sitios con muchas páginas y muchos módulos, permite renderizado concurrente en los builds incrementales —también con el adaptador de Cloudflare—, facilita pruebas E2E con varias instancias de astro preview y corrige problemas concretos de caché, i18n y Server Islands.

Para comprobar si la mejora se nota fuera del changelog, en TERAMONT ejecutamos dos pruebas locales reproducibles. En nuestra carga sintética, Astro 7.3.1 redujo la mediana de un build limpio de 1,200 módulos de 4.55 a 3.31 segundos, un 27.3%. En un rebuild incremental sin cambios de 3,000 rutas con cacheKey, pasó de 1.62 a 0.85 segundos, un 47.5%. Son resultados de esta máquina y esta carga, no una promesa universal; más adelante explicamos exactamente cómo los medimos.

Astro 7.3.1 en pocas palabras

Qué cambia realmente frente a Astro 7.2

Astro 7.2 introdujo los builds estáticos incrementales como función experimental. La idea es sencilla: si una ruta prerenderizada conserva el mismo código y los mismos datos, Astro puede reutilizar el resultado anterior en vez de volver a generar el HTML. Esto es especialmente útil en sitios donde una colección produce miles de páginas pero una publicación sólo modifica unas pocas.

En 7.2 había una limitación importante: configurar build.concurrency por encima de 1 desactivaba la caché incremental. Era posible conservar la caché fijando la concurrencia en 1, pero se perdía paralelismo durante el renderizado. Astro 7.3 elimina ese intercambio: el build incremental admite renderizado concurrente y el equipo indica expresamente que el cambio incluye @astrojs/cloudflare.

Esto no significa que concurrency: 8 siempre sea mejor. El punto óptimo depende de núcleos disponibles, memoria, coste de cada ruta y límites del entorno de CI. La mejora es que ahora puedes medir y elegir sin renunciar automáticamente a la caché incremental.

Benchmark local: Astro 7.2.10 vs 7.3.1

Mediana de cinco ejecuciones por escenario. Un tiempo menor es mejor.

Metodología y límites de la prueba

• Hardware: Intel Core i5-13450HX, 10 núcleos y 16 hilos, con 30 GiB de RAM.

• Software: Ubuntu Linux, Node.js 22.18.0 y npm 10.9.3.

• Build limpio: 1,200 archivos .astro independientes, un componente compartido, build.concurrency: 8 y eliminación de dist y node_modules/.astro antes de cada medición.

• Build incremental: una ruta dinámica generó 3,000 páginas con un cacheKey estable. Después del build inicial se eliminó sólo dist, conservando la caché en node_modules/.astro.

• Muestra: cinco ejecuciones medidas con tiempo de pared y memoria máxima; la tabla usa la mediana para reducir el efecto de valores atípicos.

La carga es sintética: no incluye un CMS remoto, optimización masiva de imágenes ni plugins específicos. Por eso el porcentaje no debe extrapolarse directamente a otro proyecto. Lo que sí demuestra es que el cambio descrito por Astro aparece en un entorno controlado y repetible. En un sitio real conviene ejecutar el mismo commit con ambas versiones, limpiar o conservar la caché según el escenario y comparar medianas, no una sola ejecución.

Como contexto, el equipo de Astro publicó para Astro 7.0 mejoras de build del 15% al 61% en seis sitios reales de entre unas 308 y 13,275 páginas. Esas cifras miden el salto general a Astro 7 —Rust, Vite 8, Rolldown y el nuevo renderizado— y no deben atribuirse únicamente a 7.3. Nuestro benchmark anterior sí compara 7.2.10 y 7.3.1 de forma directa.

Cómo activar los builds incrementales

La función sigue marcada como experimental. Se activa en la configuración y cada ruta que quiera reutilizarse debe devolver una clave de caché. Astro combina esa clave de datos con un hash del grafo de módulos de la ruta; si cambia el contenido o el código que la produce, vuelve a renderizarla.

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  build: {
    concurrency: 8,
  },
  experimental: {
    incrementalBuild: true,
  },
});

En una Content Collection, entry.digest es una clave útil porque cambia cuando cambia la entrada:

// src/pages/blog/[slug].astro
import { getCollection, render } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');

  return posts.map((post) => ({
    params: { slug: post.id },
    props: { post },
    cacheKey: post.digest,
  }));
}

const { post } = Astro.props;
const { Content } = await render(post);

Una clave incorrecta puede servir HTML obsoleto. Incluye en ella todo dato externo que afecte la salida: versión del contenido, idioma, variante o fecha de actualización. Las rutas sin cacheKey se renderizan siempre, de modo que la adopción es explícita.

Qué mejora para Cloudflare

Astro 7.3 añade renderizado concurrente para experimental.incrementalBuild incluso al usar @astrojs/cloudflare. Además, el changelog menciona menos sobrecarga de serialización en páginas prerenderizadas grandes. En la práctica hay dos beneficios potenciales:

• un pipeline con varios núcleos puede renderizar más de una página a la vez sin apagar la caché incremental;

• las páginas grandes necesitan menos trabajo de serialización dentro de la integración de Cloudflare.

Si fijaste build.concurrency: 1 únicamente como solución temporal para conservar la caché en 7.2, Astro indica que ya puedes retirar ese workaround. Hazlo primero en una rama y mide memoria y duración total: aumentar concurrencia puede acelerar el build, pero también elevar el consumo instantáneo de RAM.

Pruebas E2E: varias previews sin pelear por el lock

La nueva opción --ignore-lock permite iniciar varias instancias de astro preview en puertos distintos. Resulta útil cuando Playwright u otro runner levanta entornos aislados en paralelo.

npm run build
npx astro preview --port 4321
npx astro preview --port 4322 --ignore-lock

El flag evita el bloqueo entre previews; no asigna los puertos por ti ni sustituye el aislamiento de datos. Cada proceso debe recibir un puerto libre y, si la aplicación usa servicios externos, variables o bases separadas cuando corresponda.

Caché HTTP y observabilidad: cambios pequeños que evitan problemas grandes

El proveedor memoryCache() ahora omite respuestas con Vary: Cookie o Vary: *. Es una corrección prudente: una respuesta cuyo contenido varía según cookies no debe reutilizarse indiscriminadamente entre usuarios, y Vary: * señala que no hay una clave de caché HTTP práctica para reproducir la selección.

Astro 7.3 también entrega el logger de runtime a los hooks de servicios de imágenes y al contexto de proveedores de caché. Los mensajes respetan el destino y nivel configurados, en lugar de escribir directamente en consola. Para equipos que envían logs a Loki, CloudWatch, Kibana o un colector propio, esto reduce mensajes fuera del pipeline.

Correcciones importantes de i18n y Server Islands

Dos arreglos merecen atención aunque no aparezcan en el titular:

• Rutas fallback de i18n: Astro podía reemplazar por error una segunda aparición del código de idioma. El ejemplo oficial es /en/enterprise con fallback a español, que podía convertirse en /es/esterprise. Ahora sólo se modifica el segmento inicial del locale.

• Content Collections dentro de Server Islands: se corrige la pérdida de estilos, enlaces y scripts asociados a entradas renderizadas dentro de una isla de servidor.

Si tu sitio es multilingüe o mezcla Content Collections con Server Islands, estos fixes pueden ser una razón más fuerte para actualizar que el rendimiento.

Cómo actualizar a Astro 7.3.1 de forma segura

Antes de cambiar producción, confirma que tu proyecto ya está en Astro 7. Para el panorama completo de la versión mayor, consulta nuestra guía de Astro 7 y migración.

git checkout -b upgrade/astro-7-3-1
npx @astrojs/upgrade
npm run build
npm run preview

Después verifica:

1. que el lockfile instaló 7.3.1 o una versión posterior, no 7.3.0;

2. imágenes locales y remotas que pasen por astro:assets;

3. rutas fallback en todos los idiomas;

4. páginas de Content Collections dentro de Server Islands;

5. un build con caché limpia y otro conservando node_modules/.astro;

6. memoria máxima del job antes de aumentar la concurrencia;

7. pruebas E2E y rollback del despliegue.

¿Conviene actualizar ahora?

Astro 7.3.1, SEO y lo que sí importa

Un build más rápido no mejora una posición de Google por sí solo. Su valor SEO es operativo: reduce el tiempo entre corregir contenido y publicarlo, hace más viable regenerar sitios grandes y ayuda a mantener páginas actualizadas. El resultado final todavía debe ofrecer HTML rastreable, títulos descriptivos, contenido original, enlaces internos útiles, imágenes con texto alternativo y una buena experiencia móvil.

Google recomienda contenido pensado primero para personas, con información original, metodología clara y fuentes confiables. Por eso este análisis separa los datos oficiales de nuestro benchmark, publica el entorno de prueba y explica sus límites. También conviene recordar que Core Web Vitals y la experiencia de página ayudan, pero no garantizan el primer puesto: relevancia y utilidad siguen siendo centrales.

Preguntas frecuentes sobre Astro 7.3.1

¿Cuál es la versión de Astro que debo instalar?

Instala Astro 7.3.1 o una versión posterior. Astro 7.3.0 tuvo un error que impedía iniciar o compilar proyectos que usan astro:assets.

¿Astro 7.3 activa los builds incrementales automáticamente?

No. experimental.incrementalBuild sigue siendo experimental y debe habilitarse. Además, cada ruta que quieras reutilizar necesita un cacheKey; las demás se renderizan siempre.

¿Puedo usar concurrencia mayor que 1 con el build incremental?

Sí en Astro 7.3. Antes, 7.2 desactivaba la caché incremental cuando build.concurrency era mayor que 1. Mide consumo de RAM antes de aumentar el valor en CI.

¿La mejora del 27.3% se repetirá en mi sitio?

No necesariamente. Es la mediana de nuestro fixture de 1,200 módulos en una máquina concreta. La arquitectura, contenido, plugins, imágenes, CPU y caché cambian el resultado. Úsalo como evidencia de la dirección de la mejora, no como garantía.

¿Astro 7.3.1 mejora Core Web Vitals?

La actualización se centra principalmente en compilación y correcciones internas. Puede mejorar el proceso de publicación, pero no implica automáticamente un mejor LCP, INP o CLS para el visitante. Esas métricas deben medirse en producción.

Fuentes y datos consultados

• Notas oficiales de Astro 7.3.0.

• Corrección oficial de Astro 7.3.1.

• Astro 7.2 y diseño de builds incrementales.

• Benchmarks oficiales de Astro 7.0.

• Guía de Google sobre contenido útil y confiable.