Por qué recomendamos Astro para webs de marketing (y cuándo no)

Una web de marketing tiene dos trabajos: posicionar en Google y convertir visitas. La mayoría de los stacks comprometen ambos. Reconstruimos atico3.com en Astro hace un año. El Lighthouse móvil está en 90, el de escritorio en 99, y actualizar contenido es más rápido que el sitio en PHP que tenía antes.

Aquí están los casos en los que Astro es la decisión correcta. Y los casos en los que no.

Qué es Astro

Astro es un framework de sitios estáticos que envía cero JavaScript por defecto. Escribes componentes en React, Vue, Svelte o su propia sintaxis .astro. En tiempo de build genera HTML. Las partes interactivas (un calendario, un buscador, un formulario) cargan JS solo en los elementos que lo necesitan.

El contraste importa. Una página de Next.js se hidrata con React al cargar: 80–120 KB de JavaScript runtime, incluso para una landing estática. Los temas de WordPress envían su propio runtime más lo que añade el page builder. Astro renderiza la misma página sin runtime de framework. Cualquier JavaScript en tu página es lo que tú elegiste añadir: una etiqueta de analítica, una librería de animaciones, un widget de formulario. Pagas solo por lo que activaste, no por la sobrecarga de hidratación.

Si tu web de marketing gasta el 80% de su presupuesto de JavaScript hidratando elementos que nunca cambian, estás pagando por nada.

Para un portafolio, una página de SaaS, un blog o una colección de casos de estudio: el 95% del contenido no cambia entre sesiones. Hidratarlo en cada carga es sobrecoste.

Cuándo Astro es la decisión correcta

El rendimiento es un KPI medible

Si trabajas en B2B SaaS y una web móvil lenta te hace perder leads, Astro elimina la mayor parte del trabajo. El Lighthouse Performance, los Core Web Vitals y el Time to Interactive mejoran cuando dejas de enviar JS innecesario. Subimos el Lighthouse móvil de atico3.com de 63 a 90 en una tarde corrigiendo cabeceras de caché, retrasando Google Tag Manager y optimizando la imagen LCP. Nada de ese trabajo es específico de Astro. Es el tipo de pasada que hacemos también en webs de clientes. Pero Astro no te complica esa parte.

El contenido es mayoritariamente estático o gestionado por CMS

Casos de estudio, posts de blog, landing pages, tablas de precios. Las content collections de Astro gestionan las formas habituales (Markdown con frontmatter, esquemas tipados, glob loaders) sin dependencias externas. Añade Sanity o Contentful cuando tu equipo de contenido pase de dos o tres redactores.

El SEO importa y no estás detrás de un app-shell

Astro emite HTML semántico limpio en el primer byte. Google lo indexa igual que un blog de 2005. AI Overviews y las citaciones de ChatGPT interpretan el HTML renderizado en servidor con más fiabilidad que páginas hidratadas con JS. Si parte de tu estrategia de tráfico es que los LLMs te citen, esto es innegociable.

Quieres islas, no SPAs completas

¿Necesitas un widget de reservas, un buscador, una calculadora de precios interactiva? Astro te deja meter un componente React, Vue o Svelte en una sección sin convertir el sitio entero. El resto de la página sigue siendo estática.

Estás programando con asistencia de IA

Esta es la razón práctica por la que mencionamos Astro junto a React y Next.js. Astro tiene una API más pequeña y menos magia que Next.js. Los asistentes de IA generan código Astro funcional al primer intento más veces que con Next.js, donde los casos límite con server components, el app router y el comportamiento de caché producen bugs sutiles. Para equipos pequeños que usan IA para comprimir plazos, esa diferencia es real.

Cuándo Astro no es la decisión correcta

Astro es la decisión equivocada cuando tu web de marketing es la propia app.

Tu web de marketing es la app

Si tu homepage es un dashboard, tiene rutas autenticadas, actualizaciones en tiempo real o un flujo de usuario complejo, usa Next.js o Remix. Astro puede cubrir parte de esto con adaptadores, pero lucharás contra el framework en cada funcionalidad.

Tu equipo solo trabaja en React y no quiere aprender .astro

La sintaxis .astro es básicamente HTML con expresiones de JavaScript. La curva de aprendizaje es de una semana para un desarrollador React. Pero si tienes un único ingeniero que se resiste, no insistas. Una web enviada en Next.js es mejor que una web bloqueada en debates de framework.

Necesitas personalización en edge o A/B testing a escala

Edge middleware, personalización en servidor, feature flags complejos. Es posible con adaptadores de Astro (Netlify, Vercel, Cloudflare), pero la integración es más rugosa que en Next.js. Si vives en Vercel y usas sus herramientas de split-test a diario, quédate ahí.

Cómo decidir para tu proyecto

El framework que encaja suele ser obvio en cuanto dejas de confundir “web de marketing” con “app”.

Tres preguntas en orden. Párate en la primera que se resuelva.

1. ¿Esta web va a crecer hasta convertirse en un producto con login o un dashboard? Si la respuesta es sí, usa Next.js o Remix. Las páginas de marketing pueden vivir en la misma aplicación, o correr aparte en Astro y aprovechar despliegues independientes.
2. ¿La web de marketing va a tener más de ~10 páginas con layout compartido y requisitos de SEO? Usa Astro.
3. ¿Es una única landing sin actualizaciones de contenido previstas? Sirve cualquier cosa. Astro sigue siendo lo más pequeño y rápido, pero una página en Framer se publica antes si no tienes equipo de desarrollo.

Las primeras dos preguntas cubren la mayoría de los casos.

La razón real por la que esto importa

Una web de marketing es una herramienta de ventas. Cada segundo de carga cuesta leads. Cada error de JavaScript en la consola cuesta confianza. Cada alerta de seguridad de WordPress cuesta la tarde de un ingeniero. Elegir el framework correcto no es una preferencia del desarrollador. Es una decisión de negocio que se compone durante años.

Para la mayoría de webs de marketing, esa decisión es Astro.