Por qué migré mi web de WordPress a Astro (y los resultados me sorprendieron)

Trabajo con WordPress y otras plataformas según el proyecto. Para mi web elegí Astro con Storyblok; esa elección no significa que sea la arquitectura adecuada para todas las webs de clientes.

Pero mi propia web, jaime.digital, llevaba tiempo dándome un problema que no conseguía resolver: los tiempos de carga. Le dedicaba horas a optimizar, probando nuevos plugins de caché, actualizando temas, ajustando configuraciones con cada nueva versión y nunca terminaba de estar satisfecho con los resultados. Para el tiempo que invertía, el rendimiento no estaba a la altura.

Mi web es mi carta de presentación. Cuando un cliente potencial llega a jaime.digital, quiero que la experiencia sea impecable. Y eso no estaba pasando.

Así que decidí hacer algo que normalmente no recomendaría a un cliente con una web corporativa: reconstruirla desde cero con una arquitectura completamente diferente. Este post cuenta ese proceso, los problemas reales que encontré y los resultados que conseguí.

El problema no era WordPress, era el encaje

Quiero dejar esto claro: WordPress no era el problema en sí. El problema era que WordPress es una herramienta pensada para gestionar contenido dinámico, tiendas, membresías, portales con usuarios, webs que cambian constantemente. Mi web es esencialmente una web corporativa con un blog. El contenido cambia una o dos veces al mes.

WordPress puede servir HTML cacheado sin regenerar cada página en cada visita. La elección de otra arquitectura responde al encaje del proyecto, no a que WordPress deba ejecutar siempre PHP y consultas para todo el tráfico.

Lo que más me frustraba era el ciclo de optimización sin fin: salía una nueva versión de WordPress, la actualización rompía la compatibilidad con algún plugin de caché, probaba alternativas, dedicaba un fin de semana a ajustar configuraciones... y al mes siguiente, vuelta a empezar. Para una web que apenas cambiaba, estaba invirtiendo demasiado tiempo en mantenimiento técnico.

La idea fue sencilla: ¿y si en lugar de generar las páginas dinámicamente en cada visita, las pre-genero una vez y sirvo directamente el HTML estático?

Una nueva arquitectura para un caso muy concreto

Quiero insistir: esta arquitectura no es mejor que WordPress "en general". Es mejor para mi caso específico, una web corporativa con blog, sin tienda online, gestionada por una sola persona técnica. Para la mayoría de mis clientes, WordPress sigue siendo la respuesta correcta.

Dicho esto, el stack que elegí:

Astro como frontend: permite generar las páginas y controlar qué componentes necesitan interactividad. El rendimiento depende también de imágenes, fuentes, scripts e integraciones; no es instantáneo por elegir un framework.

Storyblok como gestor de contenido. No quería perder la comodidad de tener un CMS para gestionar los posts del blog. Storyblok me da un editor visual donde puedo escribir y publicar contenido sin tocar código, similar a lo que haría en WordPress pero sin la infraestructura de servidor detrás.

Cloudflare Pages publica el sitio y distribuye sus recursos. Las páginas estáticas y las funciones dinámicas tienen necesidades distintas. Los costes y límites de CMS, endpoints y servicios externos forman parte del mantenimiento, aunque el alojamiento de algunos recursos utilice un plan gratuito.

El proceso de migración

Exportar y transformar el contenido

Saqué todo el contenido de WordPress, posts, páginas, imágenes, metadatos SEO, y lo transformé al formato que Storyblok necesita. Los posts con contenido sencillo fueron automáticos, pero los que tenían tablas HTML, shortcodes o galerías necesitaron revisión manual. No fue inmediato, pero tampoco dramático.

Rediseño pensando en rendimiento

No migré el tema de WordPress tal cual. Aproveché para rediseñar la web completa con el rendimiento como prioridad desde el primer momento: imágenes en WebP con diferentes resoluciones según el dispositivo, fuentes optimizadas, CSS mínimo (Tailwind purga automáticamente lo que no se usa) y navegación fluida con View Transitions nativas de Astro, que dan esa sensación de app sin necesidad de frameworks JavaScript pesados.

La limpieza de imágenes

Esta parte me sorprendió. WordPress acumula versiones de cada imagen que subes, thumbnails, tamaños intermedios, retina... Mi instalación tenía 2.361 archivos en la carpeta de uploads, ocupando 314 MB. Hice una auditoría de cuáles aparecían realmente en algún post o página publicada. El resultado: solo necesitaba 81 imágenes, que ocupan 7,4 MB.

No es culpa de WordPress, así funciona su sistema de medios, y para webs activas con muchos editores tiene sentido. Pero para mi caso, el 97 % de esos archivos eran peso muerto.

Proteger el SEO

