Réduire le poids des pages Divi : purge du CSS inutilisé et chargement différé

Un constructeur visuel doit pouvoir afficher n'importe quel module dans n'importe quelle configuration, ce qui l'oblige à charger une bibliothèque de styles et de scripts couvrant l'ensemble des possibilités. Sur une page qui n'emploie que six modules, l'essentiel de ce chargement ne sert à rien. Les versions récentes du thème proposent des options de performance qui traitent une bonne partie du problème, à condition de savoir lesquelles activer et dans quel ordre. Le reste se règle par un nettoyage des ressources inutiles et par un travail sur les images, qui pèsent souvent davantage que tout le code réuni.

Comprendre ce qui pèse

Avant d'activer quoi que ce soit, il faut mesurer d'où vient le poids réel, faute de quoi l'effort se porte sur ce qui est visible plutôt que sur ce qui compte. Une analyse de dix minutes avec les outils du navigateur donne cette répartition. Le fonctionnement général du constructeur est présenté dans notre article sur le Theme Builder de Divi et son guide complet.

La feuille de style principale

Le thème charge une feuille couvrant l'ensemble des modules disponibles, dont le poids se compte en centaines de kilooctets avant compression. Sur une page employant une poignée de modules, la proportion réellement utilisée descend souvent sous les dix pour cent. C'est le poste le plus spectaculaire et il se traite bien avec les options natives. Il n'est pas toujours le plus coûteux en temps d'affichage, un fichier de style compressé et mis en cache pesant moins qu'il n'y paraît. Le poids annoncé par les outils correspond en effet au fichier non compressé, ce qui exagère la perception du problème.

Les scripts des modules

Les animations, les onglets, les diaporamas et les effets au défilement reposent sur des scripts chargés globalement. Leur exécution consomme du temps de traitement sur le fil principal, ce qui dégrade la réactivité aux interactions. Ce coût est moins visible que le poids brut et il pèse davantage sur les mesures d'expérience. Il se traite par la désactivation des fonctions inutilisées plutôt que par la compression. Comprimer un script qui s'exécute longtemps ne change rien à son temps d'exécution, seulement à son temps de téléchargement.

Les polices d'icônes

Le thème embarque une bibliothèque d'icônes complète, chargée intégralement pour afficher les quelques symboles employés sur la page. Ce fichier pèse plusieurs dizaines de kilooctets et il bloque parfois l'affichage du texte. Sa désactivation est proposée dans les réglages lorsque le site n'emploie aucune icône, ce qui est rare. Un découpage de la police aux seuls symboles utilisés est possible avec un peu de travail. Remplacer les quelques icônes employées par des images vectorielles intégrées supprime le fichier entier, solution radicale et efficace.

Les images

Les bandeaux pleine largeur invitent à téléverser des fichiers volumineux, et le poids des images dépasse fréquemment celui de toutes les autres ressources réunies. Une seule photographie mal préparée annule le bénéfice de toutes les optimisations de code. C'est le poste à traiter en premier, avant de toucher au thème. Il est aussi le plus facile à corriger et le plus souvent négligé. Une revue des dix images les plus lourdes du site suffit généralement à identifier l'essentiel du gain disponible.

Les ressources tierces

Les scripts de mesure, les widgets sociaux, les cartes et les outils de discussion s'ajoutent au poids du thème et ils échappent à ses options. Sur beaucoup de sites, ils représentent la moitié du poids total. Les inventorier avant d'optimiser le thème évite de consacrer une journée à gagner ce qu'un seul script tiers reprend. Cet inventaire se fait dans l'onglet réseau du navigateur, en triant par domaine. Il conduit régulièrement à retirer purement et simplement un ou deux services que plus personne n'utilise.

Mesurer avant d'agir

Un relevé du poids total, du nombre de requêtes et des indicateurs d'expérience avant intervention donne le point de comparaison. Sans lui, l'appréciation du résultat repose sur une impression. Ce relevé doit porter sur plusieurs gabarits, la page d'accueil et une page intérieure ne se comportant pas de la même façon. Il prend dix minutes et il oriente tout le travail qui suit. Le conserver dans un tableau permet de mesurer le gain de chaque intervention plutôt que celui de l'ensemble.

Les options natives de performance

Les versions récentes proposent un ensemble de réglages dédiés, souvent laissés à leurs valeurs par défaut sur les sites installés il y a quelques années.

Les fichiers CSS statiques

Cette option produit un fichier de styles propre à chaque page, écrit sur le disque, plutôt qu'un calcul à chaque affichage. Le gain est immédiat sur le temps de réponse du serveur et il ne présente aucun risque. Elle demande de vider le répertoire concerné après une modification globale du style, opération accessible depuis les réglages. Elle est activée par défaut sur les versions récentes et elle mérite d'être vérifiée sur les installations anciennes. Le répertoire concerné peut grossir fortement sur un site comptant de nombreuses pages, ce qui justifie un nettoyage occasionnel.

