Migramos nuestra propia web de WordPress a Astro, y esto es lo que salió

WordPress mueve el 40,3 % de todos los sitios web y el 58,8 % de los que usan un gestor de contenidos conocido. Con esas cifras, cualquier artículo que empiece diciendo que hay que salir corriendo de WordPress está vendiendo algo.

Este no. Esta web estaba en WordPress con Elementor, la migramos a Astro, y lo que sigue son las medidas de antes y después sobre las mismas páginas, los tres fallos que descubrimos por el camino y que no se veían en pantalla, y una cosa que seguimos haciendo mal.

Nuestra tienda, por cierto, sigue en WooCommerce. Esa parte no se migró, y el artículo explica por qué.

Lo que se midió, y cómo

Las páginas del WordPress original están guardadas en el repositorio, tal como las servía el servidor. Las de Astro son las que hay publicadas ahora mismo. Se comparan las mismas cinco páginas, con el mismo contenido, y se cuentan tres cosas: el peso del HTML, cuántas hojas de estilo pide y cuántos ficheros de JavaScript carga.

Y el JavaScript escrito dentro del propio HTML, en la portada:

Veintitrés ficheros de JavaScript en todas las páginas. No en la que tenía el formulario: en todas, incluida la política de cookies. Esa es la marca de un constructor visual: carga su motor entero en cada página por si acaso la usas.

Conviene decir por qué desaparecen, porque no es magia. Astro no elimina el JavaScript: es que no lo pone. Construye HTML y manda al navegador sólo el código que escribas tú a propósito. Los 858 bytes que quedan son el menú del móvil. No hay framework, no hay librería, no hay motor de nada.

Lo que ve un visitante hoy

Las cifras de arriba son de ficheros. Esta es la portada publicada, medida en el navegador:

Ese cero no es casualidad ni es sólo estética: cada dominio de tercero que carga una página es un envío de datos antes de que nadie haya consentido nada. El despliegue de esta web falla si aparece un iframe de un tercero con su src puesto.

Los umbrales oficiales de las Core Web Vitals son 2,5 segundos de LCP, 200 milisegundos de INP y 0,1 de CLS, medidos en el percentil 75 de las visitas reales. No publicamos aquí nuestras cifras de campo porque todavía no hay suficientes visitas para que el percentil 75 signifique nada, y dar un dato de laboratorio como si fuera de campo es el truco más viejo de este tema.

Lo que seguimos haciendo mal

Aquí está el desglose de esos 600 KB, y no deja bien a nadie:

Las fuentes son el 76 % del peso de la portada. Están servidas en formato TTF y completas, con todos sus caracteres, cuando deberían estar en WOFF2 y recortadas a lo que el sitio usa de verdad.

Es decir: quitamos veintitrés ficheros de JavaScript y lo que más pesa ahora es la tipografía. Lo sabemos desde que lo medimos para escribir este artículo, está apuntado y se arreglará. Lo contamos porque un artículo donde todo sale bien no es un artículo, es un folleto.

Los tres fallos que no se veían

Esta es la parte que de verdad importa de una migración, y la que casi nadie cuenta.

Cuando se pasa contenido de un sistema a otro, los fallos graves no dan error. La página se construye, se ve bien, se despliega y funciona. Lo que ha cambiado es la estructura invisible: qué es un encabezado y qué no, en qué orden, a dónde apunta cada enlace. Eso no se ve mirando la pantalla y es exactamente lo que lee un buscador.

Así que la comprobación no es mirar. Es superponer: un programa extrae del WordPress original cada encabezado, su nivel, su orden y cada destino de enlace interno; extrae lo mismo del HTML construido; los compara; y rompe el despliegue si algo no cuadra.

Cazó tres cosas el primer día:

1. Cuatro iconos pintados como <h3> cuando en el original eran párrafos. El extractor asumía el nivel en vez de leerlo.
2. Las cinco preguntas de un FAQ convertidas en <span> cuando eran <h3>. Entre esas dos páginas, diez encabezados desaparecidos sin que se notara absolutamente nada en pantalla.
3. Los <h1> que la limpieza de HTML se comía. El título de la página, que es el elemento más importante que tiene, se perdía en un paso de limpieza.

Ninguno de los tres habría aparecido revisando la web a ojo. Los tres habrían salido semanas después, como una caída de posiciones que nadie sabe explicar.

Y no acabó ahí. Con el sitio ya en marcha aparecieron más de la misma familia: el sitemap declaraba cinco URLs cuando había nueve páginas indexables; la portada y el catálogo no emitían datos estructurados; ninguna página tenía imagen para redes, así que cada enlace compartido salía como un bloque de texto gris; y un botón de compra apuntaba a la URL de una API y devolvía un 404 con el producto existiendo y el precio correcto.

Cada uno de ellos es ahora una comprobación que rompe el despliegue. Esa es la única lección transferible del artículo: en una migración, lo que no se comprueba automáticamente se descubre tarde.

Lo que se pierde al salir de WordPress

Sería deshonesto acabar sin esto.

El editor visual. Es lo más grande. En WordPress, cambiar un texto es entrar al panel y pulsar actualizar. Aquí es editar un fichero y desplegar. Si en tu equipo publica gente que no toca código, ese coste es real y hay que resolverlo antes de migrar.

El ecosistema. Casi cualquier cosa que quieras hacer en WordPress la ha hecho ya alguien y está en un plugin. Fuera de ahí, se programa.

La inmediatez. Un cambio urgente un domingo por la tarde es un despliegue, con lo que eso implica.

Por eso nuestra tienda sigue en WooCommerce. El catálogo, el carrito, el IVA y la pasarela de Redsys se quedan donde ya funcionan; la web de presentación, que es contenido y cambia poco, se fue a Astro. Cada parte donde rinde.

Cuándo tiene sentido, y cuándo no

Sí, si tu web es de contenido, cambia poco, y quieres velocidad, control y que no cargue nada de terceros sin permiso.

No, si publicáis a diario entre varias personas sin perfil técnico, si dependéis de un ecosistema de plugins, o si nadie va a poder desplegar cuando haga falta.

Y una cosa que no es motivo: que WordPress «vaya lento». Un WordPress bien montado, con buen alojamiento y sin un constructor visual cargando su motor entero en cada página, va rápido. El problema de las páginas que medimos arriba no era WordPress: eran veintitrés ficheros de JavaScript que nadie usaba.

Si estás pensando en hacerlo

Lo que de verdad decide cómo sale una migración no es la tecnología que elijas. Es si tienes forma de demostrar que no has perdido nada, y eso se monta antes de migrar, no después.

Si quieres que lo hagamos nosotros, o que lo revisemos antes de que lo hagáis vosotros, nuestra bolsa de horas existe para esto: se compran horas, se gastan en lo que haga falta, y lo que sobra no caduca de un mes para otro.

Y si prefieres empezar por hablar, la primera consulta es gratuita y de ella sale una respuesta, no un presupuesto.