Tailwind CSS para WordPress 2026: block themes, theme.json, JIT | WPPoland

Mariusz Szatkowski

Tailwind CSS en el desarrollo con WordPress en 2026

Última verificación: 22 de septiembre de 2026

7 min de lectura

Guía

500+ proyectos WP

#Tailwind CSS en el desarrollo con WordPress en 2026

Usar Tailwind CSS en un block theme de WordPress exigía antes una negociación cuidadosa entre dos fuentes de verdad en competencia: theme.json para el editor y un bundle CSS para el front-end. WordPress 6.7 y Tailwind v4 han cerrado esa negociación. El patrón que sigue es lo que WPPoland entrega en producción para clientes en Europa en 2026.

El artículo enlaza con la página de servicios de headless WordPress para integraciones headless y con el Tech Radar Q4 2026, donde Tailwind figura como herramienta de producción estable.

#Resumen

Tailwind v4 con un block theme de WordPress 6.7+ es un patrón de producción estable en 2026.
theme.json guarda los tokens globales (paleta, fuentes, espaciados). Tailwind se encarga de la composición de utilities.
JIT compila en una única hoja de estilos empaquetada que se carga con wp_enqueue_style y add_editor_style.
La paridad del editor no es negociable. Los editores deben ver los mismos colores, fuentes y layouts que muestra el front-end.
Evite los arbitrary values en el markup de los bloques para que la vista previa del editor siga siendo determinista.

#Por qué usar Tailwind CSS en un block theme de WordPress

Los block themes y Tailwind no son sistemas en competencia; cubren capas distintas. theme.json define lo que los bloques pueden elegir: una paleta de colores con nombre, una escala tipográfica, una escala de espaciados, un ancho de layout. Tailwind define cómo esas elecciones se combinan en clases utility que el desarrollador escribe en las plantillas y en el markup de los bloques.

La ventaja frente a un block theme puro es la composición de utilities sin escribir archivos CSS nuevos para cada bloque. La ventaja frente al CSS tradicional es la eliminación de código muerto gracias a JIT y Oxide: un block theme acumula CSS con cada actualización de plugins y del tema, mientras que la salida de Tailwind se limita a lo que las plantillas y los estilos del editor usan realmente.

La ventaja frente a Tailwind en un front-end sin WordPress es la paridad del editor. El editor de bloques debe renderizar con los mismos estilos que el front-end; de lo contrario, los editores diseñan en un universo y publican en otro.

#Cómo configurar Tailwind CSS en un tema de WordPress

El patrón fiable que ha sobrevivido a tres grandes actualizaciones de WordPress:

Pipeline de build. Vite, esbuild o @wordpress/scripts (que ya envuelve webpack y PostCSS) compila Tailwind v4 a partir de un único archivo CSS de entrada. El resultado es una hoja de estilos empaquetada, con hash para cache busting.

Orden del enqueue. La hoja de estilos empaquetada se carga al final de wp_head, después de los estilos de la core block library de WordPress. Así las utilities de Tailwind pueden sobrescribir los estilos por defecto de los bloques cuando hace falta, sin perder el comportamiento por defecto de los bloques en aquello que Tailwind no toca.

Estilos del editor. El mismo bundle pasa por add_editor_style para que Gutenberg renderice igual. Donde el canvas del editor necesite otro layout (por ejemplo, anchos limitados), use un pequeño archivo CSS solo para el editor que se aplique encima del bundle compartido.

theme.json. Defina la paleta de colores, las fuentes, los espaciados y el ancho del layout como tokens con nombre. Asocie esos nombres de tokens con las utilities de Tailwind correspondientes mediante un lector sencillo de theme.json (un script de build que genera un fragmento de la configuración de Tailwind). Una fuente de verdad, dos consumidores.

#Clases de Tailwind en el markup de los bloques de Gutenberg

Tres reglas pragmáticas para el markup de bloques con Tailwind.

Use clases utility para composiciones puntuales. En la plantilla de un bloque hero, la línea class="flex items-center gap-6 px-6 py-12" es más clara que una clase CSS propia.

Use clases con nombre para patrones repetidos a nivel de bloque. Un patrón “card” que aparece en varios bloques merece una clase con nombre, compuesta a partir de utilities con @apply y guardada en un pequeño archivo CSS del bloque. La clase con nombre aparece en el inspector del editor y se puede reutilizar.

Evite los arbitrary values en el markup. class="mt-[37px]" funciona en el front-end, pero genera ruido en el editor, donde los bloques esperan tokens de espaciado predecibles. Defina el token en theme.json o amplíe la escala de espaciados en tailwind.config.

En el inspector del editor, registre block styles propios con nombres que coincidan con la intención de las utilities de Tailwind. Los editores eligen “Card large”, los desarrolladores ven block-card-large y la clase se compone de utilities de Tailwind. Editor y código siguen alineados.

#Tamaño del CSS de Tailwind y rendimiento de WordPress

En un build de producción típico con WordPress 6.7+ y Tailwind v4 para un sitio de cliente de WPPoland con mucho contenido:

Un único archivo CSS empaquetado de entre 30 y 60 KB con gzip, según la amplitud de las utilities usadas.
El Largest Contentful Paint suele mejorar en el front-end respecto al CSS acumulado anterior de tema y plugins, porque el bundle es más pequeño y no hay una cadena de overrides en cascada que resolver.
El lado del editor sigue siendo rápido, porque el bundle del editor es el mismo que el del front-end; no existe una compilación de Tailwind aparte solo para el editor.

La cifra que importa más que el tamaño del bundle es el número total de selectores que Cloudflare y el navegador deben resolver. Tailwind v4 con Oxide lo reduce de forma notable frente a v3, porque el motor elimina de forma nativa los duplicados de la salida de utilities.

#Errores más comunes con Tailwind CSS en WordPress

Cinco trampas recurrentes en proyectos de producción:

Olvidar add_editor_style. El front-end se ve bien, el editor aparece sin estilos. Los editores lo notan el primer día. Cargue siempre el mismo bundle de Tailwind en el editor.

Paleta codificada fuera de theme.json. La utility de Tailwind bg-emerald-500 fuera de theme.json implica que el selector de color del editor de bloques sigue mostrando la paleta antigua. Defina la paleta en theme.json y después asóciela como tokens de Tailwind.

CSS de plugins que sobrescribe Tailwind. Algunos plugins antiguos se cargan tarde. Si un plugin rompe el layout, aumente la especificidad con :where() o controle el orden de las capas con @layer en el archivo CSS de entrada.

Arbitrary spacing en el markup. Como se ha dicho, arruina la experiencia en el editor. Cíñase a la escala de espaciados.

Tailwind v4 RC en lugar de la versión stable. v4 stable es la opción correcta en 2026; no despliegue builds v4 RC aunque funcionen el primer día. La estabilidad a lo largo de las actualizaciones de WordPress importa más que las funcionalidades.

#Tailwind CSS en headless WordPress

Cuando Astro 5 o Next.js 15 sustituye al front-end de WordPress (vea los servicios de headless WordPress), la configuración de Tailwind pasa al repositorio del front-end. theme.json sigue guiando la experiencia del editor para quienes redactan. El front-end headless importa los mismos nombres de tokens y los asocia localmente con las utilities de Tailwind. Dos repositorios, una fuente de verdad en el lado de WordPress.

Para las agencias que siguen trabajando con WordPress monolítico, el patrón de este artículo es suficiente. Para los clientes que pasan a headless, úselo como punto de partida y recurra a la página de servicios de headless WordPress para el resto de la arquitectura.