Reconstruí mi blog con Astro 5: Lighthouse pasó de 68 a 100

La semana pasada tiré abajo el blog en Next.js que llevaba dos años y lo reconstruí con Astro 5. El detonante fue una puntuación Lighthouse de solo 68: el blog cargaba tan lento que un amigo dijo que «giraba y giraba antes de aparecer». Tras la migración, el tiempo de build bajó de 2 minutos a 18 segundos y la puntuación de rendimiento pasó de 68 a 98.
En este artículo hablamos de tres cosas: por qué Astro es tan rápido, cómo montar un blog con él y cómo configurar el SEO. Si alguna vez te ha torturado el rendimiento de tu blog, lo de abajo debería ayudarte.

Por qué Astro merece tu atención

Siendo honesto, al principio Astro no me interesaba mucho. Hay tantos frameworks —Next.js, Nuxt, Gatsby— que marean. Pensaba: otro stack nuevo, ¿merece la pena el tiempo?
Hasta que vi unos datos:
La encuesta State of JavaScript 2024 sitúa a Astro en primer lugar en interés, retención y satisfacción. En uso queda segundo, solo detrás de Next.js. GitHub Octoverse 2025 va más lejos y lo presenta como uno de los lenguajes de mayor crecimiento.
Otro dato llamativo: el 60 % de los sitios Astro superan Core Web Vitals; WordPress y Gatsby solo el 38 %. La brecha es grande.
Quién lo usa: la documentación de GitHub, la de desarrolladores de Firebase, Smashing Magazine (migraron desde WordPress). En 2025 también Google, Reuters y Typst.
Ahí me paré a pensar: ¿qué es mi blog? Un montón de artículos Markdown, resaltado de código y a veces un componente de comentarios. ¿Necesito todo el aparato full-stack de Next.js? No parece.
Mi lectura: si escribes blog, documentación o landing, Astro es casi la mejor opción hoy. Si montas e-commerce o SaaS con mucha interacción, Next.js sigue encajando mejor.
No es quién gana, es el escenario.

Arquitectura Island: el secreto de la velocidad de Astro

¿Te ha pasado que el contenido ya está en pantalla pero los botones no responden?
Suele ser la hidratación de JavaScript. Los frameworks clásicos mandan todo el JS de la página al navegador y lo van «activando». Cuanto más compleja la página, más esperas.
Astro hace lo contrario con la arquitectura Island (Islands Architecture).
Imagina la página como un mar de HTML estático; solo los componentes que de verdad interactúan —contador, formulario, comentarios— «emergen» como islas independientes. Cada isla lleva su propio JavaScript sin molestar a las demás.
En código se ve así:

---

// Este componente solo carga JS cuando entra en el viewport

---

<Counter client:visible />
// Este componente es siempre HTML puro, sin JS
<Header />

¿Ves client:visible? Es la directiva de Astro: activa el componente cuando el usuario lo ve. También hay client:load (al cargar la página) y client:idle (cuando el navegador está ocioso).
En mi blog el FCP pasó de 2,1 s a 0,8 s y el TTI de 4,5 s a 1,2 s. El bundle JS: de 280 KB a 45 KB.
Con justicia, si toda la página son componentes interactivos, Astro puede no ser lo ideal. Brilla cuando la mayor parte es estática. En blogs y docs es otro nivel.

Server Islands: la novedad de Astro 5

Astro 5 añade Server Islands.
Antes: página casi estática pero un bloque dinámico —avatar, contador del carrito— ¿qué haces? O renderizas toda la página en dinámico o renuncias a la personalización.
Server Islands: primero entregas una carcasa HTML estática y el servidor inyecta por separado lo dinámico.
Oficialmente, «rendimiento y personalización ya no se excluyen». En mis pruebas, va muy fluido.

Content Layer: una forma nueva de gestionar contenido

Cuando pasas de 100 artículos, gestionar contenido se vuelve caótico.
Lo clásico: apilar Markdown en src/content y organizar por carpetas. Con pocos posts va bien; con muchos, buscar archivos y conectar un CMS duele.
Content Layer en Astro 5 cambia el juego.
El núcleo es el mecanismo Loader: contenido desde Markdown local, Strapi, Contentful, Notion o tu propia API. Una sola fuente, gestión más clara.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

// astro.config.mjs
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    tags: z.array(z.string()),
  }),
});

Esto carga todos los .md de ./src/content/blog y exige title, pubDate y tags.
En rendimiento, Astro dice hasta 5× más rápido en Markdown, 2× en MDX y 25-50 % menos memoria. En mi blog el build pasó de 2 minutos a 18 segundos; encaja con eso.
Hoy uso glob loader con Markdown local. Próximo paso: Notion para separar escritura y publicación.

View Transitions: cambios de página fluidos

Breve: en Astro 5 ViewTransitions pasó a llamarse ClientRouter, misma función, nombre que refleja mejor el enrutado en cliente.

---

import { ClientRouter } from 'astro:transitions';

---

<html>
  <head>
    <ClientRouter />
  </head>
  <body>
    <!-- Tu contenido -->
  </body>
</html>

Con este componente, los cambios de página tienen transición en lugar de un salto brusco. La UX mejora bastante.
En 2025 la View Transitions API nativa la soportan casi todos los navegadores modernos; Firefox fue el último. ClientRouter degrada en los que no la tengan.
Si necesitas estado compartido entre páginas —un reproductor que no se corta al navegar—, ClientRouter encaja. Para animaciones simples, CSS View Transitions nativo también basta.