Le CSS dynamique par module

Une option plus récente ne charge que les styles des modules réellement présents sur la page, ce qui divise couramment par cinq le poids de la feuille. C'est l'option la plus efficace de toutes et elle demande un contrôle visuel après activation. Certains modules construits avant son introduction, ou fournis par des extensions tierces, peuvent perdre leur mise en forme. Le contrôle porte donc sur les gabarits employant ces modules. Une liste écrite de trois ou quatre pages représentatives, parcourue après activation, suffit à trancher en quelques minutes.

Le JavaScript dynamique

Le même principe s'applique aux scripts, chargés selon les modules présents. Le gain porte moins sur le poids que sur le temps d'exécution, ce qui améliore les indicateurs de réactivité. Cette option casse plus facilement que la précédente, notamment sur les modules reposant sur des interactions complexes. Elle doit être activée seule, avec un contrôle complet des éléments interactifs du site. C'est le réglage qui produit le plus de retours en arrière, ce qui n'enlève rien à son intérêt lorsqu'il tient.

Le report du chargement des ressources

Une option retarde le chargement des styles et des scripts jusqu'à l'interaction ou au défilement. Elle améliore nettement les mesures d'affichage initial et elle produit parfois un scintillement visible au premier défilement. Ce compromis doit être évalué sur le site réel plutôt que sur la promesse. Sur une page d'accueil très visuelle, l'effet est souvent jugé inacceptable par le client. Il vaut mieux le lui montrer avant de trancher, la perception de ce défaut variant fortement d'une personne à l'autre.

La désactivation des icônes inutilisées

Un réglage permet de ne charger que le sous ensemble d'icônes réellement employé, lorsque le site n'en utilise que quelques unes. Le gain est modeste et sans risque, à condition de vérifier que toutes les icônes affichées appartiennent au sous ensemble retenu. Une icône manquante se voit immédiatement, ce qui rend le contrôle simple. C'est une option à activer en fin de parcours. Son gain se compte en dizaines de kilooctets, ce qui la rend accessoire par rapport aux options précédentes.

Le retrait des ressources héritées

Plusieurs réglages permettent de ne plus charger des bibliothèques conservées pour compatibilité avec d'anciennes versions. Elles ne servent qu'aux sites construits il y a plusieurs années et non repris depuis. Les désactiver sur un site récent est sans effet visible et sans risque. Sur un site ancien, un contrôle attentif s'impose, certains modules pouvant en dépendre. En cas de doute, laisser ces réglages en l'état coûte quelques kilooctets et évite une régression difficile à diagnostiquer.

Aller plus loin sans casser

Les options natives couvrent l'essentiel et quelques interventions complémentaires apportent un gain supplémentaire, avec des précautions proportionnées.

Purger le style résiduel

Même avec le chargement dynamique, une part du style reste inutilisée sur chaque page. Des outils analysent le rendu et produisent une feuille réduite au strict nécessaire. Cette approche est efficace et délicate : un style employé uniquement après une interaction, ouverture d'un menu par exemple, n'apparaît pas dans l'analyse et se retrouve supprimé. Elle demande donc un contrôle interactif complet et elle se justifie surtout sur les sites où la performance est un enjeu mesuré. Le gain supplémentaire par rapport au chargement dynamique natif reste souvent modeste, ce qui invite à la prudence.

Générer le style critique

Extraire les règles nécessaires à l'affichage de la partie haute de la page, les placer en ligne et charger le reste ensuite améliore nettement le premier affichage. Cette technique est proposée par plusieurs extensions de cache et elle produit un gain réel sur les pages lourdes. Elle exige que le style critique soit régénéré à chaque modification de mise en page, ce qui suppose une automatisation. Sans elle, un style critique périmé produit un affichage initial incorrect. Ce défaut est particulièrement désagréable, puisqu'il se manifeste par un bref affichage désorganisé avant la correction.

Retirer les modules inutilisés

Le thème permet de désactiver des familles de modules jamais employées sur le projet, ce qui allège le chargement et l'interface de construction. Ce nettoyage demande de savoir ce qui est réellement utilisé, information qui s'obtient en cherchant les noms de modules dans la base. Il apporte un gain modeste et il simplifie considérablement le travail des rédacteurs. C'est une intervention à mener une fois le site stabilisé. Elle doit être revue lors de chaque évolution importante, un nouveau besoin pouvant réclamer un module désactivé.

Traiter les images sérieusement

