
WordPress no es la única forma de hacer una web. Ni siquiera es la mejor para muchos proyectos donde mandan el contenido, la velocidad y el SEO. Para esos, nosotros usamos Astro. La respuesta corta es esa. La larga es este artículo.
Astro es un framework web pensado para sitios donde el contenido, el rendimiento y el SEO pesan más que una interfaz completamente interactiva. Renderiza los componentes como HTML y CSS y solo envía JavaScript al navegador cuando una parte de la página lo necesita.
Ese matiz importa. Astro no hace rápida una web por arte de magia. Lo que hace es facilitar una arquitectura con menos JavaScript innecesario. Luego todavía hay que optimizar imágenes, fuentes, scripts externos, caché y servidor. El framework tampoco recoge la cocina después de cenar.
¿Te suena eso de las «islas»? Es el nombre que la documentación de Astro da a su patrón: la página llega como HTML generado en el servidor o durante la construcción, y solo algunas zonas concretas —una calculadora, un carrusel, un buscador— se hidratan en el navegador. El resto de la página nunca se convierte en una aplicación JavaScript.
La documentación oficial de Astro explica que los componentes se renderizan como HTML y CSS por defecto. Las directivas client:* activan JavaScript únicamente en las islas que lo requieren.
En THECOOKIES usamos Astro cuando queremos controlar el HTML entregado, reducir dependencias en el navegador y separar el contenido de la presentación. En nuestro stack habitual lo conectamos con Sanity: el equipo edita contenido en el CMS y Astro construye la experiencia pública. La web donde estás leyendo esto funciona exactamente así.
Esta separación tiene cuatro ventajas prácticas:
Son ventajas de arquitectura. No garantizan por sí solas mejores Core Web Vitals ni posiciones en Google.
Webs corporativas, medios, documentación, portfolios y ecommerce con una capa de contenido importante. En general, cualquier sitio donde la mayoría de las páginas son informativas y solo algunos elementos necesitan interacción.
También permite integrar componentes de React, Vue, Svelte y otros frameworks. Esto resulta útil cuando un proyecto necesita una interfaz específica sin enviar el runtime de toda la aplicación en cada página.
¿Tu proyecto es en realidad una aplicación? Ahí cambia la cosa. No elegiríamos Astro por defecto para una interfaz que cambia constantemente en el navegador: un panel operativo complejo, un editor visual o una herramienta colaborativa pueden encajar mejor en un framework centrado en aplicaciones.
Tampoco lo elegiríamos si el equipo solo domina otro stack y la migración no aporta una mejora medible. Cambiar de tecnología porque está de moda es una forma bastante cara de coleccionar logos.
Astro, WordPress y Next.js resuelven problemas distintos, así que la comparación debe partir del proyecto y no de la herramienta.
| Opción | Punto fuerte | Coste operativo habitual |
|---|---|---|
| Astro + CMS headless | Rendimiento y control del frontend | Requiere desarrollo |
| WordPress | Edición y ecosistema de plugins | Más actualizaciones y compatibilidades |
| Next.js | Aplicaciones React y renderizado híbrido | Más runtime y complejidad potencial |
Una web en WordPress bien construida puede rendir mejor que una web en Astro mal implementada. La tecnología marca el techo y los riesgos. La ejecución determina el resultado.
Con datos de la web terminada, no con porcentajes universales. Revisamos el JavaScript transferido, el peso de imágenes, las peticiones de terceros, los Core Web Vitals de usuarios reales y la facilidad con la que el equipo publica contenido.
¿Significa todo esto que deberías migrar tu web a Astro? Depende de tu proyecto, y desconfía de quien te lo afirme sin mirarlo. En nuestra página de servicios web contamos cómo conectamos estas decisiones técnicas con captación y mantenimiento. El framework es una pieza. La web sigue necesitando arquitectura, contenido, analítica y alguien que la cuide.
También te puede gustar