« Passez à l’éditeur de site, c’est plus léger. » Ce conseil revient dans presque toutes les discussions sur la performance WordPress depuis l’arrivée de la Full Site Editing avec WordPress 5.9, en janvier 2022. Il part d’une intuition correcte : un thème à blocs génère en théorie moins de code que la plupart des constructeurs visuels historiques. Mais l’intuition ne remplace pas la mesure, et deux audits de performance menés sur des sites comparables en 2022 racontent une histoire plus nuancée.
Cet article ne défend pas Elementor par principe. Il compare deux projets réels, à contenu et à ambition équivalents, pour établir où se situe réellement l’écart de performance, et surtout d’où il vient.
Le protocole de comparaison
Les deux sites analysés sont des vitrines d’entreprises de services, dix pages environ, avec une page d’accueil comportant une bannière, trois blocs de mise en avant, une galerie de témoignages et un formulaire de contact. Le premier utilise Elementor avec le thème Hello Elementor. Le second utilise un thème à blocs basé sur Twenty Twenty-Two avec des motifs personnalisés. Les mesures ont été prises avec les outils de développement d’un navigateur Chromium, en simulant une connexion mobile 4G, sur la page d’accueil de chaque site.
Ce que les chiffres montrent
Le site FSE affichait 1,4 Mo de ressources chargées sur sa page d’accueil, contre 900 Ko pour l’Elementor équivalent. L’écart ne venait ni de l’éditeur, ni du moteur de rendu, mais de deux choix d’implémentation : le thème à blocs chargeait l’intégralité de sa feuille de styles globale sur chaque page, y compris les règles concernant des blocs absents de cette page précise, et les images de la galerie de témoignages n’étaient pas servies dans un format moderne comme WebP.
| Indicateur | Site FSE | Site Elementor |
|---|---|---|
| Poids total de la page | 1,4 Mo | 900 Ko |
| Nombre de requêtes | 62 | 48 |
| Temps de rendu du plus grand élément visible | 2,8 s | 2,1 s |
Où Elementor perd réellement du terrain
Cette comparaison ne signifie pas qu’Elementor gagne systématiquement. Sur un projet non optimisé, avec des addons tiers empilés et le chargement CSS global de tous les widgets sur toutes les pages plutôt que la génération de fichiers CSS par page, l’écart s’inverse largement. Le réglage Charger les styles Google Fonts localement et le mode d’optimisation des assets, quand ils restent désactivés, sont les deux causes les plus fréquentes de pages Elementor inutilement lourdes.
Ce qui compte réellement
La discipline d’implémentation pèse plus lourd que le choix de l’éditeur : compression des images, chargement différé des scripts non essentiels, minimisation du nombre de polices embarquées, nettoyage des styles inutilisés. Un site à blocs bien tenu battra sans difficulté un Elementor mal entretenu, et inversement. La question à se poser n’est donc pas « quel éditeur est le plus rapide » mais « quelle est la probabilité que ce projet, avec cette équipe, reste bien tenu dans le temps ».
- un thème à blocs limite structurellement les excès de style superflu, mais ne les empêche pas ;
- Elementor expose plus de réglages de performance à activer manuellement, ce qui laisse plus de place à l’oubli ;
- dans les deux cas, l’audit d’images et de polices reste la première source de gain.
Avant de recommander une migration vers un autre éditeur pour des raisons de performance, on commence toujours par un audit du site existant : neuf fois sur dix, le problème se règle sans changer d’outil.
Reproduire l’audit sur son propre projet
Cette méthode de comparaison se reproduit facilement sans outil payant. Il suffit d’ouvrir les outils de développement d’un navigateur, d’activer la simulation d’un réseau mobile 4G dans l’onglet Réseau, puis de recharger la page en cochant la case qui vide le cache local. Le nombre de requêtes, le poids total transféré et le temps avant le rendu du plus grand élément visible s’affichent alors directement, sans configuration supplémentaire.
Un audit répété une fois par trimestre, sur les mêmes pages de référence, permet aussi de suivre l’évolution du poids d’un site dans le temps : un ajout de widget, un plugin installé pour un besoin ponctuel, ou une image importée sans compression peuvent faire dériver ces chiffres progressivement, sans qu’aucun changement isolé ne semble en cause au premier regard.
En résumé
L’idée qu’Elementor serait mécaniquement plus lent qu’un thème à blocs ne résiste pas à une mesure rigoureuse sur des projets comparables. Le poids d’une page dépend avant tout des choix d’implémentation : images non compressées, styles chargés sans discernement, polices multipliées. Avant d’accuser l’éditeur, un audit de performance concret permet de savoir si le vrai problème se trouve ailleurs.