Configuración SEO en la práctica

Muchos creen que con buen rendimiento en Astro ya está; el SEO importa. Los buscadores miran velocidad, pero también estructura y metadatos.
La primera vez tropecé bastante; aquí va lo que aprendí.

Configuración del sitemap

Lo básico y lo que más se olvida:

npx astro add sitemap

Luego en astro.config.mjs tu dominio:

import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
  site: 'https://yourdomain.com', // ¡No olvides esta línea!
  integrations: [sitemap()],
});

La primera vez olvidé site y el sitemap salió con rutas relativas; Google no las tomó. Me costó días descubrirlo.

Gestión de metaetiquetas

Cada artículo debe tener su title y description. Yo los centralizo en el frontmatter del Markdown:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

---

title: "Guía de optimización de rendimiento en Astro 5"
description: "Análisis profundo de la arquitectura Island y Content Layer en Astro 5..."
publishDate: 2025-11-20
ogImage: "/images/astro-5-cover.png"

---

En el layout leo esos datos:

---

const { title, description, ogImage } = Astro.props.frontmatter;

---

<head>
  <title>{title}</title>
  <meta name="description" content={description} />
  <meta property="og:title" content={title} />
  <meta property="og:description" content={description} />
  <meta property="og:image" content={ogImage} />
  <link rel="canonical" href={Astro.url} />
</head>

La URL canónica evita que el mismo contenido se trate como duplicado.

Datos estructurados (JSON-LD)

Poca gente lo usa, pero ayuda al SEO: le dice al buscador que es un artículo, quién es el autor y cuándo se publicó.

<script type="application/ld+json">
  {JSON.stringify({
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": title,
    "datePublished": publishDate,
    "author": {
      "@type": "Person",
      "name": "Tu nombre"
    }
  })}
</script>

Puedes validar con Schema.org Validator.

Tendencias SEO en 2025

Cambios relevantes este año:

1. Los LLM también rastrean tu página. Buscadores e IA dependen de contenido estructurado; escribir claro pesa más que apilar keywords.
2. Los enlaces internos importan. Al menos 3 por página, o el buscador puede pensar que no merece indexarse.
3. Principio E-E-A-T. Experiencia, pericia, autoridad, confianza: no es magia, es un factor real de ranking en Google.

Lista de comprobación SEO

Al terminar la configuración, repasa:

• sitemap.xml generado y accesible
• title y description únicos en cada página
• alt en todas las imágenes
• JSON-LD añadido
• robots.txt correcto
• al menos 3 enlaces internos por página

Optimización de imágenes: el asesino silencioso del rendimiento

Suena simple, pero comprimir no basta.
Astro trae astro:assets y el componente Image es muy potente:

---

import { Image } from 'astro:assets';
import myImage from '../assets/hero.png';

---

<Image
  src={myImage}
  alt="Hero image"
  widths={[400, 800, 1200]}
  format="webp"
/>

Esto hace varias cosas:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

1. Infiere ancho y alto para evitar CLS
2. Genera varios tamaños para carga adaptativa
3. Convierte a WebP para menos peso
   Clave: las imágenes van en src, no en public. Astro optimiza las de src; las de public, no. Yo las puse mal y pesaban una barbaridad.
   Para remotas, inferSize obtiene dimensiones automáticamente:

<Image
  src="https://example.com/image.jpg"
  alt="Remote image"
  inferSize
/>

¿Cuánto se nota? El proyecto open source AstroEdge probó: de 4,2 MB a 0,8 MB (−82 %). La puntuación de rendimiento de 79 a 100.
Astro 5 añade recorte experimental de imágenes y soporte de componentes SVG; mira la documentación oficial si te interesa.

Migrar desde otros frameworks

Si vienes de Astro 4 u otro framework, repaso rápido.
Cambios principales en Astro 5:

1. ViewTransitions renombrado a ClientRouter
2. Astro.glob() obsoleto; usa import.meta.glob() o getCollection()
3. Modo híbrido fusionado en salida estática
4. Servicio de imágenes de Squoosh a Sharp
5. Protección CSRF activada por defecto
   Comando de migración:

npx @astrojs/upgrade

Resuelve la mayoría de incompatibilidades y avisa lo manual.
Desde Next.js o Gatsby hay más trabajo, pero Astro admite componentes React: puedes migrar páginas primero y sustituir componentes poco a poco.

Para cerrar

En resumen:

1. Arquitectura Island: cero JS por defecto, ventaja natural de rendimiento
2. Content Layer: contenido unificado, cualquier fuente de datos
3. SEO: pocos pasos, cada uno crítico
4. Imágenes: gran palanca oculta, no la ignores
5. View Transitions: navegación más fluida
   Si dudas qué framework usar para el blog, prueba media hora la plantilla oficial de Astro y mira el build y Lighthouse.

npm create astro@latest -- --template blog

Lista para usar; ajusta config y publica.
Recursos útiles:

• Documentación oficial de Astro (inglés, la más completa)
• Astro en chino (traducción al chino)
  En el próximo artículo montaré un blog técnico con Astro + Tailwind + MDX; si te interesa, sígueme.
  ¿Qué framework usa tu blog? ¿Te ha atormentado el rendimiento? Cuéntalo en los comentarios.