Optimiser WPBakery : alléger Visual Composer sans tout casser

Le problème WPBakery : beau à l’œil, lourd sous le capot

Un site construit avec WPBakery Page Builder (anciennement Visual Composer) peut être visuellement impeccable et pourtant afficher un score PageSpeed de 38/100. Ce n’est pas une coïncidence — c’est une caractéristique structurelle du builder.

WPBakery génère un HTML particulièrement verbeux : des dizaines de div imbriquées pour chaque rangée, colonne et élément, du CSS inline directement dans le markup, et des shortcodes qui se transforment en code PHP à chaque chargement de page. Le navigateur doit parser tout ça avant d’afficher quoi que ce soit.

La bonne nouvelle : on peut reprendre plusieurs dizaines de points de performance sans toucher à la mise en page, sans recodage, et sans migrer vers un autre builder. Voici comment.

Ce qui pèse le plus dans un site WPBakery

Avant d’agir, identifier les vraies causes :

• DOM profond et surchargé : WPBakery enveloppe chaque bloc dans 3 à 5 div supplémentaires. Sur une page moyenne, cela peut représenter 400 à 800 nœuds DOM inutiles.
• CSS inline massif : chaque couleur, marge, police définie dans le builder est injectée en style="" directement dans le HTML — impossible à mettre en cache.
• Chargement global des assets : WPBakery charge ses scripts et feuilles de style sur TOUTES les pages, même celles qui n’utilisent aucun de ses éléments (la page de connexion, par exemple).
• Images non optimisées : les utilisateurs du builder uploadent souvent des images directement depuis l’interface, sans passer par une étape de compression.
• Plugins redondants : un site WPBakery accumule fréquemment des extensions d’animation, de slider ou de formulaire dont seule une fraction est réellement utilisée.
• Hébergement sous-dimensionné : un memory_limit trop bas fait ramer PHP avant même que le builder ne charge. On y revient.

Solution 1 — Désactiver WPBakery sur les pages qui n’en ont pas besoin

WPBakery charge son CSS et son JS sur l’ensemble du site par défaut. La première action, simple et sans risque, consiste à le désactiver là où il ne sert à rien.

Dans WPBakery > Settings > General, cochez l’option “Disable on front-end” si vous n’utilisez pas le frontend editor. Pour aller plus loin, ajoutez ce snippet dans le fichier functions.php de votre thème enfant :

add_action('wp_enqueue_scripts', function() {
    if (!is_page(array(42, 67, 89))) { // IDs des pages WPBakery uniquement
        wp_dequeue_style('js_composer_front');
        wp_dequeue_script('wpb_composer_front_js');
    }
}, 100);

Remplacez les IDs par ceux de vos pages construites avec WPBakery. Sur les autres pages, zéro chargement inutile.

Solution 2 — Nettoyer le CSS inline avec un plugin de cache adapté

Le CSS inline de WPBakery ne peut pas être mis en cache séparément, mais un plugin de cache bien configuré peut le compenser en mettant en cache la page HTML entière, inline compris.

WP Rocket reste la référence : activez la minification HTML, CSS et JS, ainsi que la combinaison de fichiers CSS. LiteSpeed Cache ou W3 Total Cache font le même travail sur les hébergements compatibles.

Point d’attention : WPBakery et certains plugins de cache se disputent parfois le JS. Si après activation du cache votre mise en page s’affiche de travers, désactivez temporairement le “defer” sur les scripts et réactivez-le sélectivement.

La performance web et les Core Web Vitals sont directement liés à cette étape — un cache bien réglé peut faire passer un LCP de 4 s à 1,8 s sans toucher une seule ligne de code builder.

Solution 3 — Optimiser les images (l’impact le plus rapide)

Les images représentent en général 60 à 80 % du poids d’une page WPBakery. Action immédiate :

1. Installez ShortPixel ou Imagify et lancez une compression en masse de la bibliothèque existante.
2. Activez la conversion automatique en WebP — support navigateur à 95 %+ en 2026.
3. Activez le lazy loading natif (loading="lazy") : WP 5.5+ l’ajoute automatiquement, vérifiez que votre thème ne l’écrase pas.
4. Dans les réglages WPBakery de chaque section, évitez les images de fond en haute résolution sur les rangées : elles se chargent en CSS background, hors de portée du lazy loading natif.

Solution 4 — Auditer et désactiver les plugins inutilisés

Un site WPBakery typique embarque facilement 25 à 40 plugins. Pour chaque plugin actif, posez-vous la question : est-il utilisé sur au moins une page en production ?

• Désactivez les sliders (Revolution Slider, Layer Slider) si vous n’avez plus de slider actif sur aucune page.
• Supprimez les add-ons WPBakery tiers qui ajoutent des éléments que vous n’utilisez pas.
• Remplacez les plugins de formulaire lourds par des alternatives plus légères si les fonctionnalités avancées ne sont pas exploitées.

Chaque plugin actif ajoute au moins une requête HTTP et souvent plusieurs. Sur les sites sous WordPress ou Astro, la différence de base est structurelle — mais sur WordPress, la gestion des plugins reste le principal levier.

Solution 5 — Régler les ressources serveur PHP

Si votre site rame même sans trafic élevé, le problème peut être côté serveur. WPBakery est gourmand en PHP : il parse les shortcodes, génère le HTML et charge les assets en une seule requête.

Voici les directives PHP à vérifier :

Pour le memory_limit, l’ajout dans wp-config.php est souvent le plus simple :

define('WP_MEMORY_LIMIT', '256M');

Si votre hébergeur mutualisé ne permet pas de dépasser 128 M, c’est peut-être le signal qu’un hébergement sous-dimensionné est le vrai problème — pas uniquement WPBakery. Une maintenance sérieuse inclut ce type de surveillance proactive.

Solution 6 — Activer un CDN et le préchargement

Un CDN (réseau de distribution de contenu) sert les assets statiques depuis un nœud géographiquement proche du visiteur. Cloudflare en version gratuite suffit pour la majorité des PME françaises.

Activez le préchargement du cache dans votre plugin de cache : les pages sont générées en avance, pas à la demande du premier visiteur. Sur un site WPBakery, cela efface la latence de génération des shortcodes pour tous les visiteurs suivants.

Récapitulatif cause → solution

Quand passer la main à un pro ?

Les solutions 1 à 4 sont accessibles sans développeur. Les solutions 5 et 6 demandent un accès SSH ou panel d’hébergement, et une erreur sur php.ini peut rendre le site inaccessible. Si votre hébergeur ne propose pas d’interface claire pour modifier ces directives, ou si après toutes ces étapes le site reste en dessous de 60/100, le problème est probablement structurel : soit l’hébergement est trop juste, soit le thème lui-même génère du code redondant par-dessus WPBakery. Un audit par une agence permet de distinguer ce qui se règle en configuration de ce qui nécessite une intervention sur le code.