El cambio de tema en cifras: una web WordPress real se muda a Hafen

Promesas publicitarias sobre la velocidad de los temas hay muchas; series de mediciones de migraciones reales, pocas. Por eso documentamos aquí una completa: flirtuniversity.de, una escuela de flirteo con contenidos de 17 años, área de miembros, gestión de consentimiento, embeds de vídeo y todo lo que se acumula en una web WordPress que ha crecido con el tiempo, cambió el 1 de septiembre de 2026 de Neve a Hafen. Sin montaje de laboratorio, sin demo recién instalada. Precisamente por eso las cifras son conservadoras, y precisamente por eso valen algo.

El punto de partida

Neve no es un mal tema, al contrario, se le considera con razón uno de los temas clásicos más rápidos. Con él, la web se movía en móvil entre 56 y 59 puntos de Lighthouse, con un First Contentful Paint en torno a los 4 segundos. La causa no es la dejadez, sino la arquitectura: un tema clásico trae su propio framework CSS, sus propios scripts y sus propias capas de ajustes, que se cargan en cada página, se necesiten o no.

Hafen viene de la dirección contraria: un tema de bloques en el que el layout, los colores y la tipografía viven en el theme.json y el propio WordPress genera el CSS necesario. Lo que eso significa en el paquete lo hemos contado con calma: dos peticiones, 7 kilobytes transferidos. La pregunta de este caso real era cuánto de eso sobrevive en una web de verdad, cargada de todo.

El método, para que las cifras se puedan verificar

Medimos con Lighthouse 13.4.1 en Chrome headless, en el mismo equipo y el mismo día: Neve al mediodía antes de la migración, Hafen justo después de la puesta en producción, con la caché vaciada y vuelta a calentar. Tres ejecuciones por página y categoría de dispositivo, y se toma la mediana de cada métrica. Cuatro tipos de página cubren la web: página de inicio, portada del blog, un artículo y una página de curso con hero de vídeo. Son valores de laboratorio, no datos de campo, pero recogidos en condiciones idénticas, y eso es lo único que importa en una comparación.

Lo que aportó el cambio de tema por sí solo

En móvil, donde duele, el cambio puro se vio así, en cada caso Neve contra Hafen, mismo día, misma colección de plugins:

A eso se suman entre un 22 y un 38 % menos de peticiones, una Total Blocking Time reducida a la mitad en la página de inicio y un Largest Contentful Paint que bajó entre un 29 y un 44 %. La estabilidad del layout se quedó en 0,00. En escritorio, la web ya estaba en verde con Neve y siguió estándolo, con entre un 23 y un 34 % menos de peso de página.

La cifra más importante es el First Contentful Paint: de unos 4 segundos se pasa a 1,3 segundos en todas las páginas medidas. Es el momento en que los visitantes ven algo por primera vez en lugar de mirar una pantalla en blanco, y depende casi por completo de cuánto CSS y JavaScript coloca el tema por delante del renderizado.

La parte honesta: lo que el cambio no resolvió

Los entre 360 y 400 kilobytes de JavaScript restantes salen casi por completo de los plugins: área de miembros, gestión de consentimiento, estadísticas, embeds de vídeo. Un cambio de tema no ordena esa capa, solo deja a la vista que es ella la que carga con el peso real. Y el Largest Contentful Paint seguía en móvil entre 4 y 6 segundos también con Hafen, porque el elemento más grande de las páginas clave es un póster de vídeo que hasta entonces se cargaba mediante JavaScript. Un tema ligero no salva contenidos pesados, lo hemos escrito ya en otra ocasión, y esta medición lo confirma.

Ronda 2: lo que aún daba de sí el nuevo tema

Por eso, al cambio le siguió una segunda ronda, esta vez sobre los contenidos y el comportamiento de carga, todo cosas que solo despliegan su efecto limpio sobre unos cimientos ordenados:

• Preload del póster para los heros de vídeo: la imagen de previsualización del elemento más grande se carga con preload y prioridad alta y se muestra de inmediato como fondo CSS, en lugar de esperar al script del embed.
• Conexiones anticipadas con los hosts de analítica mediante preconnect, lo que en conexiones móviles ahorra el handshake de DNS y TLS en la ruta crítica.
• content-visibility para las secciones por debajo de la línea de flotación: el navegador solo renderiza lo que entra en el campo de visión.
• Dieta de scripts: un widget de valoraciones ya solo se carga en la página de inicio, donde realmente está integrado, y los scripts de anuncios automáticos de una cuenta publicitaria dada de baja salieron por completo de la web.

Resultado en la página de curso, el caso más duro con hero de vídeo: puntuación móvil de 71 a 86, y el Largest Contentful Paint cayó de 5,2 a 4,0 segundos. El artículo subió de 77 a 86, la portada del blog de 76 a 80, y la página de inicio mantuvo su puntuación y mejoró en ruta de carga y peso. El JavaScript volvió a bajar de forma notable, hasta entre 215 y 254 kilobytes por página. Sumando las dos etapas: de unas puntuaciones móviles de entre 56 y 59 con Neve se pasó a entre 71 y 86, con el contenido intacto.

Lo que volvió al tema

Para nosotros, la migración fue dos cosas a la vez: proyecto de cliente y prueba de fuego de nuestro propio producto. Un puñado de hallazgos de la migración pasó directamente al desarrollo del tema y llegará con la próxima versión, Hafen 0.9.0: la portada del blog ganó una retícula de revista con tarjeta destacada, las entradas sin imagen destacada recibieron un diseño de respaldo cuidado y la paginación, objetivos táctiles cómodos. Lo que antes se corregía con CSS en la web del cliente será el estándar para cualquiera que instale el tema con la próxima actualización. Así es como debe funcionar el dogfooding: el caso real mejora el producto, no solo esa web.

Lo que puedes llevarte de esto

Si estás valorando un cambio de tema, de esta migración se pueden extrapolar tres cosas. Primera: mide antes, mide después, con el mismo método. Sin cifras previas, luego no sabrás si el esfuerzo mereció la pena. Segunda: el cambio mejora los cimientos, no los contenidos. Las imágenes pesadas, los embeds de vídeo y los scripts de plugins se vienen contigo, solo que sobre unos cimientos rápidos se notan más, y justo entonces compensa la segunda ronda. Tercera: los contenidos se quedan, los layouts se mudan. La cabecera, el pie de página y las páginas de archivo hay que repensarlos, pero los textos y las imágenes permanecen intactos en la base de datos. Cómo acelerar una web lenta independientemente del tema lo explicamos en nuestra guía en diez pasos.

Preguntas frecuentes