El mejor generador de sitios estáticos: Astro, Hugo, Eleventy o Next.js

Un generador de sitios estáticos toma tus contenidos (normalmente en Markdown), aplica plantillas y produce una carpeta de archivos HTML, CSS y JavaScript listos para servir. No hay base de datos ni servidor de aplicaciones en el camino de cada visita, lo que hace que el sitio sea rápido, barato y difícil de tumbar. Si el concepto es nuevo para ti, empieza por qué es un sitio estático.

La duda suele ser qué generador usar. Cuatro nombres aparecen en casi todas las listas: Astro, Hugo, Eleventy y Next.js. Los cuatro generan buenos sitios, pero parten de filosofías distintas, y la elección equivocada se nota meses después, cuando el build se vuelve lento o el sitio carga demasiado JavaScript.

¿Qué criterios importan al elegir?#

1. Cuánto JavaScript llega al navegador. Un blog no necesita un framework ejecutándose en el cliente. Menos JavaScript significa cargas más rápidas, sobre todo en el móvil.
2. Cantidad de páginas y tiempo de build. Con decenas de páginas, cualquier generador sirve. Con miles, el tiempo de build empieza a pesar en el día a día.
3. Interactividad. Un buscador o un carrusel es una cosa; un panel con estado complejo es otra.
4. Lenguaje y ecosistema. Si ya usas React, reutilizar componentes cuenta mucho. Si no quieres depender de Node.js, eso también descarta opciones.
5. Probabilidad de necesitar un servidor después. Login, contenido personalizado o páginas generadas bajo demanda piden renderizado en el servidor. La diferencia entre los modelos está en SSR vs SSG vs estático.

¿Cuándo es Astro la mejor opción?#

Astro es un framework para sitios de contenido. Por defecto, las páginas se prerenderizan en el build como HTML estático, y Astro elimina automáticamente todo el JavaScript del cliente. Cuando una parte necesita interactividad, marcas solo ese componente con una directiva como client:load, client:idle o client:visible, y se convierte en una "isla" con su propio JavaScript. Las islas pueden escribirse en React, Preact, Svelte, Vue o SolidJS, incluso mezcladas en la misma página. Astro exige una versión reciente de Node.js; el mínimo está en la documentación de instalación.

Una página .astro mezcla un bloque de código que se ejecuta en el build con el HTML de salida:

---
const posts = [
  { slug: "hola-mundo", title: "Hola, mundo" },
  { slug: "segundo-post", title: "Segundo post" },
];
---

<html lang="es">
  <head>
    <meta charset="utf-8" />
    <title>Mi blog</title>
  </head>
  <body>
    <h1>Mi blog</h1>
    <ul>
      {posts.map((p) => <li><a href={`/blog/${p.slug}/`}>{p.title}</a></li>)}
    </ul>
  </body>
</html>

En una prueba, astro build convirtió esta página en un dist/index.html sin ninguna etiqueta <script>.

Ventajas: cero JavaScript por defecto, islas con el framework que prefieras, colecciones de contenido en Markdown y MDX, y la opción de renderizar páginas bajo demanda con un adaptador si el sitio crece.

Desventajas: el ecosistema cambia rápido. Las versiones mayores suelen cambiar piezas internas, como la versión de Vite, el compilador o el procesador de Markdown por defecto, y los plugins de remark y rehype pueden pasar a necesitar configuración extra. Actualizar entre versiones mayores exige leer la guía de migración.

¿Cuándo es Hugo la mejor opción?#

Hugo es un generador escrito en Go y optimizado para la velocidad: según su documentación, renderiza un sitio completo en segundos, a menudo menos. Se distribuye como un ejecutable listo para usar y no necesita Node.js.

hugo new project mi-sitio
cd mi-sitio
hugo server   # servidor local con recarga automática
hugo          # build de producción en la carpeta public/

En las versiones recientes, el comando de creación es hugo new project (los tutoriales antiguos usan hugo new site).

Ventajas: builds muy rápidos incluso con miles de páginas, sin node_modules, taxonomías (etiquetas, categorías) y soporte multilingüe integrados, temas listos para usar.

