Elementor et Divi : pourquoi on ne les recommande pas (mais on sait les utiliser)

Chez WebEngine, on connaît Elementor et Divi. On les a utilisés. On sait comment les configurer, les optimiser, les contourner. Et c’est précisément pour ça qu’on ne les recommande pas à nos clients.

Ce n’est pas un positionnement marketing. C’est une conclusion technique, tirée de centaines de projets.

D’abord : c’est quoi un page builder ?

Un page builder est un plugin WordPress qui remplace l’éditeur natif par une interface glisser-déposer visuelle. Vous construisez vos pages en assemblant des “widgets” ou “blocs” — texte, image, bouton, colonne — sans écrire une ligne de code.

Elementor, Divi, WPBakery, Beaver Builder, Brizy — ils fonctionnent tous sur le même principe : générer du HTML, du CSS et du JavaScript à partir de réglages configurés dans leur interface. En théorie, c’est pratique. En pratique, ça crée des problèmes structurels difficiles à résoudre.

Le vrai problème : ce que le page builder génère derrière

Ouvrez le code source d’une page Elementor. Ce que vous voyez ressemble à ça :

<div class="elementor-section elementor-top-section">
  <div class="elementor-container elementor-column-gap-default">
    <div class="elementor-row">
      <div class="elementor-column elementor-col-100">
        <div class="elementor-column-wrap">
          <div class="elementor-widget-container">
            <h2 class="elementor-heading-title">Mon titre</h2>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Six niveaux de divs pour afficher un titre H2. En code natif, c’est juste :

<h2>Mon titre</h2>

Ce n’est pas anecdotique. Ces divs superflus se multiplient sur toute la page. Résultat : un DOM de 300 à 600 éléments pour des pages qui n’en nécessitent pas plus de 80. Google crawle ce DOM. Les navigateurs le rendent. Les Core Web Vitals en pâtissent.

Impact sur PageSpeed : les chiffres réels

Voici ce qu’on observe systématiquement sur des sites Elementor non modifiés :

• Score PageSpeed mobile : 40 à 65 (contre 88 à 96 en code natif)
• LCP (Largest Contentful Paint) : 3,5 à 6 secondes (contre 1,2 à 2,0 s)
• Nombre de requêtes HTTP : 80 à 140 (contre 20 à 40)
• Poids total de la page : 2 à 5 Mo (contre 400 à 900 Ko)

Elementor charge ses fichiers CSS et JavaScript sur chaque page, même quand les widgets correspondants ne sont pas utilisés. La version Pro ajoute encore plus de ressources. Les plugins tiers compatibles Elementor en rajoutent. En fin de compte, même avec WP Rocket et toutes les optimisations possibles, atteindre 85+ en mobile sur Elementor tient du tour de force.

Nous avons repris des sites Elementor pour les recoder en natif. Résultats typiques : de 48 à 91, de 55 à 94, de 62 à 90. Ce gain n’est pas dû à des optimisations marginales — c’est le poids structurel du page builder qui disparaît.

Le SEO : un impact sous-estimé

Google lit votre HTML. Un titre H1 enfoui dans six niveaux de divs “elementor-“, entouré d’attributs data et de classes utilitaires, est moins clairement identifié qu’un H1 nu dans un code propre.

Plus concrètement : les Core Web Vitals sont des facteurs de classement depuis 2021. Un LCP à 4,5 s sur mobile pénalise votre positionnement par rapport à un concurrent avec un LCP à 1,5 s sur le même mot-clé. Les page builders dégradent structurellement ces métriques.

De plus, Elementor génère parfois du contenu dupliqué dans sa base de données (les révisions de la structure “elementor_data”), des balises méta mal gérées sans plugins supplémentaires, et des URLs de ressources qui varient entre les versions — autant de signaux négatifs pour les robots d’indexation.

La dette technique : le problème à 2 ans

Le vrai coût d’un page builder ne se voit pas dans les 6 premiers mois. Il apparaît quand :

• Elementor sort une mise à jour majeure qui casse vos animations, vos dispositions ou vos widgets personnalisés. C’est arrivé lors du passage à Elementor 3.0, puis lors de l’introduction d’Elementor AI. Des milliers de sites ont nécessité des corrections manuelles.
• Vous voulez faire évoluer le design : modifier globalement la typographie ou les espacements demande de toucher chaque widget de chaque page individuellement, car il n’y a pas de système de design cohérent.
• Un développeur doit reprendre le site : personne ne veut reprendre un site Elementor. Le code généré n’est pas maintenable, pas versifiable proprement dans Git, et dépend d’une version spécifique du plugin.
• Elementor devient payant ou disparaît : ce n’est pas hypothétique — Elementor a modifié son modèle tarifaire plusieurs fois. Un site dont le design est entièrement dépendant d’un plugin propriétaire est un risque métier réel.