Redimensionner à la taille réellement affichée, convertir vers un format moderne et servir des variantes selon la largeur d'écran produit le gain le plus important sur ce type de site. Une image de bandeau servie en trois mille pixels de large sur un écran mobile gaspille l'essentiel de son poids. Ce travail est indépendant du thème et il devrait précéder toute optimisation de code. Il est aussi le seul dont le bénéfice ne comporte aucune contrepartie. Une extension de conversion et de redimensionnement automatise l'essentiel du travail sur les images déjà présentes.

Alléger les polices

Le thème permet de choisir les polices et charge par défaut plusieurs graisses dont une partie n'est jamais employée. Limiter le chargement aux deux ou trois graisses réellement utilisées divise le poids concerné. Héberger ces polices localement plutôt que de les charger depuis un service distant supprime en outre une connexion externe. Cette double intervention se mène en une heure et elle produit un gain immédiat. Elle règle au passage la question de la transmission de données à un service tiers dès le chargement de la page.

Coordonner avec le cache

Les optimisations du thème et celles de l'extension de cache se recouvrent partiellement et se contredisent parfois. Activer la minification des deux côtés, par exemple, ne produit aucun gain supplémentaire et multiplie les sources de problème. La règle consiste à choisir où chaque optimisation est faite et à désactiver l'autre, sujet développé dans notre article sur Divi et les réglages WP Rocket compatibles avec le Visual Builder.

Contrôler et maintenir

Un site allégé se dégrade en quelques mois si rien ne surveille les ajouts successifs, chaque nouveau module ou script reprenant une partie du gain.

Activer une option à la fois

Chaque réglage doit être activé seul, suivi d'un contrôle complet du site, avant de passer au suivant. Tout activer d'un coup rend impossible d'identifier la cause d'un problème et conduit généralement à tout désactiver. Cette progression prend une demi journée et elle produit une configuration stable. La tentation de tout activer en cinq minutes est forte et elle se paie systématiquement en temps de diagnostic. Elle permet aussi de mesurer le gain apporté par chaque option, information réutilisable sur les projets suivants. Les mêmes réglages produisent en effet des résultats très proches d'un site à l'autre, ce qui rend cette connaissance directement transposable.

Vérifier les interactions

Les défauts introduits par les optimisations de script ne se voient pas au premier regard : il faut cliquer sur les onglets, ouvrir les accordéons, faire défiler les diaporamas et soumettre les formulaires. Ces éléments sont précisément ceux que le chargement dynamique peut casser. Un parcours de cinq minutes par gabarit couvre l'essentiel. Ce contrôle est le seul qui détecte cette famille de problèmes. Le faire réaliser par une personne extérieure au projet révèle en outre les éléments devenus ambigus à l'usage.

Tester en navigation privée

Un administrateur connecté ne reçoit pas les mêmes ressources qu'un visiteur ordinaire, notamment parce que le constructeur charge ses propres fichiers. Toute vérification doit donc se faire dans une fenêtre privée. Cette confusion est à l'origine de la moitié des diagnostics erronés sur ce sujet. Le réflexe s'acquiert vite et il fait gagner beaucoup de temps. Il évite aussi de conclure trop vite qu'une option n'a produit aucun effet.

Mesurer le résultat

La comparaison du poids total, du nombre de requêtes et des indicateurs d'expérience avant et après donne le gain obtenu. Ce chiffre est utile pour justifier le temps passé et il permet d'arbitrer sur les options les plus risquées. Il doit être relevé sur les mêmes pages qu'avant intervention, faute de quoi la comparaison n'a aucun sens. Une amélioration marginale ne justifie pas de conserver un réglage qui casse un module. C'est la mesure qui permet de trancher sans discussion. Elle remplace utilement les débats d'appréciation sur ce qui paraît plus rapide ou non.

Surveiller après chaque ajout

L'installation d'une extension, l'ajout d'un script de mesure ou la création d'une nouvelle page reprennent une partie du gain. Un relevé trimestriel du poids des pages principales détecte cette dérive avant qu'elle ne devienne un chantier. Ce contrôle prend cinq minutes. Son absence explique pourquoi un site optimisé se retrouve dans le même état deux ans plus tard. Inscrire ce relevé au calendrier, au même titre que les mises à jour, suffit à maintenir le résultat obtenu.

Documenter les réglages retenus

Une note listant les options activées, celles écartées et pourquoi, évite qu'un intervenant ultérieur ne réactive un réglage qui casse un module. Elle permet aussi de reprendre le travail après une mise à jour majeure du thème, moment où les options évoluent. Les principes généraux de compression employés sont par ailleurs rappelés dans notre article sur la minification et la technique pour minifier un site. Cette documentation tient sur une page et elle fait partie de la livraison. Elle doit préciser la version du thème au moment des réglages, plusieurs options ayant changé de nom ou de comportement au fil des versions. Elle doit aussi préciser les réglages volontairement laissés par défaut, information qui évite au suivant de les modifier sans raison.