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

Trabajo con WordPress todos los días. Es la herramienta con la que desarrollo el 99 % de los proyectos de mis clientes, y lo seguirá siendo: su ecosistema de plugins, su flexibilidad y su comunidad lo convierten en la opción ideal para la mayoría de webs. Esto no es un post contra WordPress.

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.

Cada vez que alguien visitaba jaime.digital, el servidor ejecutaba PHP, consultaba MySQL, cargaba plugins, ensamblaba la página y la enviaba. Todo ese proceso para servir una página que era prácticamente idéntica a la que se había servido cinco minutos antes. Sí, los plugins de caché ayudaban, pero añadían otra capa de complejidad que también necesitaba mantenimiento.

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 5 como generador. Astro toma el contenido, lo compila a HTML estático y lo deja listo para servir. No envía JavaScript innecesario al navegador, solo lo imprescindible para los componentes que realmente lo necesitan, como mi calculador de presupuestos online. Para páginas informativas, el resultado es HTML puro que carga instantáneamente.

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 como hosting. Esta fue la sorpresa más agradable: Cloudflare Pages distribuye los archivos estáticos por su red global de CDN de forma gratuita. Cada visitante recibe la página desde el nodo más cercano, sin que ningún servidor tenga que procesar nada. Coste mensual: cero euros.

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

En cualquier migración, los redirects son sagrados. Configuré redirecciones 301 para todas las URLs antiguas, mantuve la estructura de URLs del blog (/blog/slug/), actualicé sitemap, meta tags, Open Graph y datos estructurados. Además, las URLs antiguas de imágenes (/wp-content/uploads/...) redirigen automáticamente a sus nuevas ubicaciones. Ni un solo enlace roto.

Deploy automático

Cada vez que hago un cambio y lo subo a GitHub, Cloudflare Pages compila y despliega automáticamente en menos de 2 minutos. Sin FTP, sin acceder a paneles de hosting, sin preocuparme por cachés que limpiar.

Los resultados

Estos son los números de PageSpeed Insights con fecha de hoy, 3 de abril de 2026:

En escritorio: Rendimiento 98/100, Accesibilidad 96/100, Prácticas recomendadas 100/100, SEO 92/100. La web carga en 0,8 segundos con un Total Blocking Time de 0 milisegundos.

En móvil: Rendimiento 85/100, Accesibilidad 96/100, Prácticas recomendadas 100/100, SEO 92/100. Los tiempos son más altos por la simulación de red 4G lenta que usa Lighthouse, pero el TBT sigue en 0 ms.

El dato que más me impactó: LCP de 0,8 segundos en desktop. Eso significa que el elemento más grande de la página (en mi caso, la foto del hero) está completamente pintado en menos de un segundo. Con WordPress, este número rondaba los 3-4 segundos dependiendo del día y la carga del servidor.

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:

Tiene sentido cuando tu web es principalmente informativa (corporativa, portfolio, blog con actualizaciones puntuales), el rendimiento es crítico para tu imagen profesional, y tienes acceso a un perfil técnico que pueda manejar el stack. También si quieres eliminar costes de hosting recurrentes o simplificar el mantenimiento a prácticamente cero.

No tiene sentido cuando necesitas funcionalidades dinámicas complejas (tienda online con WooCommerce, membresías, foros), tu equipo no técnico necesita gestionar la web sin ayuda de un desarrollador, o dependes de plugins específicos de WordPress que no tienen equivalente.

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

El rendimiento de 98/100 en desktop, los 0 € de hosting y la eliminación del mantenimiento recurrente son datos objetivos. Pero lo que más valoro es algo menos tangible: ya no siento que mi web me queda pequeña. Cuando un cliente potencial entra en jaime.digital, la experiencia está a la altura de lo que les prometo para sus proyectos.

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.