La migración requiere inventariar las URLs y comprobar redirecciones, contenido y metadatos en producción. No basta con configurar reglas para afirmar que no queda ningún enlace roto: esa conclusión necesita un rastreo y seguimiento posteriores.

Deploy automático

Los cambios de código se publican mediante GitHub y el despliegue de Cloudflare Pages. Los cambios de Storyblok también necesitan quedar reflejados en el sitio generado. Cada publicación se valida; los tiempos de compilación no son una garantía fija.

Los resultados

Actualización de medición: 19 de septiembre de 2026. Los resultados siguientes corresponden a dos pruebas finales sobre el dominio de producción, realizadas después de optimizar fuentes, CSS e imágenes y evitar recursos innecesarios en la carga inicial de la portada, manteniendo la arquitectura y el diseño.

El 19 de septiembre de 2026 repetí PageSpeed sobre jaime.digital después de dos rondas de optimización. La primera prueba móvil final dio 99/100, LCP de 2,0 segundos, FCP de 1,1 segundos, TBT de 0 ms y CLS de 0. La segunda prueba móvil final dio 96/100, LCP de 2,3 segundos, FCP de 1,5 segundos, TBT de 0 ms y CLS de 0. Publico ambas para mostrar la variación entre ejecuciones.

Son pruebas de laboratorio con Lighthouse 13.4.1, móvil Moto G Power emulado y 4G lenta. PageSpeed no mostraba datos de usuarios reales disponibles. Estas mediciones no demuestran por sí solas que se supere la evaluación de Core Web Vitals de campo.

Antes de estos ajustes, las dos pruebas del mismo día dieron 88 y 90/100, con LCP de 3,5 y 3,4 segundos. La primera ronda mejoró hasta 92–93/100 y LCP de 3,0–3,2 segundos. Tras la segunda ronda, las dos pruebas finales mejoran puntuación y LCP y quedan por debajo de 2,5 segundos de LCP móvil. El Speed Index final fue de 1,1 y 3,8 segundos: no todas las métricas mejoran en cada ejecución. Dos pruebas no garantizan el resultado de todas las visitas.

En escritorio, las dos pruebas finales obtuvieron 100/100, LCP de 0,5 segundos, FCP de 0,4 segundos, TBT de 0 ms y CLS de 0. Antes ya se obtenían 100/100; la mejora principal observada está en móvil.

Lo que aprendí por el camino

No fue todo coser y cantar. Algunos aprendizajes:

Las View Transitions de Astro son fantásticas, pero tienen trampa. Cuando navegas entre páginas, Astro reemplaza el DOM completo. Si tu JavaScript guarda referencias a elementos (como hacía mi calculador de presupuestos), después de navegar esas referencias apuntan a nodos que ya no existen. Tuve que reescribir la lógica para que re-consulte el DOM en cada interacción.

La migración de contenido rico es artesanal. Tablas HTML complejas, shortcodes de WordPress, galerías con lightbox... todo eso necesita adaptación manual. No hay un botón de "exportar a Storyblok" que lo resuelva automáticamente.

Las rutas de imágenes son persistentes. Los posts migrados desde WordPress siguen referenciando imágenes con rutas tipo /wp-content/uploads/2023/05/foto.jpg. Necesité lógica de redirección en varios puntos del código para que todo siguiera funcionando.

¿Cuándo tiene sentido plantearse esta arquitectura?

Esta es la pregunta importante, y quiero ser honesto:

Puede tener sentido si separar contenido y frontend resuelve requisitos concretos y hay capacidad de mantenimiento. Antes de reconstruir, hay que comparar esa inversión con optimizar la solución actual; no elimina por sí sola los costes recurrentes.

Si necesitas funciones dinámicas o dependes de plugins, hay que valorar su integración y coste. No son imposibles en headless, pero pueden hacer preferible conservar WordPress tradicional. La edición no técnica también requiere un flujo de CMS probado.

Para la mayoría de mis clientes, WordPress sigue siendo la recomendación correcta. Pero si tu caso se parece al mío, una web corporativa donde el rendimiento importa y la frecuencia de actualización es baja, merece la pena explorar estas alternativas.

Finalmente

Lo que valoro de esta arquitectura es el control sobre contenido y presentación. Sigue necesitando mantenimiento y comprobaciones. Los resultados técnicos deben fecharse y no se trasladan automáticamente a otro proyecto.

Si estás en una situación parecida, satisfecho con WordPress para tus clientes pero frustrado con el rendimiento de tu propia web, me encantaría ayudarte a evaluar si esta arquitectura encaja en tu caso. Solicita un diagnóstico gratuito y lo analizamos juntos.

¿Aún no tienes claro el concepto? Empieza por mi guía: qué es WordPress headless, explicado sin jerga técnica.