2,3 secondes. C’est le temps de rendu moyen (côté PHP, avant tout cache) d’une page article sur un site de presse qui publie entre 80 et 120 contenus par jour, avec un historique de plus de 200 000 pages indexées. Sur ce projet, le passage des Sections classiques aux Containers Flexbox n’était pas une lubie de développeur en quête de nouveauté : c’était devenu une nécessité pour tenir le rythme éditorial sans multiplier les serveurs.
Le constat de départ était simple à formuler mais difficile à admettre : chaque gabarit de page (accueil, rubrique, article, tag) empilait des Sections imbriquées, certaines avec quatre ou cinq niveaux de colonnes internes, héritées de années de retouches successives par différents prestataires. Le rendu HTML généré par Elementor pour une seule page article dépassait 480 Ko avant minification, avec une profondeur de DOM qui rendait le CSS de plus en plus coûteux à calculer pour le navigateur comme pour le serveur.
Le diagnostic sur l’existant
Avant de migrer quoi que ce soit, nous avons profilé le rendu avec Query Monitor et un export Xdebug ciblé sur les hooks elementor/frontend/before_render et elementor/frontend/after_render. Sur le gabarit article, à lui seul, le widget de contenu lié imbriquait sept Sections pour obtenir une mise en page à trois zones (contenu, sommaire sticky, encart pub). Chaque Section générait ses propres classes de colonnes en pourcentages, avec des media queries dupliquées à chaque breakpoint.
Le second facteur aggravant tenait au nombre de widgets globaux insérés dans le Theme Builder : bannière d’alerte, bloc newsletter, module de partage social. Chacun ajoutait sa propre couche de Section, alors qu’aucun n’avait besoin de plus qu’un conteneur simple.
La stratégie de migration retenue
Nous avons écarté l’outil de conversion automatique de Sections vers Containers fourni par Elementor pour les gabarits les plus visités : sur ce volume de trafic, une régression visuelle même mineure coûte cher en image de marque. La migration a donc été faite gabarit par gabarit, dans cet ordre : page article (le plus gros volume de vues), page rubrique, page d’accueil, puis les templates secondaires.
Pour chaque gabarit, la règle appliquée a été stricte : un Container racine en direction column, des Containers enfants en row uniquement là où une disposition horizontale était réellement nécessaire, et suppression systématique des wrappers qui ne servaient qu’à appliquer une marge.
Un exemple concret sur le bloc « À lire aussi »
Ce widget, affiché sur chaque page article, comportait à l’origine trois Sections imbriquées pour afficher quatre vignettes en grille responsive. Reconstruit en un seul Container avec la propriété flex-wrap: wrap et des enfants dimensionnés en flex-basis, il tient désormais dans une seule structure, sans Section parasite.
<!-- Structure simplifiée du Container -->
.e-con.a-lire-aussi {
display: flex;
flex-wrap: wrap;
gap: 24px;
}
.e-con.a-lire-aussi > .e-con-inner {
flex: 1 1 260px;
}
Les chiffres après bascule
Sur un échantillon de 40 pages articles représentatives (contenu court, long, avec ou sans galerie), le temps de rendu PHP est passé d’une moyenne de 2,3 secondes à 1,2 seconde, soit une réduction de 47 %. Le poids du DOM généré par Elementor a diminué de 4,2 Mo cumulés sur les principaux gabarits, et le nombre de nœuds DOM sur la page article est passé de 2 840 à 1 690.
- Temps de rendu serveur (hors cache) : -47 % sur le gabarit article
- Nombre de nœuds DOM : -40 % en moyenne
- Taille du CSS généré par page : -31 %
- Score Lighthouse Performance mobile : de 61 à 78
Ce que cette migration ne résout pas
Il faut être honnête sur le périmètre : cette optimisation ne touche ni la stratégie de CDN d’images, ni la gestion de la monétisation publicitaire, deux sujets à part entière sur un média de cette taille, traités séparément par l’équipe technique. Les Containers réduisent le travail de rendu et de mise en page, pas le poids des médias ni la latence des régies publicitaires tierces.
Sur un site à fort volume de pages, la migration vers les Containers rapporte d’autant plus qu’elle est appliquée aux gabarits les plus vus, pas aux pages les plus complexes visuellement.
En résumé
La migration des Sections vers les Containers Flexbox n’est pas qu’un confort d’édition pour les intégrateurs : sur un site à très fort volume de pages, elle a un effet mesurable sur le temps de rendu serveur et la légèreté du DOM. Le gain de 47 % obtenu ici tient autant à la suppression des wrappers inutiles qu’au passage technique lui-même, ce qui confirme qu’un audit préalable du gabarit reste indispensable avant toute conversion automatique.
