Astro 7.4: medir y acelerar la generación de tu sitio web

Desde el 15 de octubre de 2026, Astro 7.4 ofrece astro build --timings, una nueva herramienta para entender qué ralentiza la generación de un sitio web. Plugins de Vite, Markdown, imágenes, integraciones o componentes: en lugar de buscar a ciegas, los desarrolladores pueden identificar los elementos que realmente consumen más tiempo y comprobar el efecto de sus optimizaciones.

Esta novedad resulta especialmente útil para sitios corporativos grandes, catálogos B2B y plataformas editoriales. Por sí sola no garantiza un build más rápido: es una herramienta de diagnóstico. A continuación, explicamos cómo usarla y cuáles son los límites de otras funciones de Astro 7.4.

1. ¿Cómo usar astro build --timings?

A medida que se añaden páginas e integraciones, un build puede tardar mucho más que al inicio de un proyecto. Ahora Astro 7.4 muestra, al final de la compilación, un informe que detalla en qué se invierte el tiempo. Para empezar, comprueba las versiones de Node.js y Astro y vuelve a ejecutar el build:

node --version
npx astro --version
npx astro build --timings

El diagnóstico desglosa los costes entre configuración, preparación, bundles de cliente y servidor, generación de páginas, plugins de Vite, Markdown, resaltado de sintaxis, imágenes e integraciones. También destaca las páginas o los archivos más lentos. El informe no siempre atribuye cada milisegundo a una sola línea de código, pero permite saber dónde investigar.

Una precaución: algunas tareas se ejecutan en paralelo. La suma de todas las duraciones mostradas no tiene por qué coincidir con el tiempo total transcurrido. Para evaluar una mejora de velocidad, compara siempre el tiempo total y el detalle de la fase objetivo.

2. Ejemplo práctico: un catálogo profesional de 600 páginas

Imaginemos un catálogo B2B cuyas 600 fichas de producto se construyen a partir de una API, con descripciones, imágenes y características. Este caso es un ejemplo didáctico, no un benchmark realizado por SDX: todavía habría que recopilar las mediciones de este proyecto.

Si la mayoría de las «slowest pages» son fichas de producto y «component render» es lo que más tiempo consume, hay que examinar los componentes y las consultas de esas fichas. Si el coste principal aparece en «images», la prioridad será optimizar el pipeline visual. Precisamente, el informe permite no confundir ambas causas.

Qué midió realmente el equipo de Astro

Para demostrar la funcionalidad, Astro amplió un blog de nueve páginas con una sección de comentarios que primero obtiene los comentarios y después los perfiles de sus autores. Las llamadas sucesivas alargan la generación. Al agrupar estas consultas con Promise.all(), la fase de generación de páginas pasa de 2,10 a 1,13 segundos.

No se trata del tiempo total de compilación tras la optimización ni de una mejora generalizable a catálogos de 600 páginas. El build total inicial de la demostración marcaba 2,61 segundos, pero el resultado destacado, de 2,10 a 1,13 segundos, corresponde a la generación de páginas.

3. Reducir las esperas de red y reutilizar los datos

Evitar dos consultas secuenciales independientes

En un componente de Astro, los datos detallados y los datos de existencias de un producto pueden obtenerse uno tras otro, aunque no dependan entre sí:

---
const { product } = Astro.props;
const api = import.meta.env.CATALOG_API_URL;
const details = await fetch(api + "/products/" + product.id)
  .then((r) => r.json());
const stock = await fetch(api + "/stock/" + product.id)
  .then((r) => r.json());
---

Se pueden iniciar ambas llamadas a la vez con Promise.all():

---
const { product } = Astro.props;
const api = import.meta.env.CATALOG_API_URL;
async function getJson(path) {
  const response = await fetch(api + path);
  if (!response.ok) throw new Error("API " + response.status);
  return response.json();
}
const [details, stock] = await Promise.all([
  getJson("/products/" + product.id),
  getJson("/stock/" + product.id),
]);
---

Este enfoque puede reducir la espera, pero no reduce el número de llamadas. Requiere gestionar los errores y mantener un nivel de concurrencia compatible con los límites de la API; lanzar cientos de solicitudes simultáneas podría saturar el servicio.

Cargar el catálogo una vez en lugar de una vez por página

