La solución de Astro: HTML por defecto

Si el problema es enviar una aplicación para servir un documento, la solución es dejar de hacerlo. Astro renderiza tus componentes a HTML en el servidor, no envía ningún runtime por defecto, y solo hidrata las porciones interactivas que tú marcas explícitamente. El resultado es una web que carga como lo que es: contenido.

HTML por defecto, cero JavaScript

Un componente .astro es plantilla HTML con un bloque de script delimitado por --- (la “valla frontmatter”). Ese bloque corre en el servidor, durante el build o en la petición, y jamás se envía al navegador. Lo que el usuario recibe es el HTML resultante, sin runtime, sin framework, sin bundle de hidratación.

---
// Este bloque se ejecuta en el servidor. Nunca llega al navegador.
const posts = Object.values(import.meta.glob('./posts/*.md', { eager: true }));
const destacados = posts.filter((p) => p.frontmatter.destacado);
---
<section>
  <h1>Últimos artículos</h1>
  <ul>
    {destacados.map((p) => (
      <li><a href={p.url}>{p.frontmatter.title}</a></li>
    ))}
  </ul>
</section>

Fíjate en lo que ocurre: usas expresiones de JavaScript para construir la página, pero el JavaScript se queda en el servidor. Al cliente solo baja la lista ya renderizada en HTML. La lógica se evapora en el build; el usuario nunca la descarga.

Las islas: JavaScript solo donde lo pides

¿Y cuando sí necesitas interactividad —un buscador, un carrusel, un botón con estado—? Astro te deja usar componentes de React, Vue, Svelte, Solid o Preact, y los convierte en islas: fragmentos interactivos embebidos en un océano de HTML estático. Cada isla se activa con una directiva client:* que decide cuándo se hidrata.

---
import Buscador from '../components/Buscador.jsx';
import Carrusel from '../components/Carrusel.svelte';
---
<article>
  <h1>Guía de Astro</h1>
  <p>Todo este texto es HTML estático: cero JavaScript enviado.</p>

  <!-- Solo estas dos islas se hidratan, cada una por su cuenta -->
  <Buscador client:load />
  <Carrusel client:visible />
</article>

Sin la directiva, un componente de framework se renderiza a HTML y se queda inerte, igual que un .astro. Con ella, y solo entonces, Astro envía el JS mínimo para esa isla concreta. El resto de la página no paga nada.

La regla de oro es la parsimonia: cada directiva que añades es JavaScript que el usuario descargará. client:load es tentador porque “siempre funciona”, pero convierte cada isla en coste inmediato. La mayoría vive bien con client:visible o client:idle, que difieren el trabajo hasta que de verdad hace falta.

Content-first: el contenido es de primera clase

Astro no trata el contenido como un añadido: lo pone en el centro. Las content collections te dejan definir un esquema tipado para tu Markdown y MDX, validado con Zod, de modo que tu frontmatter tiene tipos y autocompletado como cualquier otra estructura de datos.

import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    fecha: z.date(),
    destacado: z.boolean().default(false),
  }),
});

export const collections = { blog };

MDX permite mezclar componentes dentro de la prosa —esta misma guía lo hace—. El flujo entero, desde el fichero de contenido hasta el HTML final, está pensado para escribir mucho y enviar poco.

flowchart LR
A[Componentes .astro] --> B[Render en el servidor]
B --> C[HTML puro sin JS]
D[Componente de framework] --> E{Lleva directiva client}
E -- si --> F[Isla hidratada]
E -- no --> C
style C fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b

A quién beneficia

El modelo brilla justo donde la SPA desperdicia. Cualquier sitio donde el contenido manda y la interactividad es puntual gana con Astro.