Desventajas: las plantillas usan la sintaxis de plantillas de Go, con su propia curva de aprendizaje si vienes de JavaScript. Los componentes interactivos corren por tu cuenta, en JavaScript suelto. El LibSass integrado en la edición extended quedó obsoleto en la versión 0.153.0, y para Sass la recomendación pasó a ser Dart Sass.

¿Cuándo es Eleventy la mejor opción?#

Eleventy (o 11ty) es un generador minimalista sobre Node.js. Transforma plantillas en páginas y acepta muchos lenguajes: HTML, Markdown, JavaScript, WebC, Nunjucks, Liquid, Handlebars, Pug y otros. Funciona en cualquier versión reciente de Node.js. No impone un framework de front-end ni un pipeline de assets: el HTML que escribes es el HTML que sale.

Una configuración mínima con ES modules ("type": "module" en el package.json):

// eleventy.config.js
export default function (eleventyConfig) {
  eleventyConfig.addPassthroughCopy("src/img"); // copia las imágenes sin procesarlas
}

export const config = {
  dir: { input: "src", output: "_site" },
};

Con un src/index.md y npx @11ty/eleventy, el resultado va a _site/. En una prueba, el build de una página tardó menos de medio segundo.

Ventajas: fácil de entender, sin JavaScript en el cliente salvo el que añadas, flexible con las plantillas, ideal para blogs y documentación.

Desventajas: sin componentes interactivos listos ni pipeline de imágenes y CSS por defecto (hay plugins oficiales para imágenes). En proyectos grandes tienes que organizar la estructura tú mismo.

¿Cuándo tiene sentido Next.js para un sitio estático?#

Next.js es un framework completo de React con renderizado en el servidor. También exporta un sitio estático: con output: "export" en next.config, next build genera una carpeta out/ que cualquier servidor de archivos puede servir.

// next.config.mjs
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export",
  trailingSlash: true, // genera /acerca/index.html en lugar de /acerca.html
  images: { unoptimized: true }, // sin el servidor de Next.js no hay optimización de imágenes bajo demanda
};

export default nextConfig;

La documentación enumera lo que deja de funcionar en la exportación estática: rutas dinámicas sin generateStaticParams(), cookies, rewrites, redirects, headers, proxy, ISR, Server Actions, draft mode y la optimización de imágenes con el loader por defecto.

Ventajas: si tu equipo ya usa React y Next.js, reutilizas componentes y conocimiento. Puedes empezar en estático y pasar a un servidor después sin cambiar de framework.

Desventajas: carga el runtime de React en cada página. En una prueba, una exportación cuya única página decía "Hola" referenciaba más de 100 KB de JavaScript comprimido (gzip). Para un blog es peso sin beneficio. Para hospedar la versión con servidor, consulta cómo hospedar una aplicación Next.js.

¿Cómo se comparan los cuatro lado a lado?#

¿Cuál elegir en cada escenario?#

Si tienes dudas, Astro es la opción más versátil para un sitio de contenido nuevo. Si el sitio es solo texto y quieres el mínimo de piezas, Eleventy. Si el problema es el volumen de páginas, Hugo. Antes de decidir dónde publicar, compara cuánto cuesta hospedar un sitio estático. Y si tu sitio se convierte en una SPA con rutas en el cliente, ten en cuenta el error 404 al recargar, que exige configurar el servidor.

Cómo hacerlo en Square Cloud#

Square Cloud tiene un runtime de sitios estáticos, además de runtimes de Node.js y otros lenguajes. Ejecutas el build del generador (Astro, Hugo, Eleventy o Next.js con exportación) y haces el deploy de la carpeta de salida subiendo un ZIP, con la CLI o desde GitHub. La plataforma no tiene etapa de build: genera la carpeta en tu máquina o en un CI externo, como GitHub Actions, y sube el resultado.

Cada aplicación web recibe un subdominio HTTPS *.squareweb.app, y el tráfico pasa por una CDN global, con TLS automático y tráfico ilimitado (política de uso justo). Los dominios personalizados empiezan en el plan Standard: creas los registros DNS en tu registrador y el dominio sigue registrado a tu nombre. La analítica web sin cookies, recogida en el servidor, viene en todos los planes y muestra visitas, rutas, países y códigos de estado.

Los planes son de pago, desde R$12,49 al mes en el Hobby, y una aplicación web usa al menos 512 MB del pool de RAM del plan. Mira el hosting de sitios.