# Tailwind ou Bootstrap sans purge : le poids CSS qui plombe un thème

> Un thème qui embarque tout Bootstrap ou tout Tailwind sans purge des classes inutilisées charge parfois 200 Ko de CSS mort. Ce qu'on observe et comment configurer PurgeCSS.

- Auteur : Clément Hadrot
- Publié le : 2024-09-18
- Mis à jour le : 2024-09-18
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/tailwind-bootstrap-sans-purge-poids-css-theme/

## L’essentiel

- Un fichier CSS complet peut peser dix fois plus que nécessaire
- PurgeCSS supprime les classes absentes des templates PHP
- Les classes générées dynamiquement demandent une liste de sécurité

Ce qu'on voit régulièrement en auditant des thèmes WordPress sur mesure construits avec Bootstrap ou Tailwind : un unique fichier `style.css` ou `bootstrap.min.css` de 150 à 250 Ko, chargé sur toutes les pages du site, alors que le thème n'utilise en pratique qu'une fraction des classes utilitaires disponibles dans le framework. Sur un thème inspecté récemment, construit avec Tailwind CSS en version compilée complète (sans configuration de purge), le fichier pesait 218 Ko alors que l'analyse du code PHP du thème montrait un usage réel de moins de 400 classes différentes sur plus de 40 000 générées par défaut.

## Pourquoi c'est un problème pour la performance

Un fichier CSS volumineux bloque le rendu de la page : le navigateur doit le télécharger et le parser avant de pouvoir peindre le premier pixel, ce qui pèse directement sur le First Contentful Paint et indirectement sur le LCP. Sur une connexion mobile en 4G moyenne, 200 Ko de CSS supplémentaires représentent facilement 300 à 500 millisecondes de retard avant le premier rendu, un chiffre qui grimpe encore sur les connexions les plus lentes que Google continue de simuler dans ses outils de mesure.

Ce poids n'est pas seulement un problème de bande passante : le navigateur doit aussi calculer la spécificité et appliquer les règles CSS non utilisées pendant le calcul de style, ce qui ajoute un coût de traitement invisible dans les captures réseau mais bien réel dans le profil de rendu.

## Pourquoi c'est un problème répandu sur les thèmes WordPress classiques

Sur une application JavaScript moderne construite avec un bundler comme Vite ou Webpack, la purge CSS fait quasiment toujours partie de la chaîne de build par défaut. Sur un thème WordPress classique en PHP, en particulier ceux construits sans étape de build ou avec une configuration minimale, il est fréquent de simplement télécharger le CSS compilé de Bootstrap ou de Tailwind et de l'inclure tel quel via `wp_enqueue_style()`, sans jamais mettre en place d'étape de purge parce que le thème n'a pas de pipeline de build structuré.

> L'essentiel à retenir : Un fichier CSS complet peut peser dix fois plus que nécessaire ; PurgeCSS supprime les classes absentes des templates PHP ; Les classes générées dynamiquement demandent une liste de sécurité

## Configurer PurgeCSS pour un thème classique

PurgeCSS analyse un ensemble de fichiers sources (ici, les templates PHP du thème) pour repérer les noms de classes réellement utilisés, puis retire du CSS final tout ce qui n'y apparaît pas. La configuration ci-dessous cible spécifiquement les fichiers PHP d'un thème classique, en plus des fichiers JavaScript si le thème en contient.

```
// purgecss.config.js
module.exports = {
  content: [
    './*.php',
    './template-parts/**/*.php',
    './inc/**/*.php',
    './assets/js/**/*.js'
  ],
  css: ['./assets/css/tailwind-build.css'],
  output: './assets/css/style.css',
  safelist: [
    /^wp-/,
    /^has-/,
    /^is-/,
    'sr-only',
    /^js-/
  ]
};
```

### Le piège des classes générées dynamiquement

Le principal risque de la purge automatique est de supprimer une classe utilisée uniquement via une concaténation PHP dynamique, par exemple `'btn-' . $couleur`, que PurgeCSS ne peut pas détecter puisqu'il analyse du texte statique et non l'exécution du code. Sur le thème étudié, deux classes de badges de statut de commande WooCommerce, construites dynamiquement selon l'état de la commande, avaient disparu du CSS après une première purge trop agressive, provoquant un affichage sans style pendant deux jours avant d'être repérées.

La liste de sécurité (`safelist`) ci-dessus couvre ce cas avec des expressions régulières larges, au prix d'un gain de purge légèrement moindre mais d'un risque de casse visuelle très réduit.

## Intégrer la purge dans le flux de travail existant

Sur un thème sans pipeline de build préexistant, la solution la plus simple a été d'ajouter un script npm exécuté manuellement avant chaque mise en production, plutôt que d'imposer un outil de build complet à une équipe habituée à éditer directement les fichiers PHP et CSS.

```
{
  "scripts": {
    "css:purge": "purgecss --config purgecss.config.js"
  }
}
```

- Toujours tester visuellement le site entier après une purge, pas seulement les pages les plus visitées.
- Prévoir une liste de sécurité généreuse pour les classes générées dynamiquement en PHP.
- Régénérer le CSS purgé à chaque changement de template, pas seulement une fois pour toutes.

## Ce que cette approche ne couvre pas

Cette méthode concerne les thèmes classiques construits directement en PHP et CSS. Elle ne traite pas le cas des frameworks CSS embarqués par des constructeurs de pages (page builders), qui gèrent en général leur propre système de génération de styles à la demande, souvent déjà optimisé différemment et avec ses propres contraintes.

> Un framework CSS complet n'est jamais un problème en soi ; c'est le fait de le livrer intégralement à chaque visiteur, alors que 90 % de son contenu ne sert jamais, qui coûte cher.

## Notre verdict

La purge a fait passer le CSS du thème de 218 Ko à 19 Ko, soit une réduction d'un peu plus de 90 %, avec un gain mesuré de 340 millisecondes sur le First Contentful Paint en test de laboratoire sur une connexion 4G simulée. Le coût de mise en place a été d'une demi-journée, essentiellement consacrée à repérer les classes dynamiques à protéger dans la liste de sécurité.