Un cliente me llamó a principios de 2023, un editor de medios ejecutando alrededor de 14,000 posts en WordPress, un tema armado a través de cuatro desarrolladores durante seis años, y una puntuación de Core Web Vitals que era genuinamente vergonzosa. Su LCP estaba llegando a 7.2 segundos en móvil. Habían probado WP Rocket, habían probado un CDN, incluso habían quitado la mitad de sus plugins. Seguía lento. El problema no era WordPress en sí. Era que cada renderizado de página pasaba por PHP, un tema inflado, y una cadena de consultas de base de datos que no se había revisado desde 2018.
Punto clave: WordPress sin interfaz con Astro es el punto óptimo para sitios de contenido: wp-admin para editores, front end estático y rápido para visitantes, y WPGraphQL conectando ambos.
Ese fue el momento en que me comprometí adecuadamente con una configuración sin cabeza usando Astro como frontend. No porque sea de moda, sino porque para un sitio que maneja miles de posts con contenido editorial pesado, era la única arquitectura que tenía sentido.
Aquí está exactamente cómo lo configuré. Los compromisos, la configuración real, las partes que me causaron problemas.
---
¿Por qué Astro y no Next.js?
Me hacen esta pregunta seguido. Next.js es la respuesta obvia si ya tienes un equipo pesado en React o necesitas interactividad compleja del lado del cliente. Pero ¿para sitios con mucho contenido? Astro gana, y no es particularmente cercano.
Astro envía cero JavaScript por defecto. Para un blog, un sitio de noticias, o un portal de documentación, ese es el defecto correcto. Optas por JavaScript donde lo necesitas, en lugar de optar por no usar un bundle de React de 200kb que principalmente no quieres. Los docs de Astro sobre hidratación parcial, lo llaman arquitectura de Islas, lo explican mejor de lo que puedo en una frase, pero la versión corta es: solo los bits interactivos obtienen JS. El cuerpo del artículo, el encabezado, la barra lateral. HTML estático.
Construí un sitio de contenido legal a finales de 2022 con Next.js y WordPress. Lo suficientemente rápido, pero el cliente seguía preguntando por qué su puntuación de Lighthouse era 74 en móvil cuando "se supone que ahora es rápido". Sobrecarga de hidratación. Con Astro, ese mismo tipo de sitio ahora rutinariamente alcanza 95-98. No es jactancia, es solo lo que la arquitectura te da gratis.
Lo que Astro No Hace Bien
Vale ser honesto. Si tu sitio necesita personalización en tiempo real, un carrito de compras pesado, o cualquier cosa que realmente dependa del estado del cliente en muchos componentes, Astro empieza a sentirse incómodo. No es una app React. El patrón Islands es poderoso, pero es un modelo mental diferente que construir SPAs. Intenté forzar un dashboard del cliente en un proyecto Astro a mediados de 2023 y terminé revirtiendo a Next.js en dos semanas. Sabe qué estás construyendo.
---
Configurando WordPress como un Headless CMS
WordPress es genuinamente un buen backend headless. El WP REST API viene en core, está bien documentado, y tu equipo editorial no tiene que aprender nada nuevo. Ese último punto importa más de lo que los desarrolladores generalmente admiten.
Aquí está la configuración que uso:
- Instala WordPress en un subdominio, yo uso cms.yourdomain.com o api.yourdomain.com. Mantenlo detrás de autenticación básica o como mínimo restringe el tráfico público directo. El frontend es yourdomain.com. Dos deployments separados.
- Instala el plugin [WPGraphQL](https://www.wpgraphql.com/), prefiero GraphQL sobre REST para sitios de contenido porque puedes co-ubicar tus consultas con tus componentes y obtener exactamente los campos que necesitas. Sin sobre-obtención. La API REST está bien, pero una vez que tienes 15+ campos personalizados por tipo de post, el enfoque GraphQL es notoriamente más limpio.
- Instala Advanced Custom Fields (ACF) y la extensión WPGraphQL para ACF. Esta combinación es lo que hace que WordPress sea genuinamente flexible como modelo de contenido sin cabeza, puedes definir datos estructurados por tipo de post, exponerlos a través de GraphQL, y Astro los consume de manera limpia.
- Desactiva comentarios, emojis y el XML-RPC predeterminado si aún no lo has hecho. Estos añaden sobrecarga y superficie de ataque que no necesitas.
- Establece los permalinks en algo sensato antes de empezar a construir. Cambiarlos a mitad del proyecto cuando tus rutas de Astro ya están configuradas es genuinamente problemático.
Una cosa que confunde a la gente: CORS. Por defecto, WordPress no permitirá que tu servidor de desarrollo de Astro (corriendo en localhost:4321) haga solicitudes a tu instalación de WP. Añade esto a tu functions.php del tema o a un pequeño plugin utilitario durante el desarrollo:
`` add_action('init', function() { header("Access-Control-Allow-Origin: *"); }); ``
Ajusta eso a orígenes específicos en producción. Obviamente.
---
La Estructura del Proyecto Astro
Mantengo esto con opinión y consistencia en todos los proyectos. Después de una docena o más de construcciones headless, esto es lo que funciona:
`` src/ components/ layouts/ pages/ index.astro blog/ [slug].astro lib/ wpgraphql.ts ← toda la lógica de consultas WP vive aquí styles/ ``
El archivo lib/wpgraphql.ts es donde centralizo cada obtención de GraphQL. Sin llamadas fetch en línea dispersas en archivos de página. Cada consulta es una función async nombrada y exportada. Debugging de esto en 14,000 posts cuando algo se rompe a las 2am, te lo agradecerás después.
Obteniendo Posts en Tiempo de Compilación
getStaticPaths de Astro es tu pan de cada día aquí. Para un blog con miles de posts:
`` export async function getStaticPaths() { const posts = await getAllPostSlugs(); // llama a WPGraphQL return posts.map(post => ({ params: { slug: post.slug }, })); } ``
getAllPostSlugs pagina a través de WPGraphQL usando cursores after, la capa GraphQL de WordPress devuelve 100 posts por solicitud por defecto, así que para 14,000 posts estás haciendo 140 solicitudes en tiempo de compilación. Eso suena aterrador. En la práctica, en un servidor decente, la compilación completa se ejecuta en aproximadamente 4-5 minutos. Perfectamente aceptable para un sitio que se reconstruye unas pocas veces al día.
---
Manejando Imágenes Sin Perder la Cabeza
Este es el detalle que nadie menciona lo suficiente. WordPress almacena URLs de imágenes que apuntan a tu subdominio CMS. Cuando Astro construye estáticamente, esas imágenes siguen viviendo en cms.tudominio.com, lo que significa que los navegadores de tus visitantes están obteniendo imágenes desde tu servidor WordPress, potencialmente omitiendo tu CDN.
Algunas formas en que manejo esto:
- Cloudflare frente a ambos dominios. La opción más simple. Proxy de yourdomain.com y cms.yourdomain.com a través de Cloudflare, configura caché agresivo en /wp-content/uploads/*, y estás más o menos bien.
- Usa un plugin de descarga de medios. Me gusta WP Offload Media, traslada las cargas a S3 (o almacenamiento compatible) y reescribe las URLs automáticamente. Este es el enfoque que uso para cualquier sitio que espere tráfico serio. Tu servidor WordPress deja de servir imágenes completamente.
- El componente Image de Astro. Para imágenes que controlas en el momento de la construcción (imágenes destacadas obtenidas vía GraphQL), puedes pasar la URL remota al componente <Image> de Astro y él las optimizará, redimensionará y servirá desde tu salida de construcción. Funciona de maravilla. No funciona para imágenes incrustadas en el HTML del cuerpo del post, eso requiere un procesamiento diferente.
Seahawk tuvo un cliente de contenido de viajes el año pasado, alrededor de 8,000 posts, extremadamente pesado en imágenes, promedio de 12 imágenes por artículo. El servidor WordPress estaba siendo golpeado puramente por solicitudes de imágenes incluso con la configuración headless. Cambiar a S3 + CloudFront redujo su ancho de banda de origen en un 94%. Genuinamente transformador para su factura de hosting.
---
Compilaciones Incrementales y el Problema de la Reconstrucción
Aquí hay un problema real con la generación estática a escala: tu editor publica una corrección de post a las 3pm y tiene que esperar 5 minutos por una reconstrucción completa. Eso no es aceptable en una sala de redacción.
Algunos enfoques que he usado:
Opción 1: Netlify o Vercel con ISR bajo demanda. Astro soporta renderizado del lado del servidor con adaptadores, puedes ejecutar Astro en modo híbrido donde la mayoría de páginas son estáticas pero rutas específicas se renderizan bajo demanda. Para un sitio de noticias, frecuentemente prerenderizaré estáticamente los últimos 30 días de posts (tráfico alto, necesita velocidad) y estableceré páginas de archivo más antiguas para que se rendericen bajo demanda. Lo mejor de ambos mundos.
Opción 2: Compilaciones parciales disparadas por webhook. WordPress dispara un webhook al guardar un post (fácil con el plugin WP Webhooks). Ese webhook llama a un hook de despliegue de Netlify o Vercel. La compilación se ejecuta, obtiene solo lo que cambió. No es realmente parcial, Astro aún reconstruye todo, pero si mantienes tu compilación rápida, 4 minutos es manejable.
Opción 3: Solo usa SSR para todo. Despliega Astro con el adaptador Node en un VPS (uso Hetzner para esto, barato, rápido, confiable). Cada página se renderiza bajo demanda, cacheas agresivamente en el nivel de Nginx o Cloudflare, y tienes actualizaciones de posts instantáneas. Esto es lo que haría para una operación de publicación adecuada de más de 50,000 posts.
¿Mi opinión honesta? La mayoría de los sitios no necesitan la complejidad de la Opción 1 o 3. Un rebuild de 4 minutos disparado por un webhook está bien para el 90% de los sitios de contenido.
---
Desempeño: Lo que realmente obtienes
En el proyecto del editor del principio, esto es lo que sucedió después de la migración a Astro:
- LCP cayó de 7.2s a 1.1s en móvil (probado con WebPageTest desde un nodo en Londres)
- Total Blocking Time pasó de ~800ms a 0ms (cero JS por defecto, recuerda)
- Su reporte de Core Web Vitals de Google Search Console fue de 3% de URLs "Buenas" a 91% "Buenas" dentro de seis semanas del despliegue
- Los costos de hosting bajaron porque su servidor WordPress ya no servía páginas, solo respuestas de API
Nada de eso es magia. Es solo lo que ocurre cuando quitas el renderizado de PHP de la ruta crítica y dejas de enviar un bundle de JavaScript de tema de 400kb a cada lector.
---
Los detalles que te van a complicar
Hablando con sinceridad, cosas que he tenido que depurar en proyectos reales:
- Vistas previas de borradores. Esto es genuinamente molesto en una configuración headless. La vista previa nativa de WordPress depende de la representación del frontend. Necesitas construir un endpoint de vista previa personalizado en Astro que acepte un nonce de vista previa de WordPress y obtenga el borrador a través de WPGraphQL. No es difícil, pero toma un día hacerlo correctamente.
- Redirecciones. Si el sitio antiguo tenía cientos de redirecciones en .htaccess, ahora viven en el servidor de WordPress. Necesitas replicarlas en la configuración de Astro, o mantener WordPress accesible y hacer proxy de rutas específicas. He hecho ambas cosas. Replicar en Astro es más limpio a largo plazo.
- Búsqueda. La búsqueda integrada de WordPress es inútil en una configuración headless. Yo uso Algolia con el plugin WP Search with Algolia. Indexa tus posts en WP, consulta Algolia desde un componente Island de Astro. Funciona bien.
- Menús y navegación. Los menús de WordPress son extrañamente complicados de exponer a través de WPGraphQL. La ruta wpgraphql-acf frecuentemente resulta ser más limpia, solo modela tu navegación como un repetidor ACF y listo.
---
FAQ
¿Necesito WPGraphQL o puedo usar el REST API?
Puedes usar el REST API sin problema, está integrado en WordPress core y no requiere plugins adicionales. Para sitios simples con tipos de post estándar y campos personalizados mínimos, funciona bien. Donde GraphQL se justifica es cuando tienes modelos de contenido complejos con muchos campos personalizados por tipo. Poder obtener exactamente los campos que necesitas en una sola solicitud, sin luchar contra parámetros _embed y llamadas REST anidadas, te ahorra tiempo en cada consulta que escribes. La decisión es tuya. Solo encuentro GraphQL más limpio a partir de cierto nivel de complejidad.
¿Cómo manejo la autenticación de WordPress para contenido solo para miembros?
La autenticación JWT es el enfoque estándar. Instala el plugin JWT Authentication for WP REST API, genera tokens en el login, pásalos en los headers de tu solicitud GraphQL. En Astro, manejarías esto con una ruta SSR (no estática) para que el contenido específico del usuario se obtenga server-side en cada solicitud. No intentes hacer esto de forma estática, eso es pedir problemas.
¿No es esto excesivo para un blog pequeño?
Sí, probablemente. Si tienes menos de 500 artículos y un editor, el costo de mantener una configuración headless no vale la pena. Solo usa un buen tema de WordPress, optimiza tus imágenes, y sigue adelante. Esta arquitectura se justifica cuando tienes volumen, complejidad editorial, o niveles de tráfico donde el desempeño realmente impacta los ingresos.
¿Cómo se ve la infraestructura de hosting en producción?
WordPress (solo CMS) en un VPS pequeño o host WordPress gestionado, yo uso Kinsta o Cloudways. Frontend Astro en Vercel, Netlify, o un VPS Hetzner con Nginx dependiendo del proyecto. Cloudflare en la parte frontal de todo. El costo mensual total para un sitio de contenido de tamaño medio es usualmente £60-£120, que a menudo es menos de lo que los clientes pagaban por un host WordPress todo en uno que se colapsaba bajo la carga.
---
El resumen honesto es este: WordPress headless con Astro es una de las mejores cosas que le han pasado a los sitios de contenido en un tiempo. No porque sea nuevo, sino porque las herramientas finalmente han alcanzado la idea. WPGraphQL es estable, el sistema de construcción de Astro es rápido, y las ganancias de desempeño son reales y medibles.
Consigue la arquitectura correcta desde el principio, especialmente tu estrategia de imágenes y tu enfoque de reconstrucción, y pasarás mucho menos tiempo apagando incendios después. Eso es realmente todo.