Divi et le cache : réglages WP Rocket compatibles avec le Visual Builder

Un site construit avec Divi charge naturellement plus de ressources qu'un thème léger : une bibliothèque de modules, une feuille de style volumineuse et un ensemble de scripts destinés aux animations et aux effets. Une extension de cache produit donc un gain très visible sur ce type de site. Elle produit aussi, si elle est configurée sans précaution, un éditeur visuel qui ne se charge plus, des modules qui perdent leur mise en forme et des modifications qui n'apparaissent jamais. Ces symptômes ont des causes précises et des remèdes connus, à condition de mettre les réglages en place dans le bon ordre et de savoir quoi exclure.

Pourquoi les deux se gênent

Comprendre le mécanisme évite de tâtonner réglage par réglage, ce qui est la façon la plus longue d'arriver à un résultat instable. Trois interactions distinctes produisent l'essentiel des problèmes constatés. Le fonctionnement général du constructeur est présenté dans notre article sur le Theme Builder de Divi et son guide complet.

L'éditeur charge sa propre interface

L'éditeur visuel n'est pas une page ordinaire : il charge une application complète dans le navigateur, avec ses propres scripts et ses propres appels au serveur. Une extension de cache qui traite cette page comme une page publique sert une version figée, dans laquelle l'application ne peut pas s'initialiser. Le symptôme est reconnaissable : un écran de chargement qui ne se termine jamais. L'exclusion des adresses d'édition est donc la toute première mesure à poser. Elle est heureusement simple et elle règle à elle seule le symptôme le plus spectaculaire.

Les styles sont générés dynamiquement

Divi produit un fichier de styles propre à chaque page, calculé à partir des réglages des modules et stocké dans un répertoire dédié. Ce fichier est régénéré lorsque la page est modifiée, ce qui suppose que le cache soit vidé au bon moment. Une extension conservant l'ancienne version sert une page dont le contenu est à jour et la mise en forme périmée. C'est la cause la plus fréquente des modifications qui n'apparaissent pas. Elle se reconnaît à un détail : le texte modifié apparaît bien, seule la mise en forme reste celle d'avant.

Les scripts sont fortement interdépendants

Les modules du constructeur reposent sur des scripts qui s'appellent entre eux dans un ordre défini. Les combiner en un fichier unique, ou en différer l'exécution sans précaution, casse cet ordre et produit des animations qui ne se déclenchent pas, des onglets qui ne fonctionnent plus ou des formulaires inertes. Ces défauts sont visuellement subtils et ils passent souvent inaperçus lors des tests rapides. Ils sont pourtant les plus coûteux, parce qu'ils dégradent des fonctions que le visiteur essaie d'utiliser. Un formulaire de contact inerte se traduit directement par des demandes perdues, sans qu'aucune alerte ne le signale.

Le cache de page et le cache de navigateur

Deux niveaux de cache coexistent et se confondent facilement lors des diagnostics. Le premier, côté serveur, conserve la page produite. Le second, côté navigateur, conserve les fichiers de style et de script. Un vidage du premier ne touche pas le second, ce qui explique qu'une correction paraisse sans effet pour la personne qui teste alors qu'elle fonctionne pour tout le monde. La navigation privée tranche cette question en trois secondes. Un rechargement forcé, ignorant le cache du navigateur, complète utilement cette vérification.

Les appels au serveur pendant l'édition

L'éditeur communique en permanence avec le serveur pour enregistrer, prévisualiser et charger des éléments de bibliothèque. Ces appels passent par un point d'entrée du cœur qui ne doit jamais être mis en cache. Les extensions sérieuses l'excluent nativement et une configuration agressive peut le réintégrer. Ce point mérite une vérification explicite lorsque l'enregistrement échoue sans message clair. La console du navigateur montre alors des réponses inattendues sur ces appels, ce qui confirme immédiatement le diagnostic.

Les rôles et les cookies

Un utilisateur connecté ne doit pas recevoir de page mise en cache, sous peine de voir la barre d'administration disparaître et l'édition devenir impossible. La plupart des extensions désactivent le cache pour les utilisateurs connectés par défaut, réglage qu'il faut vérifier plutôt que supposer. Sur les sites où ce réglage a été modifié pour des raisons de performance, l'édition devient erratique. C'est un cas rare et particulièrement déroutant à diagnostiquer. Le symptôme varie selon les personnes, celles qui n'ont jamais été connectées ne rencontrant aucun problème.

Les réglages à poser

La configuration se construit par étapes, en commençant par les exclusions et en n'activant les optimisations qu'ensuite, une par une.

Exclure les adresses d'édition

