La discusión empezó en una comida, con la boca llena y sin ningún dato encima de la mesa. Un desarrollador con el que me peleo por esto cada dos meses soltó la frase de siempre: «los temas de bloques van más ligeros, es que no hay color». Yo llevaba semanas viendo lo contrario en sitios reales, así que le propuse algo mejor que seguir gritándonos: montamos la misma página dos veces y la medimos.
Nada de comparar el tema del cliente contra una demo de manual. Mismo servidor, mismo PHP, misma versión de WordPress, mismo contenido palabra por palabra, la misma imagen de cabecera con el mismo tamaño y el mismo formato. Una copia con un tema clásico hecho a mano, de esos que solo encolan su hoja de estilos y poco más. Otra copia con un tema de bloques, con su theme.json y su editor de sitio.
La pestaña que estropea las discusiones
Lo primero que hicimos fue lo aburrido: abrir la pestaña de red con la caché desactivada y contar qué se descarga de verdad. Después, la pestaña Coverage de Chrome, que te dice cuánto de ese CSS y ese JavaScript se ha usado realmente para pintar lo que estás viendo. Es una herramienta antipática porque nunca te da la razón.
El primer sobresalto fue del tema clásico, y no venía del tema. WordPress encola la hoja de estilos de los bloques del núcleo en el front, entera, aunque tu página no tenga más bloques que unos cuantos párrafos y una imagen. Estaba ahí, descargándose, con un porcentaje de uso ridículo. El tema pesaba lo que pesaba; el problema era el equipaje que le mete el propio WordPress por debajo.
El segundo sobresalto fue del tema de bloques, y ese sí es más interesante. Los temas de bloques activan por defecto la carga de estilos por bloque: en lugar de una hoja gigante, solo se sirve el CSS de los bloques que aparecen en esa página. En papel es una maravilla. En la práctica, lo que te ahorras por un lado te lo cobran por otro.
Los kilobytes que nadie cuenta
Si miras el código fuente de un tema de bloques y buscas global-styles-inline-css, te vas a encontrar una etiqueta de estilos en línea generada a partir del theme.json. Ahí van las variables de la paleta, los tamaños de tipografía, los espaciados, las capas de layout y las combinaciones de todo eso para cada bloque registrado. No es un archivo, así que no aparece como una petición en la pestaña de red. No se cachea aparte. No lo ves en ningún listado de recursos. Está incrustado en el HTML de todas y cada una de tus páginas.
Y crece. Cada vez que alguien toca el editor de sitio y añade un color a la paleta, un tamaño de fuente o un ajuste de espaciado, ese bloque de estilos engorda un poco. Nadie lo revisa nunca porque no hay ninguna pantalla que te diga cuánto ocupa. Yo lo he visto hincharse en proyectos donde el diseñador tenía barra libre en la paleta y se había montado catorce colores «por si acaso».
Ahí está la trampa de la comparación. Si cuentas solo archivos, el tema de bloques gana casi siempre. Si cuentas bytes de HTML entregados, la cosa se iguala mucho, porque una parte del CSS ha dejado de ser un archivo cacheable y se ha convertido en peso muerto que viaja en cada visita.
Cómo se pone cada uno en su sitio
Lo bueno es que casi todo esto se toca desde el functions.php con tres o cuatro líneas.
- Si estás en tema clásico, puedes activar el filtro should_load_separate_core_block_assets para que el núcleo sirva solo el CSS de los bloques que se usan, en vez de la hoja completa. Es el mismo comportamiento que tienen los temas de bloques de serie, y no hay ninguna razón para dejarlo apagado.
- Si tu tema clásico no usa el editor de bloques en el front ni de casualidad, puedes quitar la hoja del núcleo directamente. Aquí toca ir con cuidado: si un día metes una galería o unas columnas, se te va a caer con estrépito.
- Si estás en tema de bloques, adelgaza el theme.json. Cada color, cada tamaño y cada preajuste que quitas de ahí desaparece del bloque de estilos en línea de todas tus páginas. Es la optimización con mejor relación esfuerzo/resultado de todo el asunto.
- Existe la opción nuclear: desenganchar wp_enqueue_global_styles del arranque. Funciona, y en un tema de bloques te destroza la maqueta en cuestión de segundos. Solo tiene sentido en temas clásicos que no dependen de nada de eso.
Y la caché, ¿qué arregla de todo esto?
Aquí es donde mucha gente se relaja antes de tiempo. Repetimos las mediciones con caché de página activada y, efectivamente, todo mejora: el servidor deja de generar HTML y el navegador empieza a recibir cosas antes. El LCP baja en las dos versiones, sin sorpresas.
Pero la caché no borra un solo byte de CSS que no uses. Sigue viajando, sigue bloqueando el pintado y sigue ahí en la segunda visita si has tocado algo del tema y las cabeceras han cambiado. Y el INP, que es la métrica que de verdad se te atraganta en móvil, ni se entera de que existe la caché: depende del JavaScript que se ejecuta cuando el usuario toca la pantalla, no de lo rápido que le llegó el HTML. Si tu tema mete un menú con animaciones y un carrusel, ese número lo pone el hilo principal, no el servidor.
Conviene recordar además que el INP no lo mide Lighthouse. Lo que ves en un informe de laboratorio es una aproximación; el número real sale de usuarios de verdad tocando la pantalla, y para eso necesitas datos de campo. Cuando alguien te enseñe un INP verde en una captura de Lighthouse, sospecha.
Con qué me quedo
La prueba no coronó a ningún ganador, y por eso me gustó. El tema clásico bien hecho es rapidísimo hasta que descubres que arrastra CSS de bloques que nadie pidió. El tema de bloques es más ordenado hasta que alguien mete media paleta de Pantone en el editor de sitio y el HTML se llena de variables. En los dos casos, el peso extra venía de decisiones por defecto que nadie había revisado nunca.
Mi colega sigue pensando que los temas de bloques van más ligeros. Yo sigo pensando que va más ligero el tema que alguien se ha molestado en medir. Al menos ahora discutimos con la pestaña Coverage abierta, que ya es un avance.
