Pilar de servicios

Desarrollador Astro

Sénior B2B, jurisdicción de la UE, alcance definido por proyecto.

Tarificación individual. Respondemos en un día laborable.

Iniciar un proyecto Página completa de Astro →

Qué entregamos

Astro 5+ en el frontend. WordPress 6.7+ como back end editorial, comunicándose por REST o GraphQL. Cloudflare Pages para estático y SSR. TypeScript en toda la stack. Tailwind CSS como sistema de diseño. MDX para flexibilidad editorial donde los autores la necesitan. Anthropic Claude y Model Context Protocol cuando las funciones de IA realmente compensan.

Por qué Astro para headless WordPress

El modelo de JavaScript mínimo de Astro es la base correcta para sitios de contenido. La mayoría de las páginas de un sitio WordPress orientado a contenido tienen uno o dos elementos interactivos (un buscador, un menú de navegación, un formulario de contacto) y el resto es HTML puro. Astro envía solo el JavaScript que esas interacciones necesitan; lo demás es HTML estático renderizado en build o por SSR por ruta.

En sitios de contenido con mucho tráfico, la forma del coste importa. Las páginas estáticas de Astro se sirven desde la cache en la edge con coste de CPU casi nulo por petición. La huella de carbono y de ancho de banda es significativamente menor que un Next.js SSR equivalente. Para sitios donde la interactividad es el producto (dashboards, commerce transaccional, feeds en tiempo real), recomendamos en su lugar el pilar Next.js.

Para quién es

  • Editores y sitios de contenido con flujo editorial en WordPress
  • Catálogos WooCommerce orientados a contenido, donde el commerce es una superficie pequeña dentro de un sitio mayor
  • Portales de documentación y sitios técnicos orientados a desarrolladores
  • Sitios de marketing que necesitan LCP rápido y mínimo JavaScript en móvil

Modelo de colaboración

Contratos sénior B2B en jurisdicción de la UE. Discovery, scoping, proyectos de alcance fijo o time-and-materials. Tarificación individual.

Ruta de lectura en el edge, escritura en el origen. La caché se invalida por tags vía webhook. Lector / agente sends a request to Cloudflare Workers (edge). On cache hit the Caché en el edge (por tag) returns HTML with almost no CPU. On cache miss Workers calls REST API /wp-json/ on the Origen WordPress and renders. Editorial work happens in Block Editor + WP Admin on the origin and triggers a Webhook al publicar that invalidates relevant cache tags. Lector / agente Cloudflare Workers (edge) Caché en el edge (por tag) acierto de caché (casi cero CPU) fallo de caché → render en el edge Origen WordPress Block Editor + WP Admin REST API /wp-json/ Publicación / cambio de slug / stock Read Read Webhook al publicar Write
Ruta de lectura en el edge, escritura en el origen. La caché se invalida por tags vía webhook.
El cero JavaScript por página por defecto no es una funcionalidad; es el compromiso arquitectónico que abarata todo lo demás.
Fred K. Schott , creador de Astro , Astro Together 2025 , 2025-09-22 , source

Preguntas frecuentes

¿Cuándo gana Astro a Next.js para headless WordPress?

En sitios con mucho contenido, con cadencia de actualización predecible y mínima interactividad por página. Sitios de marketing, blogs, portales de documentación, catálogos WooCommerce orientados a contenido. Astro envía cero JavaScript por defecto; las partes interactivas son islas opt-in. Next.js gana en flujos personalizados, dirigidos por sesión o transaccionales.

¿Qué es la arquitectura de islas en la práctica?

Cada componente interactivo es una isla independiente que se hidrata por su cuenta, con su propio bundle de JavaScript. El resto de la página es HTML estático. El resultado es un TTI más rápido en redes lentas, porque el navegador solo procesa el JS de las islas que el usuario ve realmente, no de toda la página.

¿Soporta Astro componentes React, Vue y Svelte en el mismo proyecto?

Sí. Astro es agnóstico al framework. Habitualmente usamos componentes Astro para la estructura HTML y React para las islas interactivas; la elección es por componente. La mezcla está soportada, aunque rara vez es necesaria en proyectos en producción.

¿Cómo se comporta Astro en Cloudflare Pages?

Excelente para contenido estático y al estilo ISR. El HTML pre-construido de Astro se sirve desde la cache en la edge con coste de CPU casi nulo. Las rutas SSR usan el adaptador Cloudflare y corren como funciones Worker. Hacemos benchmark por proyecto; lo estático es el modo más barato.

¿Podéis migrar un monolito WordPress a Astro?

Sí. WordPress se queda como back end editorial y Astro pasa a ser el front end vía REST o GraphQL. La preservación de contenido, el mapeo de URLs, hreflang, sitemaps y datos estructurados se trasladan todos. El plazo de migración es típicamente de 6 a 16 semanas según el tamaño del catálogo y el número de integraciones.

Lecturas del cluster

Arquitectura y decisión

Migración y plazos

Página completa

Referencia

Inicia un proyecto Astro

Cuéntanos alcance y plazos. Respondemos en un día laborable.

Contáctanos