Cómo elegir un generador de sitios estáticos para proyectos JavaScript
Elegir el generador de sitios estáticos equivocado te cuesta más que tiempo. Define tu modelo de despliegue, la complejidad en tiempo de ejecución y la cantidad de JavaScript que termina llegando a tus usuarios. En 2026, las opciones han madurado considerablemente, pero también han divergido de maneras que importan. Aquí te explico cómo razonar la elección.
Puntos clave
- Los verdaderos SSG como Astro 6 y Eleventy 3 difieren fundamentalmente de los frameworks híbridos como Next.js, Nuxt y SvelteKit — tratarlos como intercambiables lleva a malas decisiones arquitectónicas.
- Astro 6 es una de las opciones por defecto más sólidas para sitios con mucho contenido en 2026, gracias a su arquitectura de islas y al soporte de componentes de múltiples frameworks.
- La Adapter API estable de Next.js 16 y OpenNext hacen viable el despliegue multiplataforma, pero sigue arrastrando más complejidad de framework que Astro o Eleventy, incluso para salidas mayormente estáticas.
- Empieza por los requisitos de renderizado e infraestructura, no por la popularidad del framework, al seleccionar una herramienta.
No todos los “SSG” son lo mismo
Antes de comparar herramientas, conviene ser preciso con las categorías. Astro 6 y Eleventy 3 son genuinamente generadores de sitios estáticos enfocados en contenido. Están diseñados para producir una salida con JavaScript mínimo y priorizar el renderizado en tiempo de compilación.
Next.js 16, Nuxt 4 y SvelteKit son frameworks híbridos que admiten salida estática, pero no son principalmente SSG. Su modelo mental por defecto son las aplicaciones renderizadas en servidor o desplegadas en el edge. Usarlos puramente para generación estática es válido, pero seguirás cargando con sustancialmente más complejidad de framework que con una herramienta verdaderamente static-first.
Tratar a estos dos grupos como equivalentes lleva a malas decisiones.
Análisis framework por framework
Astro 6 se ha convertido en una de las opciones más sólidas para sitios con mucho contenido y portales de documentación. Su arquitectura de islas envía cero JavaScript por defecto, con interactividad opcional por componente. Astro 6 admite componentes de React, Vue, Svelte y Solid en el mismo proyecto. Si tu principal preocupación es el rendimiento del contenido y quieres flexibilidad de framework, Astro es la recomendación más clara en 2026.
Eleventy 3 sigue siendo la herramienta adecuada cuando quieres simplicidad y control sin la sobrecarga de un framework. Admite múltiples lenguajes de plantillas, tiene tiempos de compilación rápidos y produce HTML limpio. Eleventy 3 incorporó soporte completo de ESM y configuración asíncrona. No está obsoleto — es deliberadamente minimalista, que es exactamente lo que algunos proyectos necesitan.
Next.js 16 introdujo una Adapter API estable que mejora significativamente el soporte de despliegue multiplataforma, incluyendo OpenNext, que permite desplegar Next.js en Cloudflare, AWS Lambda y otros runtimes que no sean Vercel. Si tu equipo trabaja nativamente con React y el proyecto involucra una mezcla de páginas estáticas, rutas de API y componentes de servidor, Next.js sigue siendo la opción más capaz. Solo ten claro que estás ejecutando un framework completo, no un SSG puro.
Nuxt 4 aporta la misma capacidad híbrida al ecosistema Vue. Su generación estática mediante nuxt generate es sólida y se integra limpiamente con plataformas CMS headless. Para equipos Vue que construyen sitios de marketing o aplicaciones orientadas a contenido que pueden necesitar funcionalidades de servidor más adelante, Nuxt 4 es la opción natural.
SvelteKit con adapter-static funciona bien para equipos Svelte que construyen sitios mayoritariamente estáticos. El adaptador produce salida completamente estática, pero el framework asume un modelo server-first, por lo que algunas funcionalidades requieren soluciones alternativas en modo estático puro. Es una buena opción cuando el equipo ya conoce Svelte y el proyecto es ligero.
Gatsby todavía existe y recibe actualizaciones tras la adquisición por parte de Netlify, pero el impulso del ecosistema que lo convirtió en el SSG por defecto para React se ha desplazado en gran medida hacia Astro y Next.js. La capa de datos GraphQL de Gatsby sigue siendo útil para mallas de contenido complejas, pero ya no es el punto de partida obvio para nuevos proyectos estáticos en React.
Docusaurus es la opción práctica por defecto para sitios de documentación respaldados por equipos grandes o proyectos open source. Está basado en React, mantenido por Meta, y maneja versionado, i18n y búsqueda de fábrica. Para un desarrollador en solitario o un equipo pequeño que construye documentación, el tema Starlight de Astro es una alternativa más ligera que vale la pena considerar.
Un marco de decisión sencillo
| Tipo de proyecto | Herramienta recomendada |
|---|---|
| Sitio de contenido, blog, marketing | Astro 6 |
| Portal de documentación | Docusaurus o Astro Starlight |
| Sitio con poco JS, basado en plantillas | Eleventy 3 |
| App React con necesidades estáticas + servidor | Next.js 16 + OpenNext |
| App Vue con renderizado híbrido | Nuxt 4 |
| Equipo Svelte, sitio ligero | SvelteKit adapter-static |
Discover how at OpenReplay.com.
Consideraciones de despliegue y hosting
Tu destino de hosting importa. Astro y Eleventy producen archivos estáticos planos que se despliegan en cualquier lugar — Netlify, Cloudflare Pages, S3 o tu propio servidor. Next.js 16 con OpenNext ha mejorado significativamente para despliegues fuera de Vercel, pero todavía requiere más configuración que una salida estática verdadera. Nuxt y SvelteKit tienen consideraciones similares.
Si apuntas a Cloudflare Pages o necesitas un despliegue edge-native, Astro y Eleventy te ofrecen la menor fricción. Si necesitas ISR o componentes de servidor, estás en territorio de framework híbrido, sin importar cuál elijas.
La pregunta correcta que debes hacerte primero
No empieces por “qué framework es el más popular”. Empieza por: ¿Cuánto JavaScript necesita realmente este proyecto en tiempo de ejecución, y cuánta infraestructura de servidor estoy dispuesto a gestionar?
Si la respuesta es “JavaScript mínimo, sin servidor”, Astro 6 o Eleventy 3 te servirán mejor que un framework híbrido configurado para actuar como uno. Si la respuesta involucra rutas dinámicas, autenticación o personalización, Next.js 16 o Nuxt 4 te dan margen para crecer sin cambiar de herramienta a mitad del proyecto.
Conclusión
El mejor SSG para tu proyecto es el que se ajusta a tus requisitos de renderizado — no el que tiene más estrellas en GitHub. Sé honesto sobre cuánta interactividad, lógica de servidor e infraestructura necesita realmente tu proyecto, y luego elige la herramienta más ligera que satisfaga esas necesidades. Un sitio de contenido no necesita un framework híbrido, y una aplicación con autenticación y rutas dinámicas no estará bien servida por un SSG puro. Ajusta la herramienta a la carga de trabajo y te ahorrarás meses de pelear contra tu propio stack.
Preguntas frecuentes
En su mayor parte, sí. El contenido en Markdown y MDX normalmente se traslada con cambios mínimos, ya que Astro admite ambos de forma nativa. El trabajo más arduo es reemplazar la capa de datos GraphQL de Gatsby con las content collections de Astro y reescribir los componentes de página de React como componentes Astro. Planifica una migración gradual en lugar de una reescritura única, y espera que el reemplazo de plugins tome la mayor parte del tiempo.
Generalmente sí. Next.js carga más complejidad de framework incluso cuando solo necesitas una salida mayormente estática, lo que significa bundles más grandes y más complejidad de compilación de lo necesario. Para un blog o sitio de marketing sin autenticación, rutas dinámicas o lógica de servidor, Astro 6 o Eleventy 3 normalmente producirán sitios más rápidos con menos configuración y un despliegue más simple.
Sí. Astro admite componentes de React, Vue, Svelte y Solid directamente, y puedes colocar componentes React existentes en páginas Astro con cambios mínimos. El cambio clave es decidir qué componentes necesitan hidratación del lado del cliente usando directivas como client:load o client:visible. Los componentes sin esas directivas se renderizan a HTML estático en tiempo de compilación, enviando cero JavaScript.
Menos que antes. La Adapter API estable en Next.js 16 y proyectos como OpenNext han hecho práctico desplegar Next.js en Cloudflare, AWS Lambda y otros runtimes. Dicho esto, algunas funcionalidades específicas de Vercel todavía funcionan mejor en Vercel. Si la independencia de plataforma es un requisito estricto, evalúa el uso de funcionalidades contra el soporte del adaptador desde el principio del proyecto.
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.
