Por qué elegimos Astro para nuestra web corporativa
El problema con los frameworks SPA para webs de contenido
Cuando nos planteamos reconstruir la web corporativa de abemon, el punto de partida era claro: necesitábamos una web rápida, bien posicionada en buscadores, fácil de mantener, y que nos permitiera reutilizar componentes del ecosistema React que ya teníamos. La pregunta era que herramienta usar.
La opción obvia en 2024-2025 era Next.js. Lo conocíamos bien, lo usábamos en otros proyectos, y su ecosistema es enorme. Pero Next.js tiene un problema fundamental para webs corporativas: está diseñado para aplicaciones, no para sitios de contenido. Y esa diferencia importa más de lo que parece.
Una web corporativa es, en esencia, un sitio de contenido. Páginas estáticas, artículos, casos de estudio, información de servicios. La interactividad se limita a formularios de contacto, alguna animación, y quizá un widget de chat. El 95% de la página es HTML y CSS. No necesitas un runtime de JavaScript de 80KB ejecutándose en el navegador para renderizar texto estático.
Con Next.js, incluso usando Server Components y Static Site Generation, el bundle de JavaScript base del framework ronda los 80-100KB comprimidos. Ese JavaScript se descarga, se parsea, y se ejecuta en cada carga de página. Para una aplicación interactiva como un dashboard, tiene sentido. Para una página de “Quiénes somos”, es un desperdicio. Y ese desperdicio tiene consecuencias directas en Core Web Vitals: mayor Largest Contentful Paint (LCP), mayor Time to Interactive (TTI), mayor Total Blocking Time (TBT).
Gatsby fue una opción que descartamos pronto. En 2026, el proyecto está en modo mantenimiento. Su sistema de plugins es frágil, los tiempos de build con grafos GraphQL complejos son impredecibles, y el ecosistema se ha estancado. No íbamos a apostar nuestra web corporativa en un framework sin futuro claro.
Lo que resuelve la arquitectura de islas de Astro
Astro toma una decisión de diseño radical: por defecto, no envía JavaScript al navegador. Cero. El HTML se renderiza en build time y se sirve como HTML estático. Si un componente necesita interactividad, lo marcas explícitamente con una directiva (client:load, client:visible, client:idle) y solo ese componente se hidrata. El resto de la página sigue siendo HTML puro.
Esto es lo que se llama arquitectura de islas (Islands Architecture): un océano de HTML estático con islas de interactividad donde realmente se necesita. En nuestra web, las islas son: el formulario de contacto, el selector de idioma, y el componente de cookies. Todo lo demás es HTML servido directamente.
El resultado es dramático. Nuestra página principal carga con menos de 15KB de JavaScript total (incluyendo las islas interactivas). La misma página en Next.js requería 120KB. No es una optimización marginal. Es un orden de magnitud de diferencia.
Pero lo más importante no es el tamaño del bundle. Es lo que implica para la experiencia del usuario. Con menos JavaScript, el navegador tiene menos trabajo. El contenido aparece antes. La página responde antes. Y esto se traduce directamente en mejores métricas de Core Web Vitals, que a su vez impactan en el ranking de Google.
Números reales: Core Web Vitals
Hemos medido el antes y el después con datos reales de campo (Chrome User Experience Report) y de laboratorio (Lighthouse, WebPageTest). Estos son los números de nuestra página principal:
| Métrica | Next.js (antes) | Astro (después) | Mejora |
|---|---|---|---|
| LCP | 2.4s | 0.9s | -62% |
| FID/INP | 120ms | 40ms | -67% |
| CLS | 0.08 | 0.01 | -87% |
| TBT | 350ms | 45ms | -87% |
| JS total | 118KB | 14KB | -88% |
| Lighthouse Score | 82 | 99 | +21% |
El LCP bajó de 2.4 segundos a 0.9 segundos. Esto no es solo un número bonito: Google considera que un LCP por debajo de 2.5 segundos es “bueno”, pero por debajo de 1.2 segundos estás en el percentil superior. Esa diferencia se nota en las impresiones orgánicas.
El Cumulative Layout Shift (CLS) bajó a prácticamente cero porque no hay JavaScript reorganizando el layout después de la carga inicial. Lo que renderiza el servidor es lo que ve el usuario, sin saltos.
Content Collections para contenido bilingüe
Nuestra web es bilingüe (español e inglés). Gestionar contenido bilingüe en Next.js requería una estructura de carpetas manual, un sistema de rutas personalizado, y lógica de negocio para vincular traducciones entre sí. Funcionaba, pero era frágil y cada nuevo contenido requería tocar múltiples archivos.
Astro tiene un sistema nativo llamado Content Collections que resuelve esto de forma elegante. Definimos un schema con Zod para cada tipo de contenido (insights, servicios, casos de estudio), y Astro valida automáticamente que cada archivo markdown cumple con el schema. Si falta un campo obligatorio o un tipo no coincide, el build falla con un error claro.
Para el contenido bilingüe, organizamos las colecciones con subdirectorios por idioma (/es/ y /en/), y el slug conecta las traducciones. Cada archivo markdown tiene un campo lang que determina su idioma, y la lógica de routing genera las URLs correspondientes (/insights/slug para español, /en/insights/slug para inglés).
El resultado es que añadir un nuevo artículo es crear un archivo markdown con el frontmatter correcto y hacer push. No hay base de datos, no hay CMS, no hay panel de administración. El contenido vive en el repositorio, se versiona con git, y se revisa con pull requests. Para un equipo técnico, esto es infinitamente más eficiente que cualquier CMS. Es parte de nuestra filosofía de desarrollo a medida aplicada incluso a nuestra propia infraestructura web.
Experiencia de desarrollador
Este es el punto donde Astro nos sorprendió más. Esperábamos mejor performance. No esperábamos que la experiencia de desarrollo fuera tan buena.
Componentes de cualquier framework. Astro permite usar componentes de React, Vue, Svelte o Solid en el mismo proyecto. En nuestro caso, teníamos una librería de componentes React que usábamos en otros proyectos. Pudimos reutilizarlos directamente en Astro sin reescribirlos. Los componentes que solo renderizan HTML (cards, layouts, secciones) se usan como componentes Astro puros (sin runtime). Los que necesitan interactividad (formularios, dropdowns) se importan como componentes React con la directiva client: correspondiente.
Velocidad de build. Astro usa Vite bajo el capó, y los tiempos de build son excelentes. Nuestra web completa (unas 80 páginas entre ambos idiomas) compila en menos de 8 segundos. Con Next.js, el build de un sitio similar tardaba entre 30 y 45 segundos. En un flujo de CI/CD donde cada push dispara un build, esa diferencia se acumula.
Markdown como ciudadano de primera clase. En Next.js, trabajar con markdown requiere instalar y configurar mdx, remark, rehype, y un puñado de plugins. En Astro, markdown funciona out of the box con soporte para frontmatter tipado, syntax highlighting, y componentes embebidos. La fricción de crear contenido es mínima.
Hot Module Replacement real. El servidor de desarrollo de Astro, alimentado por Vite, hace HMR instantáneo. Cambias un archivo markdown y ves el resultado en el navegador en menos de 100ms. Cambias un componente y lo mismo. No hay recargas completas, no hay esperas. Esto parece menor, pero cuando estás iterando sobre diseño y contenido, la velocidad del feedback loop cambia la calidad del resultado.
Los tradeoffs que aceptamos
Sería deshonesto presentar Astro como la solución perfecta. Hay tradeoffs reales que evaluamos y aceptamos conscientemente.
Ecosistema más pequeño. El ecosistema de plugins y herramientas de Astro es más pequeño que el de Next.js. Para funcionalidades específicas (autenticación, e-commerce, dashboards), Next.js tiene más opciones maduras. Para una web corporativa de contenido, esto no nos afecta. Pero si tu proyecto tiene requisitos de aplicación web interactiva, Astro puede quedarse corto.
Menos recursos de aprendizaje. Hay menos tutoriales, menos respuestas en Stack Overflow, y menos desarrolladores con experiencia en Astro. La documentación oficial es excelente, pero cuando te sales del camino feliz, a veces estás solo. Esto está mejorando rápidamente, pero en 2026 Next.js sigue teniendo una ventaja significativa en comunidad.
SSR limitado para contenido dinámico. Astro soporta Server-Side Rendering, pero no es su punto fuerte. Si necesitas páginas que cambien en cada request basándose en el usuario (dashboards, perfiles, contenido personalizado), Astro no es la herramienta correcta. Para contenido que cambia con cada deploy (artículos, páginas de servicios, landing pages), es ideal.
No es para aplicaciones. Astro no pretende reemplazar React, Vue o Next.js para aplicaciones interactivas. Es una herramienta de contenido. Si tu “web corporativa” es en realidad una aplicación con login, estados complejos y comunicación en tiempo real, usa un framework de aplicación. Si es un sitio de contenido con islas de interactividad, Astro es probablemente la mejor opción disponible hoy.
El resultado
Llevamos la web en Astro desde hace varios meses y los resultados hablan por sí solos. Core Web Vitals en verde en todas las páginas. Tiempos de build de un solo dígito. Contenido bilingüe gestionado con git. Componentes React reutilizados sin coste de runtime. Y un equipo de desarrollo que puede iterar sobre contenido y diseño con una velocidad que antes no teníamos.
La decisión no fue fácil porque implicaba salir de la zona de confort de Next.js. Pero para una web corporativa de contenido, Astro nos dio exactamente lo que necesitábamos: performance sin compromisos, SEO nativo, y una experiencia de desarrollador que no sacrifica productividad por rendimiento. Si te planteas una decisión similar entre frameworks o entre construir vs comprar, el criterio clave es el mismo: elige la herramienta que mejor encaje con el problema, no la más popular.
