Por qué Astro y no Next.js
La pregunta clásica del 2024-2026: «¿qué uso para mi sitio web nuevo?». La respuesta industry-default ha sido «Next.js, porque todos lo usan». Y por eso muchos proyectos arrancan con un framework sobredimensionado para lo que realmente necesitan.
Astro nace del lado contrario: content-first, server-rendered por defecto, JavaScript opt-in vía islands. Si tu sitio es un blog, un directorio, una landing comercial, un sitio corporativo con muchas páginas, un proyecto pSEO con cientos de URLs — Astro lo hace mejor, más rápido, más barato y con menos código.
Cuando el caso es realmente una app SPA con estado complejo (CRM, dashboard intensivo, editor colaborativo), Next.js encaja mejor. Pero el 70% de los sitios que se construyen hoy NO son apps; son sitios de contenido pretendiendo serlo.
◆ Verdict de operador. Astro es el default correcto para sitios que tienen que rankear, cargar rápido y mantener bajo coste. Para apps reales sigue habiendo casos para Next/Remix. Pero ChefBusiness Group construyó 6 sitios en Astro y no se arrepiente.
Para qué sirve y para qué no
Para qué SÍ
- Sitios content-first donde el SEO y el TTFB son métricas críticas. Blogs, directorios, landings, corporate.
- Proyectos pSEO generando 50-5000 páginas desde collections tipadas. ChefBusiness tiene ~1.139 páginas Astro.
- Sitios con MDX donde necesitas componentes embebidos en el contenido (este directorio que estás leyendo).
- Mezcla de frameworks UI — un mismo sitio con React + Svelte + Vue + Solid si tu caso lo justifica.
- Hosting cero-config en Netlify, Vercel, Cloudflare Pages. Build estático brutal de rápido.
Para qué NO
- Apps web ricas con estado complejo persistente. Notion, Figma, Linear no se construirían con Astro.
- Casos de server actions intensivas donde la cohesión de Next App Router (form actions + RSC + streaming) compensa.
- Equipos sin experiencia Vite ni con frameworks modernos. La curva inicial existe.
- Cuando el sitio es 90% interactividad cliente y el SEO es secundario.
Encaje en stack StratoAI
| Línea StratoAI | Cómo se usa |
|---|---|
| MicroSaaS | Default para producto del cliente cuando es content-first o tiene mucho landing/marketing. |
| Consultor IA | Las landings hiperlocales del propio sitio StratoAI son Astro con collections geolocalizadas. |
| Transversal | 6+ sitios del grupo en Astro. Es la elección por defecto cuando no hay razón fuerte para Next. |
Pricing real (2026-05)
- Astro framework · gratis, open-source MIT.
- Hosting · cero coste en Netlify/Vercel/Cloudflare Pages para tier gratuito hasta cierto volumen.
- Coste real para 1 sitio Astro de StratoAI = el coste del hosting (Netlify Pro 19$/mes para sitios serios) + dominio + APIs externas si las usas. Suele ser menor de 30€/mes total.
Alternativas reales
| Alternativa | Cuándo elegirla en lugar de Astro |
|---|---|
| Next.js | Apps reales con estado complejo. Server actions intensivas. Vercel-first stack. |
| SvelteKit | Si tu equipo prefiere Svelte y el caso encaja con su filosofía full-stack. |
| Remix | Apps con énfasis en formularios, mutations server-driven, progressive enhancement. |
| Eleventy | Si quieres static-only sin runtime JavaScript en absoluto. Más austero, menos productivo. |
| Hugo | Performance bruta para blogs masivos. Menos flexibilidad, pero builds en milisegundos. |
Casos de uso reales en ChefBusiness Group + StratoAI
- stratoai.pro (este sitio) · Astro 6 + CSS vanilla con tokens · 14 páginas + content collections.
- chefbusiness.co · Astro 5 + Tailwind v4 + pnpm · ~1.139 páginas (i18n EN, pSEO, barrios, tipos, tools).
- hosply.pro · Astro · 548 páginas, directorio HORECA con 362 proveedores enriquecidos vía Firecrawl + Gemini.
- gastroseo.com · Astro 5 · 890 páginas, sprint territorial 57 ciudades + clusters blog.
- directorio-catering · Astro 5 fork de gastroconsultores (~80% reutilizable, ~2.800 páginas objetivo).
- elcanaveral.info · Astro · directorio hiperlocal barrio El Canaveral, Madrid.
◇ Regla de uso operativo. Para sitios serios: Astro 5+ con TypeScript + content collections tipadas + MDX para contenido enriquecido + CSS vanilla con tokens (NO Tailwind si el equipo es 1 operador, sí Tailwind si va a colaborar). Hosting Netlify por defecto. Build hooks para rebuilds programados desde n8n.
