Tailwind CSS et WordPress : le guide complet pour un CSS performant
Vous bossez sur un projet WordPress et vous en avez marre du CSS qui part dans tous les sens ? Des fichiers de 3000 lignes où personne ne sait plus ce qui sert à quoi ? Bienvenue au club 😅 C’est exactement pour ça que Tailwind CSS a changé ma façon de travailler — et celle de pas mal de développeurs WordPress.
Après avoir intégré Tailwind sur une bonne vingtaine de projets WordPress ces dernières années, je peux vous dire que le couple fonctionne remarquablement bien. Mais attention, ce n’est pas un plug-and-play : il y a des pièges, des bonnes pratiques, et un workflow à mettre en place. Je vous explique tout ça.
Tailwind CSS, c’est quoi exactement ? 🎯
Pour ceux qui débarquent : Tailwind CSS est un framework CSS « utility-first ». Au lieu d’écrire des classes sémantiques comme .card-header et de définir leurs styles dans un fichier séparé, vous appliquez des classes utilitaires directement dans votre HTML : flex items-center gap-4 p-6 bg-white rounded-lg shadow-md.
Ça fait bizarre au début — j’avoue que la première fois que j’ai vu un template Tailwind, j’ai eu un léger mouvement de recul 😬 Tout ce HTML plein de classes, ça ressemble à du inline CSS déguisé. Mais une fois qu’on a passé le cap, on comprend la puissance du truc : plus besoin de naviguer entre 15 fichiers CSS, plus de noms de classes inventés à la volée, et surtout un CSS final ultra-léger grâce au purge automatique.
Pourquoi Tailwind plutôt que Bootstrap ou du CSS classique ?
La question revient souvent chez mes clients. Voici ma réponse de terrain :
- Bootstrap vous impose un design. Tailwind vous donne des briques pour construire le vôtre. Sur un projet WordPress sur mesure, c’est jour et nuit.
- Le CSS classique (même bien organisé en BEM) finit toujours par grossir. Sur un gros site WordPress avec 50+ templates, on se retrouve vite avec du CSS mort partout.
- Tailwind + purge = un fichier CSS final de quelques Ko seulement. Les performances s’en ressentent directement sur les Core Web Vitals.
Cela dit, soyons clairs : Tailwind reste un compromis. Sur mes projets, ma préférence va toujours au CSS BEM custom — c’est la forme la plus propre, la plus performante et la plus maintenable de coder du CSS. Tailwind, c’est une bonne option quand le budget est plus serré et qu’il faut aller vite. Mais si vous avez le choix, un site entièrement en CSS natif BEM sera toujours supérieur en qualité, en performances et en maintenabilité sur le long terme 💪
Tailwind CSS et WordPress : le setup qui marche 🔧
Installer Tailwind sur un thème WordPress classique, c’est possible mais pas idéal. Le vrai confort, c’est avec un stack moderne type Bedrock + Sage (par Roots.io). C’est d’ailleurs le setup que j’utilise sur tous mes projets — y compris ce site.
L’architecture idéale : Bedrock + Sage + Tailwind
Si vous travaillez avec Sage 11 (la dernière version du starter theme de Roots), Tailwind est déjà intégré par défaut. C’est prêt à l’emploi. Voici ce que ça donne concrètement :
- Bedrock gère la structure du projet WordPress (séparation du core, gestion des dépendances via Composer)
- Sage 11 fournit le thème avec Laravel Blade comme moteur de template
- Bud (le bundler de Roots) compile tout : Tailwind, PostCSS, JavaScript
- Tailwind CSS s’occupe du styling avec son fichier
tailwind.config.js
Le résultat ? Un workflow de développement fluide où chaque modification CSS est visible instantanément grâce au hot reload, et un CSS de production optimisé automatiquement.
Et sans Sage ? C’est possible aussi
Si vous avez un thème custom existant ou si vous ne voulez pas passer sur Sage, Tailwind s’intègre quand même. Il faut juste un peu plus de configuration :
- Installer Node.js et npm dans votre projet
- Ajouter Tailwind via
npm install tailwindcss postcss autoprefixer - Configurer
tailwind.config.jspour scanner vos fichiers PHP/Blade/HTML - Créer un fichier CSS source avec les directives
@tailwind base; @tailwind components; @tailwind utilities; - Ajouter un script de build dans votre
package.json
L’étape cruciale, c’est la configuration du content dans tailwind.config.js. Il faut que Tailwind sache où chercher les classes utilisées pour ne garder que celles-ci dans le CSS final :
module.exports = {
content: [
'./templates/**/*.php',
'./parts/**/*.php',
'./patterns/**/*.php',
'./inc/**/*.php',
'./js/**/*.js',
],
theme: {
extend: {},
},
plugins: [],
}Si vous oubliez un dossier dans cette config, les classes Tailwind utilisées dedans disparaissent du CSS compilé. J’ai vu plus d’un dev s’arracher les cheveux là-dessus 😅
Pourquoi le CSS BEM custom reste supérieur 💪
C’est là que ça devient intéressant. Tailwind c’est bien pour aller vite, mais quand on compare objectivement avec du CSS BEM custom bien structuré, y’a pas photo. Le BEM gagne sur quasiment tous les points. Et c’est pour ça que je le recommande systématiquement quand le projet le permet.
Le problème du « tout utility »
Sur un site WordPress complexe avec des dizaines de composants (header sticky, mega menu, cards produits, sliders, accordéons FAQ, formulaires multi-étapes…), le tout-Tailwind atteint ses limites :
- Les templates deviennent illisibles avec des lignes de 200+ caractères de classes
- Les états complexes (hover, focus, responsive, dark mode) multiplient encore les classes
- La réutilisation se fait via
@apply… qui revient finalement à écrire du CSS classique mais en moins lisible - Le debug dans le navigateur devient pénible quand chaque élément a 25 classes
CSS BEM : la Rolls du CSS sur WordPress
Sur mes projets les plus exigeants, je travaille en CSS BEM custom pur. Chaque composant a sa propre feuille de styles, avec des noms de classes sémantiques et une architecture prévisible. Résultat : un CSS ultra-performant, zéro surcharge dans le DOM, et un code que n’importe quel développeur peut reprendre en 5 minutes.
Tailwind, lui, je le réserve aux projets où le budget impose d’aller plus vite — et dans ce cas, il fait très bien le job. Mais c’est un compromis vitesse/qualité, pas un idéal.
Prenons un exemple concret. Un composant de card service :
<!-- Layout Tailwind + composant BEM -->
<div class="grid grid-cols-1 md:grid-cols-3 gap-8 px-4 lg:px-0">
<article class="service-card">
<div class="service-card__icon">...</div>
<h3 class="service-card__title">Développement sur mesure</h3>
<p class="service-card__description">...</p>
<a href="#" class="service-card__cta">En savoir plus</a>
</article>
</div>Voyez le composant .service-card : des classes sémantiques, lisibles, maintenables. Pas besoin de déchiffrer 25 classes utilitaires pour comprendre ce que fait l’élément. Le CSS BEM, c’est un code qui se documente tout seul.
Résultat : un CSS final encore plus léger qu’avec Tailwind (oui, le BEM bien structuré est plus performant — moins de classes dans le DOM, moins de poids HTML, CSS ciblé au pixel près), et un code source limpide pour toute l’équipe.
Tailwind dans l’éditeur Gutenberg 📝
C’est LE point qui fait grincer des dents beaucoup de développeurs WordPress. Gutenberg et Tailwind, c’est pas un mariage naturel. Voici pourquoi et comment je gère ça.
Le défi : le back-office vs le front
Gutenberg a son propre système de styles. Quand un utilisateur ajoute un bloc paragraphe ou un bloc image dans l’éditeur, WordPress applique ses propres classes CSS. Tailwind ne connaît pas ces classes, et Gutenberg ne connaît pas les vôtres. Deux mondes parallèles.
Pour que l’éditeur ressemble au front (le fameux WYSIWYG), il faut charger vos styles Tailwind dans l’éditeur aussi. Avec Sage et Bud, ça se fait via le fichier editor.css qui est automatiquement injecté dans Gutenberg.
Les blocs custom Gutenberg avec Tailwind
Quand je développe des blocs Gutenberg sur mesure, j’applique la même logique. Le markup du bloc utilise Tailwind pour le layout rapide, et chaque composant visuel a son propre fichier BEM. L’avantage : les blocs sont consistants entre l’éditeur et le front, et le CSS reste léger.
Un point important : pensez à inclure vos templates de blocs dans la config content de Tailwind. Sinon, les classes utilisées dans vos blocs seront purgées du CSS final. Erreur classique qui fait perdre du temps 🙃
Les performances : Tailwind vs CSS classique sur WordPress 🚀
C’est souvent l’argument massue en faveur de Tailwind : les performances. Et c’est justifié, mais avec des nuances.
Le poids du CSS : la différence est réelle
Sur un projet WordPress classique avec un thème custom, le CSS compilé fait facilement entre 200 et 500 Ko. Avec Tailwind + purge, on tombe à 10-30 Ko. C’est pas la même planète.
Moins de CSS = moins de temps de parsing par le navigateur = un meilleur score sur les Core Web Vitals, notamment le CLS et le LCP. Pour le SEO et les performances de votre site WordPress, c’est un levier non négligeable.
Attention au CSS mort des plugins
Tailwind optimise VOTRE CSS. Mais sur un site WordPress, il y a aussi le CSS de WooCommerce, de Contact Form 7, de vos plugins divers… Tout ça s’accumule. J’ai déjà audité des sites où le CSS des plugins représentait 80% du poids total.
Ma recommandation : combiner Tailwind avec un travail d’optimisation global. Désactiver le CSS des plugins sur les pages où ils ne sont pas utilisés, minifier, combiner les fichiers critiques, utiliser le critical CSS inline. C’est ce genre de travail qui fait la vraie différence sur les performances.
L’impact sur le HTML
Un effet secondaire de Tailwind : le HTML grossit un peu à cause de toutes ces classes utilitaires. Mais entre un HTML qui fait 5 Ko de plus et un CSS qui fait 400 Ko de moins, le calcul est vite fait. Et avec la compression gzip/brotli, les classes Tailwind (qui sont très répétitives) se compressent remarquablement bien.
Le responsive avec Tailwind sur WordPress 📱
Si il y a un domaine où Tailwind brille particulièrement, c’est le responsive design. Et sur WordPress, où chaque page peut avoir un layout différent, c’est un vrai gain de productivité.
Les breakpoints intégrés
Avec Tailwind, le responsive se gère directement dans le HTML :
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4 md:gap-6 lg:gap-8">
<!-- Vos éléments -->
</div>Plus besoin d’ouvrir un fichier CSS, de trouver la bonne media query, d’ajouter vos règles, de vérifier que rien ne casse ailleurs… Tout est co-localisé avec le markup. Quand vous modifiez un composant, vous voyez immédiatement comment il se comporte sur chaque breakpoint.
Personnaliser les breakpoints pour WordPress
Les breakpoints par défaut de Tailwind (sm: 640px, md: 768px, lg: 1024px, xl: 1280px, 2xl: 1536px) conviennent à 90% des projets. Mais sur certains sites WordPress — notamment les sites vitrines avec des sections plein écran ou les e-commerce avec des grilles produits complexes — j’ajoute des breakpoints custom :
// tailwind.config.js
module.exports = {
theme: {
screens: {
'xs': '375px', // Pour les petits mobiles
'sm': '640px',
'md': '768px',
'lg': '1024px',
'xl': '1280px',
'2xl': '1440px', // Adapté aux écrans courants
'3xl': '1920px', // Full HD
},
},
}Le xs est particulièrement utile pour gérer les iPhone SE et autres petits écrans qui cassent souvent les layouts prévus pour 390px+.
Les erreurs courantes à éviter ⚠️
Après des années à bosser avec Tailwind sur WordPress, voici les pièges que je vois le plus souvent :
1. Ne pas configurer le purge correctement
C’est l’erreur numéro un. Si votre fichier CSS compilé fait 3 Mo en production, c’est que le purge ne fonctionne pas. Vérifiez votre content dans tailwind.config.js. Chaque dossier contenant du markup doit y figurer.
2. Abuser de @apply
La directive @apply permet d’utiliser des classes Tailwind dans du CSS classique. C’est pratique, mais si vous l’utilisez partout, vous perdez tout l’intérêt de Tailwind. Autant écrire du CSS normal à ce stade. Réservez @apply aux cas où vous avez vraiment besoin de réutiliser un groupe de classes (composants BEM, styles de base).
3. Oublier l’éditeur Gutenberg
Vos styles Tailwind doivent aussi être chargés dans le back-office WordPress. Sinon, le contenu dans l’éditeur ne ressemblera pas au front, et vos clients vont vous appeler toutes les cinq minutes 😅 Avec Sage, c’est géré nativement. Sur un thème custom, il faut ajouter manuellement le stylesheet dans l’éditeur via add_editor_style().
4. Ignorer les classes dynamiques
Le purge de Tailwind analyse vos fichiers de manière statique. Si vous générez des classes dynamiquement en PHP ou JavaScript (par exemple $class = 'bg-' . $color . '-500'), Tailwind ne les trouvera pas et les supprimera du CSS final. Il faut utiliser les safelist ou écrire les classes complètes en dur.
5. Ne pas versionner le tailwind.config.js
Ça paraît évident, mais je l’ai vu arriver. Le fichier de config Tailwind fait partie intégrante de votre design system. Il contient vos couleurs, vos polices, vos espacements custom. Perdre ce fichier, c’est perdre la cohérence de tout votre site. Git, toujours Git.
Tailwind CSS et le workflow d’intégration WordPress 🛠️
Concrètement, quand je reçois des maquettes Figma pour un projet WordPress, voici mon workflow avec Tailwind :
- Analyse des maquettes : j’identifie les composants récurrents, la grille utilisée, la palette de couleurs, la typographie
- Configuration Tailwind : je traduis le design system dans
tailwind.config.js— couleurs custom, fonts, espacements spécifiques - Structure CSS : idéalement, tout en CSS BEM custom. Si le budget est plus serré, Tailwind pour le layout rapide
- Intégration : templates Blade avec un CSS propre et performant, quelle que soit l’approche choisie
- Responsive : je teste sur chaque breakpoint et ajuste directement dans le markup
- Optimisation : build de production avec purge, minification, extraction du critical CSS
Ce workflow me permet de livrer des sites performants et maintenables, quel que soit le budget. Et c’est un point que je mets souvent en avant auprès de mes clients : investir dans du CSS BEM custom, c’est investir dans un site qui coûtera moins cher à faire évoluer. Tailwind fait le job quand il faut optimiser les coûts, mais le sur-mesure BEM reste la référence 👌
Tailwind, WordPress et le SEO : quel impact ? 📊
Google ne regarde pas si vous utilisez Tailwind ou du CSS vanilla. Ce qui l’intéresse, c’est le résultat : le temps de chargement, la stabilité visuelle, l’accessibilité.
Et sur ces trois critères, un site WordPress bien intégré avec Tailwind a un avantage :
- Temps de chargement : CSS ultra-léger = moins de ressources bloquantes = meilleur LCP
- Stabilité visuelle : pas de FOUC (Flash of Unstyled Content) grâce au CSS critique inline
- Accessibilité : Tailwind encourage les bonnes pratiques avec ses classes
sr-only,focus-visible, etc.
J’ai mesuré des gains de 15 à 30 points sur PageSpeed Insights rien qu’en passant du CSS classique à Tailwind + purge sur des sites WordPress existants. C’est significatif, surtout pour le SEO technique qui prend de plus en plus de poids dans les algorithmes de Google.
Faut-il passer à Tailwind sur un site WordPress existant ? 🤔
La réponse honnête : ça dépend. Voici mon analyse selon les situations :
Oui, si…
- Vous prévoyez une refonte de votre site WordPress — c’est le moment idéal pour migrer vers Tailwind
- Votre CSS actuel est un cauchemar (fichiers énormes, pas de convention, CSS mort partout)
- Vous avez besoin de meilleures performances et que votre CSS est un goulot d’étranglement
- Votre équipe de développement connaît déjà Tailwind
Non, si…
- Votre site fonctionne bien, le CSS est propre et maintenable — on ne change pas une équipe qui gagne
- Vous utilisez un page builder (Elementor, Divi) — Tailwind n’apporte rien dans ce contexte
- Personne dans l’équipe ne maîtrise l’outil — la courbe d’apprentissage est réelle
- Le budget ne permet pas une refonte du front — une migration partielle créerait plus de problèmes qu’elle n’en résoudrait
Si vous hésitez, n’hésitez pas à me contacter pour en discuter. C’est le genre de décision technique où un avis extérieur peut éviter des erreurs coûteuses. Je travaille en full remote avec des clients dans toute la France — que vous soyez à Lille, Paris, Bordeaux ou ailleurs, la distance n’est jamais un frein 🚀
FAQ — Tailwind CSS et WordPress
Non, c'est même l'inverse. Grâce au système de purge, Tailwind génère un CSS final beaucoup plus léger que du CSS classique (10-30 Ko contre 200-500 Ko). Le site charge plus vite et les Core Web Vitals s'améliorent.
Oui, tout à fait. Il faut cependant gérer la cohabitation entre les styles Tailwind et ceux de WooCommerce. La méthode recommandée : utiliser Tailwind pour votre thème custom et surcharger les styles WooCommerce de manière ciblée plutôt que de tout réécrire.
Oui, Tailwind ne remplace pas la connaissance CSS — il l'accélère. Comprendre flexbox, grid, le modèle de boîte et le positionnement reste indispensable. Tailwind est un outil de productivité, pas un raccourci pour éviter d'apprendre CSS.
Ça dépend de la taille du site et de la complexité du thème actuel. Pour une refonte complète du front-end avec Tailwind, comptez entre 3 et 10 jours de développement selon le nombre de templates. C'est un investissement qui se rentabilise sur la maintenance à long terme.
Oui, mais ça demande une configuration spécifique pour que les styles soient chargés dans l'éditeur back-office. Avec un stack Sage/Bud, c'est géré nativement. Sur un thème custom, il faut ajouter manuellement le stylesheet via add_editor_style().