Si los productos están disponibles en una respuesta común, getStaticPaths() permite preparar las rutas estáticas y pasar los datos necesarios a las páginas, sin volver a consultar la API para cada propiedad que ya se conoce:

---
// src/pages/catalogue/[slug].astro
export async function getStaticPaths() {
  const api = import.meta.env.CATALOG_API_URL;
  const response = await fetch(api + "/products");
  if (!response.ok) throw new Error("Catalogue indisponible");
  const products = await response.json();
  return products.map((product) => ({
    params: { slug: product.slug },
    props: { product },
  }));
}
const { product } = Astro.props;
---
<h2>{product.name}</h2>
<p>{product.description}</p>

Este código está simplificado a propósito: presupone que el contenido de la API se puede cargar de una vez y que una ficha estática no necesita actualizarse de inmediato. En una plataforma real, se debería utilizar una capa de datos compartida y una caché controlada y, si hace falta, paginación o llamadas agrupadas. Las existencias o los precios que cambian con frecuencia no deben quedar fijados sin una estrategia de actualización: podrían requerir renderizado bajo demanda.

Las demás posibilidades siguen la misma lógica: eliminar el procesamiento redundante de Markdown, examinar los plugins de Vite, evitar cálculos repetidos en un layout e identificar conversiones de imágenes anormalmente numerosas. Cada cambio debe responder a una hipótesis verificable con --timings.

4. Antes y después: establecer una comparación fiable

Es tentador comparar una ejecución local con un build realizado en otro ordenador o en una CI. Sin embargo, la CPU, la memoria, el estado de la caché, la velocidad de la API, las versiones de Node.js y el contenido exacto pueden modificar los tiempos medidos. La comparación solo es válida si se mantiene el mismo alcance.

Un protocolo práctico consiste en realizar cinco ejecuciones por variante, distinguiendo claramente entre builds con la caché fría y con la caché caliente. Es un método propuesto para el artículo, no un valor de referencia oficial de Astro.

¿Por qué no hay cifras en estas celdas? Porque no se ha compilado este catálogo ficticio. Un artículo técnico fiable debe distinguir entre el protocolo propuesto y los resultados obtenidos realmente.

5. ¿Conviene activar el prerenderizado paralelo experimental?

Astro 7.4 incorpora experimental.parallelPrerender, que distribuye el prerenderizado estático entre varios worker threads de Node.js. Este mecanismo puede ser útil en proyectos con muchas operaciones de cálculo y varios núcleos disponibles. Por ejemplo, se activa así:

// astro.config.mjs — solo para pruebas
import { defineConfig } from "astro/config";

export default defineConfig({
  experimental: {
    parallelPrerender: { workers: 4 },
  },
});

Por defecto, cuando se activa la opción sin indicar un número de workers, Astro utiliza todos los núcleos disponibles menos uno. Cada worker puede generar varias páginas según build.concurrency, pero también aumenta el consumo de memoria. Una máquina con poca memoria o un build limitado por servicios de red no necesariamente se beneficiará.

Por tanto, el orden adecuado es: primero eliminar las llamadas innecesarias a la API, comprobar los elementos costosos con --timings y, solo después, comparar las configuraciones de workers si se ha demostrado que el renderizado de la CPU es un cuello de botella.

6. Imágenes, compatibilidad con Node.js y otras novedades

Dos servicios de imágenes para dos entornos

Astro 7.4 permite usar un servicio para las páginas prerenderizadas durante el build y otro para las páginas renderizadas bajo demanda. Por ejemplo, se puede usar Sharp durante la compilación y un servicio CDN adaptado al entorno de ejecución de producción:

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

export default defineConfig({
  image: {
    service: {
      build: { entrypoint: "astro/assets/services/sharp" },
      runtime: { entrypoint: "my-image-cdn-service" },
    },
  },
});

El nombre my-image-cdn-service es un marcador de posición, no un módulo listo para usar: debe sustituirse por un servicio de imágenes compatible, instalado y configurado. El servicio de build también se utiliza durante el desarrollo; el servicio runtime está destinado a las páginas bajo demanda y al endpoint de imágenes en producción. Sigue siendo compatible el servicio único tradicional.

Node.js 22.22.0 pasa a ser la versión mínima compatible

