310 millisecondes contre 490 : c’est l’écart de temps de rendu serveur mesuré entre une page Elementor V4 pure et la même page où un bloc Gutenberg natif (une grille d’articles récents, core/query) a été inséré au milieu du contenu. Le chiffre intrigue suffisamment pour creuser ce qui se passe réellement quand les deux systèmes cohabitent sur une même page, en beta Elementor V4 début 2025.
Ce retour d’expérience porte sur la cohabitation technique mesurée sur trois pages types d’un site vitrine, pas sur une migration complète d’un système vers l’autre, ni sur un tutoriel de développement de widgets V4 (l’architecture atomique d’Elementor V4 mérite un article à part entière).
Le protocole de mesure
Trois pages ont servi de base : une page d’accueil avec sections Elementor et un bloc core/query inséré via le convertisseur de contenu, une page de blog avec un widget Elementor de type formulaire de contact et deux blocs Gutenberg natifs (core/table et un bloc dynamique maison de FAQ), et une page produit hybride. Chaque page a été chargée cinquante fois via wp-cli eval avec chronométrage du temps de génération HTML côté serveur, cache d’objet désactivé pour isoler le coût réel du rendu.
Le surcoût de rendu, poste par poste
Le surcoût mesuré ne vient pas d’un seul endroit mais de trois sources cumulées : le chargement des deux moteurs de style (Elementor et le moteur de blocs), la résolution des styles globaux (theme.json côté Gutenberg, kit Elementor côté V4) qui s’exécute deux fois indépendamment, et un appel supplémentaire à render_block() pour chaque bloc natif inséré dans une mise en page Elementor, qui n’est pas optimisé pour ce contexte hybride.
| Page | Temps Elementor seul | Temps avec bloc natif | Écart |
|---|---|---|---|
| Accueil | 310 ms | 490 ms | +180 ms |
| Blog | 275 ms | 410 ms | +135 ms |
| Produit | 340 ms | 505 ms | +165 ms |
Le conflit qui revient le plus : les marges de conteneur
Le point de friction le plus visible n’est pas la performance mais le CSS. Elementor V4, avec son système de conteneurs flexbox atomiques, applique ses propres règles de marge et d’espacement (gap, padding) au niveau du conteneur parent. Un bloc Gutenberg inséré à l’intérieur hérite de ces règles, puis tente d’appliquer les siennes issues de theme.json (via blockGap), ce qui produit des doubles marges visibles sur les blocs core/group et core/columns imbriqués dans un conteneur Elementor.
- Doubler la marge basse sur les blocs
core/groupinsérés dans un conteneur Elementor V4. - Perte du
gapdéfini partheme.jsonsur les colonnes imbriquées, écrasé par la règle flexbox du conteneur parent. - Aucun conflit constaté en revanche sur la typographie, les deux systèmes respectant les polices définies globalement.
Ce qui n’a pas posé problème
Contrairement à une crainte initiale, aucune perte de contenu n’a été constatée après une série d’éditions croisées : modifier une page dans Elementor puis rouvrir le bloc Gutenberg qu’elle contient dans l’éditeur de site n’a jamais corrompu ses attributs, ni inversement. Les deux systèmes stockent leur contenu dans le même champ post_content, avec des marqueurs de commentaire HTML distincts, et coexistent sans écrasement mutuel tant qu’aucun script de nettoyage automatique de contenu n’intervient entre les deux.
Le point de vigilance pour la suite
Elementor V4 étant encore en bêta au moment de ce test, ce comportement est susceptible d’évoluer d’ici la version stable. Le surcoût de rendu mesuré ici concerne spécifiquement l’insertion ponctuelle de blocs natifs dans une architecture Elementor, un cas de figure fréquent lors d’une migration progressive plutôt qu’un big bang, mais qui a un coût réel qu’il faut budgétiser dans le devis de migration.
Faire cohabiter deux moteurs de rendu n’est jamais gratuit : la question n’est pas de savoir s’il y a un coût, mais s’il reste acceptable au regard du gain de flexibilité obtenu pendant la transition.
Notre verdict
La cohabitation fonctionne, sans perte de contenu, mais avec un surcoût de rendu mesurable (+130 à +180 ms selon la page) et un conflit de marges récurrent qu’il faut corriger manuellement par du CSS additionnel ciblant les conteneurs mixtes. Pour un projet en cours de migration progressive vers Elementor V4, ce coût reste raisonnable sur une période de transition courte, mais ne doit pas devenir une architecture cible durable.
