Por qué este blog bilingüe corre sobre Astro 7: una nota de ingeniería en primera persona

La versión corta: primero la noticia

Astro 7.0 salió el 22 de junio de 2026 y, en palabras del propio equipo, este release “es todo sobre velocidad” (anuncio de Astro 7.0). Para un sitio de contenido e i18n como este blog, los titulares importan: el compilador de .astro fue reescrito en Rust (reemplazando al compilador anterior en Go), los builds son entre 15% y 61% más rápidos gracias a Vite 8 más el nuevo bundler Rolldown, el cacheo de rutas (route caching) pasó a ser estable, y llegaron funciones de desarrollo asistido por IA.

Aclaro algo desde el inicio: este es un post meta, en primera persona. No estoy teorizando. Corro cesarayala.dev sobre Astro, con el inglés en la raíz y el español bajo /es/, así que lo que describo es mi propio setup, no un diagrama de pizarrón. Si quieres ver lo que publica este stack, ahí está el blog.

Y como construyo con herramientas de IA todos los días, la parte de “Astro detecta agentes de código y emite logs en JSON” no es una nota al pie para mí: es directamente relevante a cómo trabajo. Un ejemplo reciente hecho con ese flujo es este post sobre Claude structured outputs en producción.

Dos trampas de migración que vale la pena marcar de una vez, antes de que te emociones: el Node.js mínimo ahora es la v22, y @astrojs/db fue eliminado (venía deprecado desde la v6.4.5). Ninguna me afectó a mí, pero son reales para otros.

¿Por qué un blog bilingüe (y por qué estático)?

El español es una audiencia prioritaria para mí. La ventaja ganable que veo —pagos en LATAM y contenido en español primero— no se construye con traducción automática; se construye escribiendo en serio en ambos idiomas. Así que el blog tiene que ser genuinamente bilingüe, no un EN con un botón de Google Translate encima.

Un sitio de contenido bilingüe vive o muere según sus señales de hreflang y canonical. Si la versión en inglés y la versión en español de un mismo post se desincronizan —una existe, la otra no, o apuntan mal— los buscadores ven páginas duplicadas o huérfanas. Eso es daño real al SEO, no un detalle cosmético.

HTML-first y estático encaja exactamente por eso: cada página se genera en build time y envía casi cero JavaScript. Rápido en los teléfonos Android de gama media que usa buena parte de mis lectores en LATAM. Sin costo de hidratación para un post de blog, los Core Web Vitals salen bien prácticamente gratis.

Opinión, y la etiqueto como tal: para contenido que no puede desincronizarse en hreflang ni canonical, un framework estático, HTML-first y validado por esquema le gana a una SPA pesada en JS. Las garantías de corrección importan más que la interactividad del lado del cliente que de todos modos no necesito en un artículo.

Cómo modelo el i18n (mi setup, no una función de 7.0)

Encuadre importante: así he construido el i18n con el modelo de content collections que Astro ya tenía. No es una función nueva de Astro 7.0 y no estoy reclamando ningún cambio de i18n del changelog. Es ingeniería de aplicación sobre piezas existentes.

Cada post es una entrada MDX dentro de una content collection con un esquema de Zod. El frontmatter lleva un campo lang (‘en’ o ‘es’) y un translationKey compartido que enlaza un post en inglés con su gemelo en español. Las páginas en inglés se renderizan en la raíz; las de español, bajo /es/. Como ambas comparten el translationKey, genero los tags de hreflang recíprocos —cada idioma apuntando al otro— más un canonical autorreferencial.

// astro.config.mjs — EN en la raíz, ES bajo /es/ (ilustrativo)
import { defineConfig } from "astro/config";

export default defineConfig({
  site: "https://cesarayala.dev",
  i18n: {
    defaultLocale: "en",
    locales: ["en", "es"],
    routing: {
      // el idioma por defecto (en) vive en la raíz; es vive en /es/
      prefixDefaultLocale: false,
    },
  },
});

// content.config.ts — el esquema es la barrera (ilustrativo)
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    lang: z.enum(["en", "es"]),
    // enlaza un post EN con su gemelo ES; obligatorio
    translationKey: z.string(),
  }),
});

export const collections = { blog };

El esquema de Zod es la barrera de protección: si se me olvida lang o translationKey, el build falla. No puedo enviar por accidente un post con el emparejamiento de idiomas roto. Eso significa que el hreflang se deriva de los datos, no se mantiene a mano página por página. La fuente número uno de drift en sitios bilingües queda eliminada por construcción. Esa misma disciplina es la que aplico en guías como pasarelas de pago en México.

Qué significan el compilador en Rust y el “HTML más estricto” para MDX

El compilador de .astro fue reescrito en Rust, reemplazando al anterior basado en Go. Es mayormente compatible hacia atrás, pero más estricto con el HTML inválido o de estilo JSX, y revisó el manejo de espacios en blanco (según el anuncio de Astro 7.0).

Para un sitio de contenido con MDX, eso es una función, no un bug. El markup malformado que antes pasaba en silencio ahora aparece como error de build. Atrapo etiquetas rotas antes de que lleguen a producción, no después de que un lector me las reporte.

Caveat honesto: “más estricto” también significa que una migración puede romperse de golpe por HTML que antes compilaba. Presupuesta tiempo para arreglar el markup que el compilador marque cuando actualices. No es trabajo infinito, pero no es cero.