Astro 7.4 y sus integraciones oficiales requieren como mínimo Node.js 22.22.0. Por ello, hay que comprobar los equipos de desarrollo, las imágenes Docker, la CI y el alojamiento, y después probar las dependencias al actualizar. El comando de migración recomendado es:

npx @astrojs/upgrade

También hay que actualizar las integraciones @astrojs/cloudflare y @astrojs/markdoc a versiones compatibles con astro@^7.4.0. Haz una copia de seguridad del proyecto y valida el resultado del build antes del despliegue.

Entre los cambios adicionales se incluyen el nuevo controlador notFound() para los puntos de entrada creados con astro/fetch o astro/hono, una detección mejorada de los parámetros de fuentes no compatibles con su proveedor y una página de redirección estática personalizada experimental.

7. Generación, carga y SEO: no mezclar los indicadores

El rendimiento de generación mide la rapidez del trabajo que se realiza antes de publicar el sitio: compilación, obtención de datos, procesamiento y generación de archivos. Afecta sobre todo a los equipos, la integración continua y los plazos de despliegue.

El rendimiento de carga tiene que ver con la experiencia de los visitantes: tiempo de red, JavaScript, fuentes, imágenes, caché y capacidad de respuesta. Los Core Web Vitals evalúan, entre otros aspectos, el LCP (carga), el INP (interacciones) y el CLS (estabilidad visual). --timings no mide ninguno de estos indicadores.

El SEO técnico también depende de la indexabilidad, las etiquetas, la estructura HTML, las URL canónicas, el enlazado interno y el sitemap. Un build más rápido no soluciona automáticamente estos problemas. Hay que medir los Core Web Vitals y comprobar por separado el contenido renderizado y su accesibilidad para los motores de búsqueda.

Si lo que más importa es el tamaño de las imágenes que se entregan al navegador, nuestro artículo sobre JPEG XL, WebP y AVIF aborda un aspecto complementario: el peso que se transfiere a los usuarios no es lo mismo que el tiempo de procesamiento de imágenes durante la generación.

Preguntas frecuentes sobre Astro 7.4

¿--timings acelera el sitio?

No. El informe identifica los cuellos de botella del build, pero todavía hay que corregir sus causas y medir el efecto real de los cambios. No mejora directamente la experiencia de los visitantes.

¿Cómo identificar un componente de Astro costoso?

Observa las páginas más lentas y la sección de renderizado de componentes; después, inspecciona los layouts comunes, las consultas, los bucles costosos y los procesos externos. El informe orienta la investigación, pero no identifica por sí solo una línea de código concreta.

¿Funciona el prerenderizado paralelo en Cloudflare?

El prerenderizado paralelo experimental se ignora con @astrojs/cloudflare, que ya cuenta con su propio sistema de prerenderizado. Por tanto, no hay que atribuirle mejoras inexistentes.

¿Hay que migrar inmediatamente a Astro 7.4?

La herramienta de diagnóstico merece probarse si el build es lento. Antes de adoptar la migración de forma permanente, comprueba la versión mínima de Node.js, las integraciones y el entorno de despliegue. La opción de timings se puede utilizar sin activar el prerenderizado paralelo.

Conclusión: optimizar a partir de mediciones

La novedad más útil de Astro 7.4 es la visibilidad de la cadena de generación. Con astro build --timings, se puede identificar una llamada externa repetitiva, un componente lento o una transformación costosa, corregir la causa y comparar el resultado. El prerenderizado paralelo y los servicios de imágenes separados responden a otras necesidades, pero no sustituyen este proceso.

En SDX Development, aplicamos este enfoque al diseño, rediseño y optimización de sitios web profesionales: trabajar de forma más eficiente, mantener una base sostenible y comprobar por separado el rendimiento que experimentan los visitantes.

Fuentes y metodología 4 referencias

• Astro — Astro 7.4, anuncio oficial del 15 de octubre de 2026 y ejemplo de 2,10 a 1,13 segundos.
• Astro — Documentación de la CLI, descripción de --timings.
• Astro — Prerenderizado paralelo experimental, configuración y limitaciones.
• web.dev — Web Vitals, definición de las métricas de experiencia de usuario.

La tabla de mediciones oficiales corresponde al proyecto de demostración de Astro, no a un catálogo real. El caso de las 600 fichas constituye un método reproducible cuyos resultados aún están pendientes de medición.