Un thème bloc à 400 Ko de CSS généré : où partent les octets

Un client dans l’événementiel avait commandé un thème bloc avec sept variations de style différentes, une par type d’événement organisé (mariage, séminaire d’entreprise, anniversaire, etc.), chacune changeant la palette de couleurs et quelques préréglages typographiques. L’équipe de développement avait ajouté ces variations progressivement, sans jamais remesurer l’impact cumulé sur le poids du CSS de styles globaux généré par WordPress. Un audit de performance commandé par le client a révélé un fichier de style généré dépassant 400 kilo-octets, chargé intégralement sur chaque page, quelle que soit la variation réellement active.

Ce cas décrit le diagnostic réseau mené et les pistes de réduction retenues. La minification générale des assets (concaténation, compression gzip côté serveur), déjà en place et correctement configurée sur ce projet, n’est pas le sujet de cet article : le problème se situait en amont, dans la génération même du CSS.

Constat initial : un poids anormal pour un thème bloc

En inspectant l’onglet réseau du navigateur sur la page d’accueil du site, la feuille de style des styles globaux, générée dynamiquement par WordPress à partir de theme.json et de ses variations, pesait à elle seule 412 kilo-octets non compressés, contre une moyenne habituelle de 40 à 80 kilo-octets observée sur des thèmes blocs comparables suivis par ailleurs. Ce poids restait constant quelle que soit la variation de style réellement sélectionnée par l’administrateur du site, ce qui constituait le premier indice du problème : tout était chargé, tout le temps, indépendamment de ce qui était réellement affiché.

Diagnostic : chaque variation duplique l’intégralité de la déclaration

En examinant le dossier styles/ du thème, sept fichiers JSON de variation existaient, chacun redéclarant l’intégralité des sections settings.color, settings.typography et styles, plutôt que de ne surcharger que les valeurs réellement différentes d’une variation à l’autre. WordPress génère effectivement un jeu de règles CSS séparé pour chaque variation disponible, même si l’utilisateur n’en a sélectionné qu’une seule à un instant donné, car le mécanisme des variations de style est conçu pour permettre un changement instantané depuis l’éditeur de site, ce qui suppose que tout le CSS nécessaire soit déjà présent.

ls styles/
mariage.json      seminaire.json     anniversaire.json
gala.json         baptême.json       depart-retraite.json
noel-entreprise.json

Chaque fichier, au lieu de ne déclarer que les couleurs propres à son thème visuel, redéclarait également l’ensemble des tailles de police, des espacements et des styles de blocs communs à toutes les variations, dupliquant ainsi des centaines de lignes de CSS strictement identiques d’un fichier à l’autre.

Un facteur aggravant : les duos de couleurs générés automatiquement

En creusant plus loin, une partie significative du poids provenait des préréglages color.duotone déclarés dans chaque variation, utilisés pour un effet de superposition colorée sur les photographies d’ambiance de chaque type d’événement. Chaque duo de couleurs génère son propre filtre SVG et sa classe CSS associée, et sept variations multipliées par plusieurs duos par variation représentaient à elles seules près de 90 kilo-octets du poids total mesuré, pour un effet visuel utilisé sur moins d’une dizaine d’images au total sur l’ensemble du site.

{
  "settings": {
    "color": {
      "duotone": [
        { "slug": "mariage-duotone", "colors": [ "#7a1f2b", "#faf6ef" ] },
        { "slug": "mariage-duotone-alt", "colors": [ "#7a1f2b", "#c9a24b" ] }
      ]
    }
  }
}

Pistes de réduction retenues

• Fusionner les sections communes de typographie et d’espacement dans un fichier theme.json de base unique, chaque variation ne redéclarant plus que ses couleurs réellement distinctives.
• Réduire chaque variation à un seul duo de couleurs au lieu de deux ou trois déclinaisons rarement utilisées en pratique par l’équipe éditoriale du client.
• Fusionner deux variations quasiment identiques visuellement (« baptême » et « anniversaire » partageaient la même palette pastel) en une seule variation renommée plus génériquement.

Après ces trois ajustements, le poids du CSS de styles globaux est retombé à environ 105 kilo-octets, soit une réduction proche des trois quarts par rapport à la mesure initiale, sans qu’aucune fonctionnalité visuelle réellement utilisée par le client n’ait été retirée.

Vérifier le résultat après correction

curl -s https://exemple-evenementiel.fr/ | grep -o 'wp-content/uploads/[^"]*global-styles[^"]*'

Une seconde mesure réseau après déploiement a confirmé la baisse de poids, avec un temps de génération du style global également amélioré côté serveur, la construction du CSS à partir de moins de duplication de règles demandant elle-même moins de traitement.

Ce qui reste à surveiller pour la suite

Sur un thème bloc à variations multiples, chaque nouvelle variation ajoutée doit être pensée comme un coût réseau fixe payé par tous les visiteurs, pas comme une simple option d’affichage gratuite pour l’administrateur du site.

Le client a été prévenu qu’ajouter une huitième variation à l’avenir referait grimper le poids proportionnellement, et qu’un audit similaire mériterait d’être reconduit avant toute nouvelle extension de la bibliothèque de styles du thème.

En résumé

Le poids anormal du CSS généré ne venait ni d’un plugin ni d’un défaut de minification, mais d’une architecture de variations de style qui dupliquait systématiquement des déclarations communes et multipliait des préréglages de duo de couleurs rarement utilisés. Réduire la duplication entre variations et limiter les combinaisons de couleurs générées a suffi à diviser le poids par quatre, sans toucher à la moindre configuration serveur.