Por que 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: necesitabamos una web rapida, bien posicionada en buscadores, facil de mantener, y que nos permitiera reutilizar componentes del ecosistema React que ya teniamos. La pregunta era que herramienta usar.
La opcion obvia en 2024-2025 era Next.js. Lo conociamos bien, lo usabamos en otros proyectos, y su ecosistema es enorme. Pero Next.js tiene un problema fundamental para webs corporativas: esta diseñado para aplicaciones, no para sitios de contenido. Y esa diferencia importa mas de lo que parece.
Una web corporativa es, en esencia, un sitio de contenido. Paginas estaticas, articulos, casos de estudio, informacion de servicios. La interactividad se limita a formularios de contacto, alguna animacion, y quiza un widget de chat. El 95% de la pagina es HTML y CSS. No necesitas un runtime de JavaScript de 80KB ejecutandose en el navegador para renderizar texto estatico.
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 pagina. Para una aplicacion interactiva como un dashboard, tiene sentido. Para una pagina de “Quienes 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 opcion que descartamos pronto. En 2026, el proyecto esta en modo mantenimiento. Su sistema de plugins es fragil, los tiempos de build con grafos GraphQL complejos son impredecibles, y el ecosistema se ha estancado. No ibamos a apostar nuestra web corporativa en un framework sin futuro claro.
Lo que resuelve la arquitectura de islas de Astro
Astro toma una decision de diseño radical: por defecto, no envia JavaScript al navegador. Cero. El HTML se renderiza en build time y se sirve como HTML estatico. Si un componente necesita interactividad, lo marcas explicitamente con una directiva (client:load, client:visible, client:idle) y solo ese componente se hidrata. El resto de la pagina sigue siendo HTML puro.
Esto es lo que se llama arquitectura de islas (Islands Architecture): un oceano de HTML estatico 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 demas es HTML servido directamente.
El resultado es dramatico. Nuestra pagina principal carga con menos de 15KB de JavaScript total (incluyendo las islas interactivas). La misma pagina en Next.js requeria 120KB. No es una optimizacion marginal. Es un orden de magnitud de diferencia.
Pero lo mas 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 pagina responde antes. Y esto se traduce directamente en mejores metricas de Core Web Vitals, que a su vez impactan en el ranking de Google.
Numeros reales: Core Web Vitals
Hemos medido el antes y el despues con datos reales de campo (Chrome User Experience Report) y de laboratorio (Lighthouse, WebPageTest). Estos son los numeros de nuestra pagina principal:
| Metrica | Next.js (antes) | Astro (despues) | 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 bajo de 2.4 segundos a 0.9 segundos. Esto no es solo un numero bonito: Google considera que un LCP por debajo de 2.5 segundos es “bueno”, pero por debajo de 1.2 segundos estas en el percentil superior. Esa diferencia se nota en las impresiones organicas.
El Cumulative Layout Shift (CLS) bajo a practicamente cero porque no hay JavaScript reorganizando el layout despues de la carga inicial. Lo que renderiza el servidor es lo que ve el usuario, sin saltos.
Content Collections para contenido bilingue
Nuestra web es bilingue (español e ingles). Gestionar contenido bilingue en Next.js requeria una estructura de carpetas manual, un sistema de rutas personalizado, y logica de negocio para vincular traducciones entre si. Funcionaba, pero era fragil y cada nuevo contenido requeria tocar multiples 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 automaticamente 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 bilingue, 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 logica de routing genera las URLs correspondientes (/insights/slug para español, /en/insights/slug para ingles).
El resultado es que añadir un nuevo articulo es crear un archivo markdown con el frontmatter correcto y hacer push. No hay base de datos, no hay CMS, no hay panel de administracion. El contenido vive en el repositorio, se versiona con git, y se revisa con pull requests. Para un equipo tecnico, esto es infinitamente mas eficiente que cualquier CMS.
Experiencia de desarrollador
Este es el punto donde Astro nos sorprendio mas. Esperabamos mejor performance. No esperabamos 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, teniamos una libreria de componentes React que usabamos 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 paginas 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 friccion de crear contenido es minima.
Hot Module Replacement real. El servidor de desarrollo de Astro, alimentado por Vite, hace HMR instantaneo. 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 estas iterando sobre diseño y contenido, la velocidad del feedback loop cambia la calidad del resultado.
Los tradeoffs que aceptamos
Seria deshonesto presentar Astro como la solucion perfecta. Hay tradeoffs reales que evaluamos y aceptamos conscientemente.
Ecosistema mas pequeño. El ecosistema de plugins y herramientas de Astro es mas pequeño que el de Next.js. Para funcionalidades especificas (autenticacion, e-commerce, dashboards), Next.js tiene mas opciones maduras. Para una web corporativa de contenido, esto no nos afecta. Pero si tu proyecto tiene requisitos de aplicacion 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 documentacion oficial es excelente, pero cuando te sales del camino feliz, a veces estas solo. Esto esta mejorando rapidamente, pero en 2026 Next.js sigue teniendo una ventaja significativa en comunidad.
SSR limitado para contenido dinamico. Astro soporta Server-Side Rendering, pero no es su punto fuerte. Si necesitas paginas que cambien en cada request basandose en el usuario (dashboards, perfiles, contenido personalizado), Astro no es la herramienta correcta. Para contenido que cambia con cada deploy (articulos, paginas 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 aplicacion con login, estados complejos y comunicacion en tiempo real, usa un framework de aplicacion. Si es un sitio de contenido con islas de interactividad, Astro es probablemente la mejor opcion disponible hoy.
El resultado
Llevamos la web en Astro desde hace varios meses y los resultados hablan por si solos. Core Web Vitals en verde en todas las paginas. Tiempos de build de un solo digito. Contenido bilingue 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 teniamos.
La decision no fue facil porque implicaba salir de la zona de confort de Next.js. Pero para una web corporativa de contenido, Astro nos dio exactamente lo que necesitabamos: performance sin compromisos, SEO nativo, y una experiencia de desarrollador que no sacrifica productividad por rendimiento.