Toutes les adresses correspondant à l'ouverture de l'éditeur doivent figurer dans les exclusions de cache. Ces adresses comportent un paramètre reconnaissable, ce qui permet une exclusion par motif plutôt qu'une liste. Cette exclusion est en général posée automatiquement par les extensions qui reconnaissent le thème, et il vaut mieux le vérifier que le supposer. C'est la mesure sans laquelle rien d'autre ne fonctionne. Une extension ne reconnaissant pas le thème laisse cette exclusion à la charge de l'administrateur, ce qui explique une part importante des incidents rencontrés.

Exclure les pages de prévisualisation

Les adresses de prévisualisation, employées pour voir un brouillon, doivent également être exclues. Sans cela, un rédacteur voit une version figée de son travail et conclut que ses modifications ne s'enregistrent pas. Ce symptôme génère beaucoup de signalements et il se corrige par une ligne d'exclusion. Il concerne tous les thèmes et il est particulièrement visible avec un constructeur. La prévisualisation étant l'outil de travail principal du rédacteur, son dysfonctionnement bloque entièrement la production de contenus.

Vider le cache à l'enregistrement

Le cache de la page modifiée doit être vidé lorsque la page est enregistrée depuis l'éditeur. La plupart des extensions le font nativement pour les enregistrements classiques et pas toujours pour ceux issus du constructeur, qui passent par un autre chemin. Une vérification consiste à modifier une couleur et à recharger la page publique en navigation privée. Si l'ancienne couleur persiste, le vidage automatique ne fonctionne pas et il faut soit ajouter une règle, soit vider manuellement après chaque modification. La seconde solution est acceptable sur un site peu modifié et intenable dès que plusieurs personnes contribuent.

Activer la minification progressivement

La compression des fichiers de style et de script produit un gain réel et elle constitue la principale source de casse. Elle doit être activée séparément pour les styles puis pour les scripts, avec un contrôle complet du site entre les deux. Activer les deux simultanément, puis constater un problème, oblige à recommencer pour identifier la cause. Cette discipline paraît lente et elle est en réalité la plus rapide, puisqu'elle évite les retours en arrière successifs. Les principes de cette opération sont détaillés dans notre article sur la minification et la technique pour minifier un site.

Se méfier de la combinaison de fichiers

Regrouper plusieurs fichiers en un seul était une optimisation majeure il y a dix ans et elle a perdu l'essentiel de son intérêt avec les protocoles réseau modernes. Elle reste en revanche la source la plus fréquente de casse sur un site construit avec un constructeur, en modifiant l'ordre de chargement. Sur un site Divi, la garder désactivée est la position raisonnable. Le gain constaté est faible et le risque élevé. Cet arbitrage est d'ailleurs valable au delà de Divi, la plupart des sites modernes n'ayant plus rien à gagner à cette option.

Différer les scripts avec précaution

Le report de l'exécution des scripts améliore nettement les mesures de performance et il casse fréquemment les modules interactifs. La solution consiste à activer l'option en excluant les scripts du thème et de ses modules, liste que les extensions récentes proposent en préréglage. Cette exclusion réduit le gain sans l'annuler, les scripts tiers restant différés. C'est l'arbitrage le plus rentable de toute la configuration. Les scripts de mesure d'audience et de réseaux sociaux, qui pèsent souvent le plus lourd, restent en effet concernés par le report.

Les optimisations qui rapportent le plus

Toutes les options d'une extension de cache n'ont pas le même effet sur un site construit avec un constructeur visuel. Quelques unes produisent l'essentiel du gain.

Le cache de page lui même

Servir une page déjà produite plutôt que de la recalculer supprime l'ensemble du travail du serveur, ce qui divise couramment par cinq ou dix le temps de réponse. Sur un site Divi, où la construction de la page mobilise de nombreux modules, ce gain est proportionnellement plus élevé que sur un thème simple. C'est de loin l'option la plus rentable et la moins risquée. Elle suffit à elle seule à transformer la perception de vitesse du site. Sur un hébergement mutualisé, la différence entre une page mise en cache et une page calculée se compte souvent en secondes entières.

Le chargement différé des images

Ne charger les images qu'au moment où elles approchent de la zone visible allège considérablement les pages construites avec de longues sections. Le gain est particulièrement net sur les pages d'accueil comportant plusieurs bandeaux. Le seul point de vigilance concerne les diaporamas, dont les images suivantes peuvent ne pas se charger correctement selon l'implantation. Un contrôle sur une page en comportant suffit à trancher. Une exclusion ciblée sur les images concernées règle le cas sans renoncer à l'option pour le reste du site.

La génération des styles statiques

Divi propose une option produisant un fichier de styles statique par page plutôt qu'un calcul à chaque affichage. Cette option, interne au thème et indépendante de l'extension de cache, apporte un gain immédiat. Elle demande de vider le répertoire concerné après une modification globale, opération accessible depuis les réglages du thème. 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 par ailleurs grossir considérablement sur un site comptant de nombreuses pages, ce qui justifie un nettoyage occasionnel.

