Trois outils de construction de page dominent aujourd’hui les projets WordPress orientés design visuel poussé : Elementor dans sa version V4 aux éléments atomiques, Bricks avec sa propre architecture de composants, et l’éditeur de blocs natif de WordPress enrichi de patterns et de thèmes blocs. Plutôt que de comparer leurs fonctionnalités sur le papier, nous avons construit la même maquette de page de destination dans les trois outils, avec les mêmes contraintes de contenu, pour mesurer des écarts concrets plutôt que des arguments commerciaux.
La maquette retenue est une page de destination classique pour un lancement de produit : une section héro, une grille de trois avantages, une section de témoignages, un tableau de tarifs et un formulaire de contact, soit un gabarit représentatif d’une grande partie des projets de ce type.
Temps de production
Le temps de construction a été chronométré du début à la fin, sans compter le temps de rédaction des textes qui restait identique dans les trois cas. Sur cette maquette précise, l’écart entre les trois outils est resté limité pour une équipe déjà formée à chacun d’eux :
| Outil | Temps de construction | Poids JS total chargé | Éléments DOM générés |
|---|---|---|---|
| Elementor V4 (atomique) | 2 h 10 | 112 Ko | 187 |
| Bricks | 2 h 25 | 98 Ko | 176 |
| Éditeur natif (blocs + patterns) | 2 h 40 | 16 Ko | 164 |
L’éditeur natif reste le plus long à produire pour cette maquette précise, principalement à cause du tableau de tarifs qui demande davantage de manipulation manuelle des blocs de colonnes qu’avec les widgets dédiés d’Elementor ou de Bricks, mais il conserve un avantage très net sur le poids JavaScript chargé, l’éditeur de blocs n’ayant pas besoin d’un moteur de rendu de page builder côté visiteur.
Performance mesurée : l’INP au centre de l’attention
Depuis que l’INP a remplacé le FID comme métrique de réactivité de Core Web Vitals, la comparaison ne peut plus se limiter au seul poids de page. Sur la page de destination testée, avec un accordéon de FAQ et un formulaire interactif communs aux trois versions, l’INP mesuré via le terrain (via l’extension Web Vitals dans Chrome, en conditions de test répétées) donne un avantage net à l’éditeur natif et à Bricks sur ce point précis :
| Outil | INP mesuré (interaction sur l’accordéon FAQ) |
|---|---|
| Elementor V4 (atomique) | 145 ms |
| Bricks | 110 ms |
| Éditeur natif (blocs + patterns) | 95 ms |
L’écart reste modeste dans l’absolu, les trois valeurs restant dans la zone considérée comme bonne par Core Web Vitals, mais il confirme une tendance déjà documentée : moins un outil ajoute de couche d’abstraction JavaScript entre l’interaction du visiteur et le rendu, plus l’INP tend à s’améliorer, toutes choses égales par ailleurs.
Effort de maintenance dans le temps
Ce critère est plus difficile à chiffrer sur un test ponctuel, mais l’expérience cumulée de l’agence sur des projets déjà en production oriente clairement l’appréciation. Elementor V4 et Bricks partagent désormais une architecture atomique assez proche dans leur philosophie (propriétés déclaratives, classes globales réutilisables), ce qui simplifie les évolutions futures d’un site construit avec l’un ou l’autre. L’éditeur natif, appuyé sur les patterns et le thème actif, demande une plus grande rigueur de la part de l’équipe pour éviter la dispersion de styles locaux d’un bloc à l’autre, faute d’un système de classes globales aussi structuré nativement que celui des deux page builders.
Ce qui départage vraiment le choix en 2026
- Équipe déjà formée à un outil précis et productive dessus : rester sur cet outil reste presque toujours le choix le plus rentable, l’écart de performance entre les trois restant modéré pour une majorité de projets.
- Site à fort enjeu de performance mobile (commerce, contenu à fort trafic) : privilégier l’éditeur natif ou Bricks, avec un avantage marginal mais réel sur l’INP.
- Besoin fort de widgets métiers prêts à l’emploi (réservation, immobilier, catalogues complexes) : l’écosystème d’extensions plus mature d’Elementor reste souvent déterminant, malgré le léger surcoût de performance.
Notre verdict
Aucun des trois outils ne domine sur tous les critères en 2026, et le débat oppositionnel qui existait encore quelques années plus tôt perd de son sens à mesure que les architectures se rapprochent. Le facteur qui pèse le plus lourd dans un choix de projet réel reste la compétence déjà installée dans l’équipe et l’écosystème d’extensions nécessaire au projet, bien avant les écarts de quelques dizaines de kilo-octets ou de millisecondes mesurés dans ce comparatif.
