De 4 Segundos a Cero: La Magia de Astro para un WordPress Headless Ultrarrápido
📝 Introducción: La Realidad de la Velocidad Web
Todos amamos la flexibilidad y el poder de WordPress como CMS. Es el corazón editorial de la web. Pero seamos sinceros: cuando un cliente llega con un informe de PageSpeed y pide un 95+ en móvil, o cuando el tiempo de carga del primer byte (TTFB) es de 4 segundos, la "magia" de WordPress se convierte rápidamente en un dolor de cabeza.
Mi camino, como freelance, me ha llevado a la solución que muchos evitan: WordPress Headless. Pero incluso con Next.js o Gatsby, nos enfrentamos a un nuevo monstruo: la "sobrecarga de JavaScript" o Hydration Hell. El sitio carga rápido, sí, pero hasta que ese gigabyte de JavaScript se procesa en el móvil, el usuario sigue esperando.
Aquí es donde entra Astro. No es solo un framework, es una filosofía. Es la artillería pesada que utilicé para llevar un sitio de 4 segundos de TTFB a una carga inicial casi instantánea. Y te voy a mostrar por qué funciona y cómo lo integramos con nuestra fuente de datos: WordPress.
El Diagnóstico – ¿Por qué mi Frontend es Lento?
El problema en el desarrollo moderno, incluso con React, no es el backend de WordPress; es la hidratación.
El flujo es simple: el servidor de Node.js envía el HTML pre-renderizado, pero luego el navegador debe descargar, parsear y ejecutar TODO el JavaScript de la aplicación antes de que los componentes se vuelvan interactivos. El usuario ve el contenido rápidamente, pero si intenta hacer clic, la página está "muerta" hasta que la hidratación finaliza. Esto hunde métricas como Time To Interactive (TTI) y First Input Delay (FID).
La Solución – La Arquitectura de Islas de Astro
Astro resuelve el problema de forma elegante, adoptando la Island Architecture (Arquitectura de Islas).
La Playa (El HTML): Es el contenido estático generado por Astro (puro HTML y CSS). Es rápido, accesible y no necesita JS para verse.
Las Islas (Los Componentes Interactivos): Son pequeñas porciones de componentes React, Vue o Svelte aisladas que sí necesitan JavaScript. Un carrusel de imágenes, un formulario de contacto o un widget de comentarios.
La Regla de Oro de Astro: Por defecto, cero JavaScript. Astro solo carga el JS en las "islas" específicas que lo requieran, y solo cuando sea estrictamente necesario. Esto maximiza la velocidad de carga inicial.
El Puente de Datos – Modelando Contenido con ACF y GraphQL
En proyectos empresariales, casi nunca usamos el editor clásico de WP. Usamos campos personalizados para estructurar los datos. Para Astro, debemos asegurarnos de que el backend sea tan limpio y rápido como el frontend.
El Problema del Backend Clásico: Si usáramos la REST API para obtener nuestros campos de ACF, tendríamos que hacer varias llamadas (una para el post, otra para los campos, otra para las categorías) y lidiar con el over-fetching (obtener datos que no necesitamos).
La Solución Elegante: El plugin WP GraphQL junto con el plugin WPGraphQL for Advanced Custom Fields nos permite obtener exactamente lo que necesitamos, en una sola consulta, en la fase de build de Astro.
Ejemplo de Fetching en Astro:
Aquí le estamos pidiendo a WP solo el título, el contenido y un campo personalizado de ACF llamado autor_experto, todo en una sola petición.
JavaScript
// Llamada a la API en getStaticPaths o getStaticProps de Astro
const GQL_QUERY = `
query GetPostBySlug($slug: ID!) {
post(id: $slug, idType: SLUG) {
title
content
// Campo personalizado de ACF expuesto a GraphQL:
fieldsPersonalizados {
autorExperto // El nombre de tu campo ACF
}
}
}
`;
// La función de fetching...
export async function getStaticPaths() {
const data = await fetchWPGraphQL(GQL_QUERY, { slug: 'mi-post-astro' });
// ... tu lógica para generar la página con data.post
}
Al pasar solo esta pequeña carga de datos a Astro, el motor de build genera un archivo HTML mínimo y ultra-optimizado.
Del Dato a la Interacción (La Práctica de la Isla)
Una vez que Astro tiene los datos del post de WP GraphQL, la mayor parte de la página se renderiza como HTML estático (como en el ejemplo anterior con set:html).
Pero, ¿qué pasa si queremos un botón de "Me Gusta" hecho en React?
JavaScript
// En tu archivo .astro:
<BotonLike client:visible postId={post.id} />
{/* La directiva client:visible solo carga el JS cuando el componente entra al viewport */}
La Magia:
El navegador carga el post (HTML, CSS, muy rápido).
El JavaScript del
BotonLikeni siquiera se descarga.Solo cuando el usuario desplaza la pantalla y el botón entra en la vista (viewport), Astro carga ese JS específico y el componente de React se inicializa, permitiendo la interacción.
El Time To Interactive (TTI) mejora drásticamente porque la página es funcional casi desde el principio.
Evita el Retraso de la CDN
Cuando trabajes con Headless, tu velocidad ya no depende de tu servidor de WP, sino de tu CDN (Vercel, Netlify, Cloudflare).
Mi Consejo: Si tu WordPress es lento en responder a la API (lo que te dará TTFB lentos durante el build de Astro), utiliza un caché de objeto o un CDN delante de tu endpoint de GraphQL (como Cloudflare APO o Redis). Esto acelera el proceso de build de tu sitio Astro y garantiza que los datos que Astro fetecha para construir el HTML sean siempre rápidos.
El Futuro del Frontend Headless
La elección de Astro no es solo una moda; es una decisión de negocio y de rendimiento. Como desarrolladores, nuestra responsabilidad es entregar experiencias que no solo se vean bien, sino que funcionen instantáneamente.
Al usar la Island Architecture de Astro junto a la flexibilidad de WP GraphQL y ACF, podemos prometer y entregar esa velocidad extrema sin tener que reescribir la lógica compleja de nuestro CMS. Si estás buscando el 95+ en PageSpeed, es hora de que tu frontend se ponga a dieta de JavaScript y que uses Astro.
Escrito por
Joaquin Sáez
