300 000 pages générées à partir du même jeu de données, rendues une fois avec l’éditeur V4 d’Elementor, une fois avec l’éditeur de site natif de WordPress : voilà le protocole retenu pour trancher, avec des chiffres plutôt que des impressions, une question posée en amont d’un projet à très fort volume. Ce comparatif ne traite ni le coût de licence des deux approches ni la courbe d’apprentissage des équipes, deux critères tout aussi importants mais mesurés séparément.
Le protocole de mesure retenu
Le jeu de données utilisé provient d’un export de fiches produit d’un catalogue existant, converti en un format neutre puis injecté dans deux gabarits strictement équivalents en apparence : un gabarit construit avec un composant V4 d’Elementor, un gabarit construit avec un modèle de l’éditeur de site natif, tous deux affichant les mêmes champs (titre, image, description, prix, caractéristiques techniques).
Les mesures ont été prises côté serveur, avec l’outil Server-Timing exposé dans les en-têtes de réponse HTTP, sur un environnement d’hébergement identique pour les deux architectures, avec le même niveau de cache de page désactivé pendant la phase de mesure du temps de rendu brut.
Résultats mesurés par palier de volume
| Volume de pages | Temps de rendu moyen Elementor V4 | Temps de rendu moyen éditeur de site | Écart |
|---|---|---|---|
| 1 000 pages | 85 ms | 70 ms | 15 ms |
| 50 000 pages | 140 ms | 95 ms | 45 ms |
| 150 000 pages | 310 ms | 140 ms | 170 ms |
| 300 000 pages | 510 ms | 170 ms | 340 ms |
L’écart entre les deux architectures reste modeste jusqu’à 50 000 pages, puis se creuse nettement au-delà. Cette dégradation plus marquée du côté d’Elementor V4 s’explique par le coût de résolution des classes globales et des variables partagées, qui doivent être recalculées à chaque rendu de page dans la configuration testée, alors que l’éditeur de site natif s’appuie sur un système de templates PHP compilés plus directement par le moteur de rendu de blocs.
Le rôle du cache de rendu
En réactivant un cache de page complet (testé ensuite avec un cache objet persistant et un cache HTML en périphérie), l’écart se réduit fortement pour les visiteurs qui reçoivent une page déjà mise en cache, ramenant la différence perçue à quelques dizaines de millisecondes dans la majorité des cas. Ce résultat nuance fortement l’écart brut mesuré plus haut : en usage réel, avec un cache correctement configuré, l’essentiel du trafic ne subit pas directement ce delta de rendu serveur.
L’écart redevient significatif uniquement dans deux situations : la première visite d’une page non encore mise en cache, et toute opération de purge et régénération massive du cache après une modification de structure affectant l’ensemble du catalogue.
Un test complémentaire sur la génération statique
Un troisième scénario a été testé en complément des deux premiers : la pré-génération complète des 300 000 pages en fichiers statiques, via une commande d’export dédiée, plutôt qu’un rendu dynamique servi ensuite par un cache. Dans ce scénario, l’écart entre les deux architectures disparaît presque totalement une fois les fichiers statiques servis directement par le serveur web, puisque le coût de résolution des classes globales et des templates de blocs n’intervient alors qu’une seule fois, au moment de la génération, et non à chaque visite.
Ce résultat déplace la question posée initialement : au-delà de 200 000 pages, le choix décisif ne porte peut-être pas tant sur l’architecture de rendu retenue que sur la capacité du site à fonctionner en génération statique plutôt qu’en rendu dynamique à chaque requête, une option que toutes les configurations ne permettent pas selon le niveau d’interactivité attendu par page.
Ce que ce résultat ne dit pas
- Il ne mesure pas le temps de développement initial des deux approches, qui diffère sensiblement
- Il ne prend pas en compte la facilité de délégation du contenu à une équipe éditoriale non technique
- Il ne tient pas compte d’éventuelles optimisations spécifiques à Elementor V4 encore en développement au moment du test
Notre lecture de ce comparatif : au-delà de 200 000 pages générées dynamiquement sans cache complet, l’éditeur de site natif conserve un avantage de rendu serveur mesurable, mais cet avantage s’efface largement dès qu’une stratégie de cache sérieuse est en place.
Notre verdict
Sur un jeu de 300 000 pages rendues sans cache, l’éditeur de site natif de WordPress affiche un temps de rendu serveur nettement inférieur à celui de l’éditeur V4 d’Elementor, avec un écart qui se creuse à mesure que le volume augmente. Ce résultat ne doit pas être lu comme un verdict définitif en défaveur d’Elementor : la mise en place d’une stratégie de cache adaptée réduit fortement cet écart pour l’immense majorité des visites réelles, un facteur à intégrer dans toute décision d’architecture à ce niveau de volume.
