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.
- Evita 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. Tailwind v4 escribe su salida en capas en cascada (theme, base, components, utilities), como muestra la documentación de Preflight. La hoja de block-library de WordPress no usa capas: en WordPress 7.0, wp-includes/css/dist/block-library/style.css no contiene ninguna regla @layer. Según MDN, los estilos que no están en una capa siempre ganan a los que sí lo están. Cargar el bundle al final de wp_head no basta, por tanto, para que una utility gane a un estilo del core: el orden solo decide entre hojas sin capas. La sección sobre capas, más abajo, explica cómo resolver esos conflictos.
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), usa un pequeño archivo CSS solo para el editor que se aplique encima del bundle compartido.
theme.json. Define la paleta de colores, las fuentes, los espaciados y el ancho del layout como tokens con nombre. Desde v4 la configuración de Tailwind vive en CSS y no en JavaScript (anuncio de Tailwind CSS v4.0), así que la asociación entre los tokens de theme.json y las utilities se escribe directamente en el archivo CSS de entrada, sin un script intermedio. Una fuente de verdad, dos consumidores.
Cómo conectar theme.json con @theme en Tailwind v4
WordPress convierte cada preset de theme.json en una propiedad CSS personalizada con el patrón --wp--preset--{tipo}--{slug}. Un color con el slug ocean se convierte en --wp--preset--color--ocean y una familia tipográfica con el slug primary en --wp--preset--font-family--primary (Theme Handbook: colores y tipografía). Tailwind v4, por su parte, crea utilities a partir de las variables declaradas en @theme: --color-ocean produce bg-ocean, text-ocean y fill-ocean (theme variables).
Basta con unir los dos lados. Primero theme.json, en la versión 3 del esquema:
{
"version": 3,
"settings": {
"color": {
"defaultPalette": false,
"custom": false,
"palette": [
{ "slug": "ocean", "color": "#0b5d7a", "name": "Ocean" },
{ "slug": "charcoal", "color": "#1d2327", "name": "Charcoal" }
]
},
"typography": {
"fontFamilies": [
{ "slug": "primary", "name": "Primary", "fontFamily": "Charter, Cambria, serif" }
]
}
}
}Después el archivo CSS de entrada del tema:
@import "tailwindcss";
@theme inline {
--color-*: initial;
--color-ocean: var(--wp--preset--color--ocean);
--color-charcoal: var(--wp--preset--color--charcoal);
--font-primary: var(--wp--preset--font-family--primary);
}Cada detalle de estos dos bloques sale de la documentación. inline hace falta porque la variable de Tailwind apunta a otra variable: sin él, la utility puede resolverse a un valor inesperado por la forma en que CSS resuelve var(), y con él la clase recibe directamente var(--wp--preset--color--ocean). --color-*: initial elimina la paleta por defecto de Tailwind, así que bg-emerald-500 deja de existir y solo quedan los colores de theme.json. En theme.json, defaultPalette: false oculta los colores del core y custom: false limita a los usuarios a los colores predefinidos.
El resultado es que el editor que elige “Ocean” en el selector de color y el desarrollador que escribe bg-ocean obtienen el mismo valor, porque los dos leen la misma variable. Cambiar el color en theme.json cambia también la utility, sin recompilar Tailwind, porque la clase solo contiene la referencia var().
La misma página de la documentación da dos reglas que se pasan por alto con facilidad en un tema. Las variables de @theme deben declararse en el nivel superior del archivo, nunca dentro de un selector ni de una media query. Las variables que no deben generar utilities (por ejemplo, la altura de una cabecera fija que solo usa el CSS de un bloque) se declaran en :root, no en @theme.
Los espaciados funcionan de otra manera. Tailwind v4 calcula su escala a partir de una sola variable --spacing (0.25rem por defecto), mientras que WordPress genera un preset por paso, como --wp--preset--spacing--50 (espaciados en el Theme Handbook). Para los márgenes y rellenos que los editores pueden cambiar, usa las variables de WordPress directamente en el CSS del bloque; deja la escala de Tailwind para el layout interno de las plantillas.
Clases de Tailwind en el markup de los bloques de Gutenberg
Tres reglas pragmáticas para el markup de bloques con Tailwind.
Usa 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.
Usa 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.
Evita 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. Define el token en theme.json o amplía la escala en el bloque @theme del archivo CSS de entrada.
En el inspector del editor, registra 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.
Qué archivos de un tema de WordPress escanea Tailwind v4
Tailwind v4 detecta las clases sin configuración: trata cada archivo como texto plano, busca tokens que parezcan clases y descarta los que no corresponden a ninguna utility (detección de clases). En un block theme eso incluye las plantillas HTML de templates/ y parts/, los patrones PHP de patterns/ y los archivos render.php de los bloques. Quedan fuera los archivos listados en .gitignore, node_modules, los binarios, los archivos CSS y los lockfiles de los gestores de paquetes.
Tres consecuencias prácticas en WordPress:
Las clases guardadas en la base de datos no existen para Tailwind. Las clases que un editor añade a un bloque en el editor, o las que llegan con un patrón insertado en una entrada, viven en post_content, no en los archivos del tema. Tailwind no las ve y no genera su CSS. Si el equipo editorial debe poder usar un conjunto fijo de clases, regístralo con @source inline(), que admite expansión de llaves:
@import "tailwindcss";
@source inline("{md:,}grid-cols-{2,3,4}");Los nombres de clase construidos en PHP no se generan. Tailwind no interpreta concatenaciones: 'text-' . $color . '-600' no deja en el archivo ninguna clase completa. Escribe la clase completa en cada rama de la condición, igual que recomienda la documentación para cualquier lenguaje de plantillas.
Las rutas fuera del tema hay que declararlas. Si los bloques viven en un plugin propio, regístralo con @source "../../plugins/bloques-del-sitio";. Si el directorio vendor/ de Composer no está en .gitignore, @source not "../vendor"; evita que Tailwind recorra miles de archivos PHP de terceros en cada build.
Por qué los estilos de bloques de WordPress ganan a las utilities de Tailwind
Tailwind v4 coloca su salida en cuatro capas declaradas en este orden: theme, base, components y utilities (Preflight). La regla de cascada decisiva está en MDN: las declaraciones normales fuera de una capa siempre ganan a las declaradas dentro de capas, y entre declaraciones !important el orden se invierte. WordPress no usa capas. Además, en WordPress 7.0 las clases de presets como .has-ocean-color llevan !important en el CSS que genera la clase WP_Theme_JSON, así que un color elegido en el editor se impone a cualquier utility de color sin !important.
Para el trabajo diario salen dos reglas. Las utilities funcionan sin fricción en las propiedades que el core no define. Cuando el core sí define una propiedad, cambia el valor en la sección styles de theme.json, para que el editor y el front-end muestren lo mismo, en lugar de pelear con la cascada desde el markup.
Preflight merece una revisión aparte. También vive en la capa base, pero actúa sobre el contenido que escriben los editores: elimina los márgenes de todos los elementos, deja los encabezados con el tamaño y el peso del texto normal, quita las viñetas y los números de las listas y convierte las imágenes en display: block. Allí donde ni theme.json ni el core definen esos valores, el contenido de las entradas pierde su formato. Si el tema ya define sus estilos base en theme.json, puedes importar Tailwind sin Preflight:
@layer theme, base, components, utilities;
@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/utilities.css" layer(utilities);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. Tailwind elimina las clases no usadas en el build de producción y, según la página principal de Tailwind, la mayoría de los proyectos con Tailwind envían menos de 10 kB de CSS al cliente. Mide tu propio bundle después de la compresión.
- 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.
Tailwind también documenta la velocidad del build. Según el anuncio de v4.0, en sus propios proyectos los rebuilds completos son más de 3,5 veces más rápidos y los incrementales más de 8 veces más rápidos que en v3. Eso acorta el ciclo de build y del modo watch del tema. El tamaño final del CSS depende de las clases que aparezcan en las plantillas, no del motor.
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. Carga 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. Define la paleta en theme.json y después asóciala como tokens de Tailwind.
CSS de plugins que sobrescribe Tailwind. Algunos plugins antiguos se cargan tarde y, como su CSS no usa capas, gana a cualquier utility de Tailwind con independencia del orden. :where() no sirve para subir la especificidad: según MDN, su especificidad es siempre cero, y WordPress lo usa precisamente para limitar la especificidad de los estilos globales (:root :where(...)). Escribe la corrección como CSS sin capa en un archivo propio del tema, cargado después del plugin y con un selector algo más específico que el suyo.
Arbitrary spacing en el markup. Como se ha dicho, arruina la experiencia en el editor. Cíñete a la escala de espaciados.
Tutoriales de Tailwind v3 aplicados a v4. Tailwind CSS v4.0 estable se publicó el 22 de enero de 2025 (anuncio oficial). Muchos tutoriales de WordPress siguen mostrando tailwind.config.js y las directivas @tailwind; en v4 basta con @import "tailwindcss" y la configuración va en @theme. Mezclar los dos estilos en un mismo tema produce un build que el equipo deja de entender al cabo de unos meses.
Qué navegadores soporta Tailwind v4 en un sitio WordPress
La funcionalidad central de Tailwind CSS v4.0 depende de Chrome 111 y Safari 16.4 (ambos de marzo de 2023) y de Firefox 128 (julio de 2024), según la página de compatibilidad. El framework se apoya en cascade layers, propiedades registradas con @property y color-mix() (anuncio de v4.0). Antes de migrar un tema de v3 a v4, revisa en las analíticas del sitio qué parte del tráfico llega con navegadores anteriores a esas versiones.
La misma página señala dos límites más. Algunas utilities usan funciones con soporte limitado, como field-sizing: content, @starting-style o text-wrap: balance; si los navegadores de tu público no las soportan, no las uses. Y v4 no está pensado para combinarse con Sass, Less o Stylus, porque Tailwind ya cumple el papel de preprocesador. Un tema heredado con style.scss tiene que pasar sus variables a @theme y a CSS nativo antes de compilar con Tailwind v4.
Tailwind CSS en headless WordPress
Cuando Astro 5 o Next.js 15 sustituye al front-end de WordPress (consulta 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, úsalo como punto de partida y recurre a la página de servicios de headless WordPress para el resto de la arquitectura.
Lecturas relacionadas
- Servicio de headless WordPress
- Servicio de desarrollador Astro
- Cloudflare Workers y WordPress en el edge
- Tech Radar Q4 2026: veredictos sobre el stack
En la implementación, encuadramos este tema dentro de GEO y LLMO.