Vale calibrar las expectativas de velocidad: el compilador en Rust por sí solo es alrededor de 6% más rápido en aislamiento, según los benchmarks de Astro. Las ganancias grandes vienen del resto del pipeline, que es la siguiente sección. El efecto neto para mí es concreto: builds más limpios y menos problemas silenciosos a lo largo de decenas de archivos MDX bilingües.

Builds 15–61% más rápidos: de dónde sale la velocidad

Los benchmarks del propio Astro reportan builds entre 15% y 61% más rápidos en general, y algunos sitios construyen más del doble de rápido (anuncio de Astro 7.0). No es un solo cambio mágico; es el pipeline completo moviéndose a Rust.

Las fuentes de la mejora de velocidad, según Astro: el compilador en Rust (alrededor de 6% en aislamiento), un nuevo pipeline de Markdown/MDX impulsado por Rust que reemplaza al pipeline anterior basado en unified (remark/rehype) como procesador por defecto, y un motor de render basado en colas más rápido (cerca de 2.4× en render). Además, Vite 8 trae el nuevo bundler Rolldown —también en Rust, reemplazando la combinación de Rollup y esbuild— que Astro cita como 10–30× más rápido que Rollup.

Por qué esto importa específicamente en un sitio de contenido: el tiempo de build escala con el número de páginas, y un blog bilingüe tiene el doble de páginas (EN más ES). Un procesamiento de Markdown/MDX más rápido se compone a medida que el archivo crece. La recompensa práctica es directa: rebuilds locales más rápidos y deploys de CI más rápidos. Menos fricción para enviar un post en dos idiomas.

Dev asistido por IA: detección de agentes + logs JSON

Astro 7 puede detectar agentes de código y correr automáticamente el servidor de desarrollo en un modo de fondo, con manejo de procesos y un endpoint de salud. También puede emitir logs estructurados en JSON —vía un flag de CLI o configuración— es decir, feedback legible por máquina en vez de parsear la salida formateada para humanos de la terminal.

Por qué me importa: construyo con herramientas de IA a diario. Logs estructurados significan que un agente puede leer de forma confiable la salida de build o dev y actuar sobre ella, en lugar de adivinar a partir de texto embellecido. Esto está genuinamente apuntado al flujo de “agente en el loop”, que es como cada vez más sucede mi día a día de shipping. Si te interesa esa parte, tengo un hub de agentes de IA donde profundizo.

Alcance honesto: son conveniencias de tiempo de desarrollo, no magia. Hacen más apretado el loop asistido por IA que ya existía; no te escriben el post.

Las trampas de migración: Node 22 y @astrojs/db

Cambio rompedor: el Node.js mínimo ahora es la v22. Si tu CI o tu host fija una versión más vieja de Node, la actualización falla hasta que la subas. Revisa tu entorno de deploy primero, antes de tocar el package.json.

Cambio rompedor: @astrojs/db fue eliminado (estaba deprecado desde la v6.4.5), junto con los comandos de CLI astro db, login, logout, link e init. Si usabas Astro DB, necesitas una capa de datos alternativa antes de actualizar.

Para mi blog bilingüe estático ninguno de los dos es un bloqueador. No uso @astrojs/db, y subir a Node 22 fue un cambio de una línea en CI. Pero los marco porque son reales para otros, y porque “a mí no me pegó” no es asesoría.

Ruta de actualización: sigue la guía oficial para migrar a Astro v7 y espera que el compilador en Rust, más estricto, saque a la luz problemas de HTML antes silenciosos. Mi recomendación: actualiza en una rama, corre un build completo y lee los errores del compilador. No actualices directo sobre main. Si quieres ver cómo encaja Astro con el resto de mi stack, está el hub de integraciones.

Preguntas frecuentes

¿Astro 7 agregó funciones nuevas de i18n? No que yo reclame aquí. El setup que describo —EN en la raíz, ES bajo /es/, translationKey y hreflang— es el modelo de content collections que ya existía, no un ítem del changelog de 7.0.

¿Cuándo salió Astro 7? El 22 de junio de 2026.

¿Qué tan rápidos son los builds? Entre 15% y 61% más rápidos en general según los benchmarks de Astro, con algunos sitios más del doble de rápido.

¿Tengo que actualizar ahora mismo? No. El requisito de Node 22 y la eliminación de @astrojs/db son razones reales para planear en vez de correr. Actualiza en una rama.

¿De verdad alcanza con estático para un blog? Para un blog de contenido e i18n, sí. No necesito hidratación del lado del cliente, y saltármela es lo que me da casi cero JS y Core Web Vitals limpios.

Cierre

El punto de fondo: un blog bilingüe es un problema de corrección antes que un problema de rendimiento. Astro me deja resolver la corrección en el esquema, donde un emparejamiento de idiomas roto se vuelve un error de compilación en lugar de una página huérfana que descubro tres meses después en Search Console.

La velocidad de Astro 7 y sus funciones de dev con IA son un buen viento a favor. Pero la razón por la que estoy en Astro es que EN/ES y el hreflang no pueden desincronizarse, y un build estático, validado por esquema, convierte ese drift en un error de compilación.

Si estás construyendo contenido en español primero o bilingüe para LATAM, este stack merece una mirada seria.