Mantys CoreComment accélérer un site Divi et améliorer ses Core Web Vitals (étape par étape)
En une phrase : un site Divi peut être rapide si vous optimisez dans le bon ordre, d'abord les images, puis le CSS, puis le JavaScript, en commençant par les leviers qui ne peuvent rien casser avant de toucher à ceux qui le peuvent.
Divi a la réputation d'être lourd. Il embarque beaucoup de CSS et de JavaScript pour que le constructeur visuel puisse tout faire, et par défaut, ce poids se répercute sur vos Core Web Vitals. La bonne nouvelle : un site Divi peut être rapide, et vous n'avez pas besoin de le vider de sa substance pour y arriver.
L'astuce consiste à optimiser dans le bon ordre, et à commencer par les leviers qui ne peuvent rien casser. Cette méthode sans-risque-d'abord est l'ossature de ce guide. Nous irons des images, puis au CSS, puis au JavaScript, du plus sûr au plus délicat, et chaque étape s'appuie sur un guide dédié que vous pouvez approfondir.
Étape 1 : les images (le levier le plus sûr)
Les images représentent presque toujours le plus gros poids d'une page Divi, et Divi aggrave les choses d'une manière bien précise : il s'appuie beaucoup sur des images pleine largeur et sur beaucoup d'images d'arrière-plan CSS (arrière-plans de sections et de modules).
Les mesures sans risque sont les habituelles, et aucune d'elles ne peut rien casser : compressez vos images, servez-les en WebP ou AVIF, et servez-les aux bonnes dimensions plutôt qu'un fichier énorme réduit par le CSS. Passez en lazy-load les images sous la ligne de flottaison, mais jamais l'image principale en haut de page (le LCP), sous peine de la ralentir. Et définissez width et height (ou un aspect-ratio) pour que la mise en page arrête de sauter (CLS).
Voici le piège spécifique à Divi. Les images d'arrière-plan de section et de module n'ont aucun srcset. Le levier srcset/sizes ne peut tout simplement pas les atteindre, donc aucun outil ne peut les dimensionner correctement à votre place. Vous devez compresser et dimensionner ces images en amont, avant qu'elles ne soient définies comme arrière-plans. Ce cas des images sans srcset est traité dans notre guide sur srcset et sizes.
Et pour les images classiques, l'attribut sizes que Divi et WordPress génèrent est souvent faux dès qu'une image se trouve dans une colonne ou une grille, ce qui est le cas de la plupart des mises en page Divi, si bien que le navigateur télécharge trop. Pourquoi cela se produit, et comment le repérer dans DevTools en trente secondes, fait l'objet de ce même guide sur srcset.
Étape 2 : le CSS
Divi a son propre panneau de performance (Theme Options → Performance). Activez Dynamic CSS: au lieu de charger toute la feuille de style de Divi, il ne charge que le CSS des modules réellement utilisés sur la page. C'est un gain important et sans risque. Dynamic Module Framework et Dynamic Icons fonctionnent de la même façon, en ne chargeant que ce dont une page a besoin.
Divi propose aussi une option Critical CSS. Si vous utilisez déjà un outil externe de critical-CSS, ne faites pas tourner les deux. Désactivez le Critical CSS de Divi et laissez un seul moteur posséder cette tâche. Deux moteurs qui se disputent la même responsabilité, c'est ainsi qu'on obtient des pages incohérentes et difficiles à déboguer. Appelons cela la règle d'or : un seul moteur par responsabilité.
C'est là que se produit le bug classique de Divi. Le Critical CSS et la suppression du CSS inutilisé ne conservent que ce qui est visible en haut de la page au chargement. Votre menu mobile, l'overlay de recherche et le mega-menu sont masqués à ce moment-là, si bien que leurs styles sont retirés, et ils s'affichent ouverts ou sans mise en forme. La solution durable consiste à insérer ces règles interactives en dur dans un bloc non-optimisable après wp_head(), pour qu'elles voyagent avec le thème. La méthode complète, et les pièges autour des caches par URL et mobile/desktop, se trouve dans le guide Critical CSS.
Autre habitude Divi : après un gros changement, régénérez le CSS statique de Divi. Un cache Divi périmé peut servir une feuille de style tronquée, ce qui ressemble exactement à une optimisation cassée. Purgez et régénérez, puis vérifiez le rendu réel.
Étape 3 : le JavaScript (et le menu Divi)
Divi charge jQuery, et sur la plupart des sites, c'est le menu qui l'impose. Différer le JavaScript est un gain important, mais c'est aussi là que tout casse si c'est fait à la légère.
Le cas emblématique est le menu burger qui ne s'ouvre qu'au deuxième clic. Divi a même un réglage pour ça, Defer jQuery And jQuery Migrate, et l'activer naïvement déclenche exactement ce bug : le premier appui réveille le chargement du script au lieu d'ouvrir le menu.
La solution, tout en gardant le menu Divi, consiste à exclure toute la chaîne de dépendances du délai ensemble : jQuery, jQuery Migrate, et le script du menu. Ciblez-les par un fragment d'URL unique (pas le handle interne, qui peut être retiré), et gardez une garde d'état du document pour que le script exclu tolère de s'exécuter tôt. Faites cela, et le menu répond de nouveau au premier appui. Si vous ne pouvez pas gérer la chaîne, laissez Defer jQuery désactivé plutôt que de livrer un menu à deux clics. La marche à suivre détaillée se trouve dans le guide du menu burger.
Une fois le menu géré, différer ou retarder le reste (sliders, lightbox, etc.) ne pose pas de problème et vous apporte l'essentiel du gain JavaScript.
Étape 4 : l'ordre et la méthode
Assemblez le tout avec la méthode sans-risque-d'abord. D'abord, activez tous les gains sans risque : compression et dimensions des images, lazy-load hors écran (jamais le LCP), minification, compression serveur, mise en cache navigateur, font-display. Ils ne peuvent rien casser, donc vous n'avez pas besoin de les tester un par un.
Ensuite, mesurez vos Core Web Vitals pour voir ce qu'il reste. Ce n'est qu'ensuite que vous attaquez les leviers à tester, le critical CSS et le report du JavaScript, un par un, en vérifiant mobile ET desktop ainsi que vos parcours clés (menu, recherche, panier) après chaque changement. Le raisonnement complet se trouve dans le pilier des optimisations sans risque.
Avec Mantys Core
Mantys Core peut constituer toute votre couche de performance, cache compris, ou fonctionner aux côtés de votre installation existante. Sur un site Divi en particulier, il s'aligne avec chacune des étapes ci-dessus :
il gère le Critical et le used-CSS page par page, et respecte les blocs non-optimisables, si bien que les menus et overlays masqués au chargement conservent leurs styles ;
il mesure la largeur d'affichage réelle de chaque image, réécrit
sizes, et génère du WebP, y compris le bon dimensionnement que la sortie native de Divi manque ;il retarde le JavaScript avec des exceptions déclarées par fragment d'URL et une garde d'état du document, si bien que le menu Divi continue de répondre au premier appui ;
et il sépare mobile et desktop pour que vous n'ayez pas à deviner quel cache sert quoi.
La règle d'or, un seul moteur par responsabilité, appliquée pour vous : vous désactivez les options Divi correspondantes, et Mantys prend en charge ces tâches proprement, sans que deux moteurs ne se disputent.
En résumé
- Divi peut être rapide ; optimisez dans l'ordre, images puis CSS puis JavaScript, et commencez par ce qui ne peut pas casser.
- Images : compressez, WebP, bonnes dimensions, lazy-load hors écran (jamais le hero) ; les images d'arrière-plan Divi n'ont pas de srcset, donc dimensionnez-les en amont.
- CSS : activez Dynamic CSS ; gardez un seul moteur de critical-CSS, pas deux ; protégez les menus et overlays masqués au chargement ; régénérez le CSS statique de Divi après les gros changements.
- JavaScript : pour garder le menu Divi avec le report JS activé, excluez toute la chaîne jQuery par fragment d'URL avec une garde d'état, ou laissez Defer jQuery désactivé.
- Méthode : tous les gains sans risque d'abord, mesurez les Core Web Vitals, puis les leviers risqués un par un, en testant mobile et desktop.