“Mais Elementor peut être optimisé, non ?”

C’est la question qu’on nous pose le plus souvent. La réponse honnête : oui, partiellement.

Avec WP Rocket, Cloudflare, la désactivation du CSS inutilisé et le chargement différé des ressources Elementor, on peut passer de 45 à 70. Parfois 75. Rarement 80+ de façon stable sur mobile.

Mais 75 reste inférieur à ce qu’on obtient en code natif sans aucune optimisation. Et ces optimisations demandent du temps, des plugins supplémentaires, et créent de la fragilité : chaque mise à jour d’Elementor peut casser les règles de cache configurées.

On ne cherche pas à optimiser un site Elementor. On cherche à livrer un site qui performe nativement.

Divi : les mêmes problèmes, une philosophie encore plus fermée

Divi (Elegant Themes) partage les défauts d’Elementor, avec une couche de lock-in supplémentaire : le thème et le builder sont indissociables. Vous ne pouvez pas utiliser Divi sans le thème Divi. Vous ne pouvez pas migrer le contenu Divi vers un autre thème sans perdre toute la mise en forme.

Divi utilise un système de shortcodes qui enregistre la structure des pages dans la base de données. Si vous désactivez Divi un jour, vos pages se transforment en pages blanches parsemées de shortcodes bruts. C’est la définition du vendor lock-in.

Son score PageSpeed est généralement 5 à 10 points en dessous d’Elementor sur des configurations comparables — soit 35 à 60 sur mobile pour un site standard.

Alors, quand un page builder est-il acceptable ?

En toute honnêteté, il existe des cas où Elementor est un choix défendable :

• Un site institutionnel à faible trafic (moins de 2 000 visites/mois) géré en interne par une équipe non-technique — la praticité de l’interface prime sur la performance
• Un MVP rapide à tester avant d’investir dans un développement sur mesure
• Un site dont le SEO n’est pas un enjeu — rare, mais ça existe

Pour tout projet où la performance, le SEO ou la pérennité comptent, le code natif est la seule réponse sérieuse.

Si vous voulez Elementor ou Divi : on sait faire

Soyons clairs : si vous arrivez avec un projet et que vous tenez à utiliser Elementor ou Divi, on ne refusera pas. On maîtrise ces outils — on sait les configurer, les optimiser et contourner leurs limitations.

• On choisit la configuration la plus légère possible
• On couple avec WP Rocket ou Perfmatters
• On configure Cloudflare CDN en frontal
• On optimise toutes les images en WebP
• On établit des règles CSS globales dans le kit global Elementor

Avec ces optimisations, on peut viser 75 à 82 en score PageSpeed mobile sur un site Elementor bien configuré.

Notre recommandation reste le code natif — mais le choix final vous appartient.

Ce qu’on fait à la place

Chez WebEngine, chaque thème est développé from scratch en PHP, HTML, CSS et JavaScript natifs. Le résultat :

• Un CSS de 40 à 80 Ko (contre 600 Ko à 2 Mo avec Elementor)
• Un DOM de 80 à 120 éléments (contre 300 à 600)
• Un score PageSpeed mobile de 88 à 96 sans plugin d’optimisation
• Un code versionnable dans Git, maintenable par n’importe quel développeur PHP
• Zéro dépendance à un plugin tiers pour le design

On connaît les page builders. On sait les utiliser. On a fait le choix de ne pas les utiliser pour nos clients — parce qu’on pense à leur site dans 3 ans, pas dans 3 semaines.

Si votre site actuel est construit avec Elementor et que vous constatez des performances dégradées ou des difficultés de maintenance, contactez-nous pour un audit gratuit.

Conclusion

Elementor et Divi sont des outils populaires, et on comprend leur attrait : rapidité de prise en main, interface visuelle, bibliothèques de templates. Mais pour un site performant, léger et bien référencé, le code natif reste notre recommandation.

On connaît les page builders. On sait les utiliser. Si vous les voulez, on les fait — avec les meilleures optimisations possibles. Si vous nous faites confiance sur le choix technique, on vous livrera un site en code natif qui surclasse la concurrence sur Core Web Vitals et SEO.

Le choix vous appartient. Parlons de votre projet.