Le nettoyage des ressources inutiles

Un site Divi charge par défaut des ressources destinées à des fonctions que le projet n'emploie pas, polices d'icônes complètes ou styles de modules jamais utilisés. Les options de désactivation proposées par le thème, dans ses réglages avancés, retirent une partie de ce poids. Ce nettoyage demande un contrôle visuel du site après chaque désactivation. Il apporte un gain modeste et sans risque lorsqu'il est mené prudemment. Il vaut mieux le mener en fin de configuration, une fois les réglages de cache stabilisés, pour ne pas mélanger les causes en cas de problème.

L'optimisation des images

Le poids des images dépasse fréquemment celui de tout le reste sur un site construit avec un constructeur, les bandeaux pleine largeur invitant à téléverser des fichiers volumineux. Une conversion vers un format moderne et un redimensionnement à la taille réellement affichée produisent souvent le gain le plus important de toute l'optimisation. Ce travail est indépendant de l'extension de cache et il mérite d'être mené en premier. C'est le point où le retour sur le temps investi est le plus élevé. Une image de bandeau pesant trois mégaoctets annule à elle seule tout le bénéfice d'une configuration de cache soignée.

Le préchargement du cache

Une option parcourt le site après chaque vidage pour reconstituer le cache, ce qui évite qu'un visiteur ne tombe sur une page non mise en cache. Sur un site de quelques dizaines de pages, cette opération prend quelques minutes et elle est sans inconvénient. Sur un site de plusieurs milliers de pages, elle consomme des ressources et mérite d'être limitée aux pages importantes. Ce réglage se déduit de la taille du site, l'ensemble s'inscrivant dans la logique décrite dans notre article sur WP Rocket et l'augmentation de la vitesse de chargement.

Vérifier et diagnostiquer

Une configuration posée sans contrôle systématique produit des défauts qui se découvrent des semaines plus tard, par un client mécontent.

Tester en navigation privée

Toute vérification doit être menée dans une fenêtre privée, déconnectée du site. Un administrateur connecté ne reçoit pas les pages mises en cache, ce qui signifie qu'il ne voit jamais ce que voit un visiteur. 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 un temps considérable. Il évite aussi de conclure trop vite qu'une optimisation ne produit aucun effet.

Parcourir les gabarits principaux

Le contrôle doit couvrir un exemplaire de chaque type de page : accueil, page construite avec le constructeur, article, page de contact, éventuelle boutique. Un défaut apparaît souvent sur un seul gabarit, celui qui emploie un module particulier. Une liste écrite de ces pages, rejouée après chaque modification de réglage, transforme le contrôle en formalité de dix minutes. Elle sert ensuite à chaque mise à jour du thème ou de l'extension de cache.

Vérifier les interactions

Les défauts de script ne se voient pas au premier coup d'œil : il faut cliquer sur les onglets, ouvrir les accordéons, faire défiler les diaporamas et soumettre les formulaires. Ces éléments constituent précisément ce que les optimisations de script cassent. Ce contrôle prend cinq minutes par page et il est le seul qui détecte cette famille de problèmes. Le faire réaliser par une personne qui ne connaît pas le site révèle en outre les éléments dont le comportement est devenu ambigu.

Consulter la console du navigateur

Les erreurs de script apparaissent dans la console des outils de développement, avec le nom du fichier concerné. Cette information désigne directement la ressource à exclure de l'optimisation. C'est le diagnostic le plus rapide et il demande simplement de savoir où regarder. Une erreur signalant qu'une fonction est indéfinie indique presque toujours un problème d'ordre de chargement.

Mesurer avant et après

Relever les indicateurs de performance avant toute modification donne un point de comparaison. Sans lui, l'appréciation du résultat repose sur une impression. La mesure doit être faite sur données réelles autant que possible, les tests en laboratoire donnant des résultats sensiblement différents de l'expérience des visiteurs. Ces deux sources se complètent plutôt qu'elles ne se contredisent. Les premières mesures sur données réelles demandent plusieurs semaines pour être significatives, ce qui impose de la patience avant de conclure.

Documenter les exclusions posées

Une note listant chaque exclusion et sa raison évite qu'un intervenant ultérieur ne la retire en croyant améliorer les performances. Ce cas est fréquent et il produit une régression difficile à relier à sa cause. Cette documentation tient en dix lignes et elle doit vivre à côté du site plutôt que dans la mémoire de celui qui a configuré. C'est la conclusion logique d'un travail dont l'essentiel consiste à savoir ce qu'il ne faut pas activer.