Elementor V4, avec son architecture de conteneurs atomiques désormais stabilisée, contre une architecture de blocs Gutenberg natifs classique : lequel des deux tient la charge sur un site à très fort volume de pages ? Ce comparatif répond à cette question précise sur un jeu de test de 300 000 pages générées automatiquement, représentatif d’un site d’annonces immobilières avec une fiche par bien.
Il ne couvre pas le coût de licence des deux solutions, ni la courbe d’apprentissage des équipes qui devraient les adopter, uniquement les mesures de temps de rendu constatées sur ce jeu de pages identique dans les deux architectures.
Le protocole du comparatif
Un même modèle de fiche (titre, galerie d’images, tableau de caractéristiques, formulaire de contact) a été reconstruit à l’identique dans les deux architectures : une fois avec des conteneurs Elementor V4 et ses widgets natifs, une fois avec des blocs Gutenberg natifs (core/group, core/gallery, core/table) assemblés en modèle de bloc réutilisable via wp_insert_template(). Les 300 000 fiches ont été générées avec les mêmes données sources dans les deux cas, cache d’objet et cache de page désactivés pour isoler le coût de rendu pur.
Le tableau de mesures
| Volume de pages | Temps de rendu moyen Elementor V4 | Temps de rendu moyen Gutenberg natif |
|---|---|---|
| 1 000 pages | 85 ms | 60 ms |
| 50 000 pages | 110 ms | 65 ms |
| 300 000 pages | 190 ms | 75 ms |
D’où vient l’écart qui se creuse avec le volume
L’écart, faible sur un petit volume, se creuse nettement au-delà de 50 000 pages. La cause principale tient à la résolution des styles globaux : Elementor V4 recalcule, pour chaque conteneur atomique de chaque page, sa correspondance avec le kit de style global et les classes réutilisables du site, une opération dont le coût croît avec le nombre de règles de style enregistrées dans le kit au fil du temps. L’architecture Gutenberg native, appuyée directement sur theme.json compilé en CSS statique au build, ne recalcule rien de comparable à l’affichage.
Ce que le cache de page change concrètement
Une fois le cache de page complet activé (Varnish en frontal), l’écart mesuré à froid s’efface presque totalement pour les visiteurs suivants : les deux architectures servent alors une page statique déjà générée, sans recalcul de style à chaque requête. L’écart de rendu ne reste donc déterminant que pour les pages non encore mises en cache, ou pour les visiteurs connectés qui contournent systématiquement le cache de page (via un cookie de session), un cas fréquent sur un site avec favoris et compte utilisateur.
- Sans cache de page, l’écart de rendu profite nettement à l’architecture Gutenberg native au-delà de 50 000 pages.
- Avec cache de page complet, l’écart devient marginal pour les visiteurs anonymes servis depuis le cache.
- Les visiteurs connectés, hors cache de page, restent exposés à l’écart mesuré dans le tableau ci-dessus.
Ce qui ne dépend pas du volume
Certains critères de choix restent indépendants du volume de pages testé ici : la flexibilité visuelle offerte à un éditeur non technique reste supérieure côté Elementor V4 pour ce type de fiche répétitive, tandis que la portabilité du contenu (export, réutilisation dans un autre thème) reste plus simple côté blocs Gutenberg natifs, stockés en HTML commenté standard plutôt que dans un format propriétaire.
Un comparatif de performance ne tranche jamais seul un choix d’architecture : il fixe simplement le prix technique de chaque option, à mettre en regard des autres critères du projet.
Notre verdict
Sur un site à très fort volume de pages générées automatiquement, l’architecture Gutenberg native conserve un avantage de rendu net et croissant avec le volume, avantage largement atténué mais pas totalement effacé dès qu’un cache de page complet est en place. Le choix final dépend surtout du profil des visiteurs (anonymes servis par cache, ou connectés qui le contournent) et du besoin réel de flexibilité visuelle donné aux équipes éditoriales, pas uniquement de ce comparatif de temps de rendu.
