Caso jaime.digital: de WordPress a Astro con Storyblok

jaime.digital utiliza Astro como frontend, Storyblok para gestionar contenido y Cloudflare Pages para publicar la web. El sitio procede de una migración desde WordPress, pero WordPress no es el backend de la arquitectura actual. Es importante distinguir este caso del servicio WordPress headless.

Las mediciones históricas documentan el estado de la web en aquella etapa de la migración. Las pruebas del 19 de septiembre de 2026 corresponden a una versión posterior y se muestran por separado; ambas referencias permiten seguir la evolución.

Resultados históricos de la migración

Comparación registrada en el caso original de la migración de febrero de 2026. Estos valores históricos no sustituyen las mediciones actuales que se incluyen más abajo.

En los dos meses posteriores, la tasa de rebote pasó del 58 % al 41 % y el tiempo medio en página aumentó un 22 %. Son cambios observados del periodo, no una atribución causal aislada a la velocidad.

El proyecto sumó 86 horas de trabajo repartidas en seis semanas. El coste de hosting frontend pasó de 18 €/mes a 0 €/mes, un ahorro de 216 € al año en ese concepto.

Qué gestiona cada parte

Astro construye las páginas y componentes de la web. Las páginas de servicios incluyen contenido en el código del proyecto; las entradas del blog se obtienen de Storyblok. Por tanto, no todo el contenido está en el mismo editor ni se publica mediante el mismo recorrido.

Cloudflare Pages sirve el resultado del despliegue. Algunas funciones, como formularios y herramientas, también necesitan endpoints y servicios externos. Describir el sitio como «sin servidor» o «sin mantenimiento» ocultaría esas dependencias.

Qué hubo que comprobar en el contenido

Pasar de un CMS a otro exige revisar URLs, enlaces, medios y formato de texto. Las tablas, los bloques y las rutas antiguas necesitan comprobación en la página publicada: que un dato exista en el gestor no significa que el frontend lo represente correctamente.

El mismo principio se aplica al SEO. Título, descripción, canonical, datos estructurados y sitemap tienen que corresponder al contenido visible. Conservar una URL reduce cambios innecesarios, pero no garantiza que Google mantenga su posición.

Una medición fechada, no una promesa permanente

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.

Qué cambió en la carga de la página

La optimización conserva Astro, Storyblok y el diseño. Las fuentes se sirven desde el mismo dominio, los estilos se integran en el HTML para eliminar peticiones que bloqueaban el primer renderizado, el logo utiliza tamaños adaptables y el póster del vídeo pesa menos. En móvil se prioriza el texto frente a la precarga de la fotografía. La segunda ronda evita cargar Turnstile en bloques sin formulario y retrasa Caveat en la portada hasta que su texto se acerca a la pantalla. Los formularios mantienen su protección antispam y las páginas que usan Caveat en un titular la conservan desde el inicio.

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.

Qué no demuestra este caso

No permite afirmar que WordPress sea lento por naturaleza, que headless sea adecuado para un porcentaje fijo de empresas o que las variaciones de tráfico o conversión se deban solo a la tecnología. También hubo trabajo de diseño y contenido, y las comparaciones necesitan periodos y condiciones equivalentes.

El coste total incluye mantenimiento de código, servicios, contenido y despliegues. Una tarifa de alojamiento del frontend no basta para calcular el ahorro de todo el proyecto.

Si quieres valorar una arquitectura similar, revisamos primero tu edición, integraciones y objetivos. Puedes ampliar la guía WordPress headless o consultar el servicio de diagnóstico e integración.