Une page convertie peut être tout aussi rapide qu’une page codée à la main — ou nettement plus lente, selon quelques choix effectués pendant et après la conversion.
Privilégiez les widgets natifs aux blocs HTML
C’est le facteur le plus important. Une page placée dans un seul grand widget HTML emporte avec elle toute sa feuille de style d’origine, y compris des règles pour des éléments qui ne se trouvent pas sur la page. Le mode composants natifs produit de vrais widgets dont Elementor génère et met en cache les styles par page : vous livrez donc beaucoup moins de CSS inutilisé — et vous obtenez en bonus une page modifiable.
Décidez quoi faire de la feuille de style d’origine
Conserver les styles en ligne est utile pendant la conversion, car c’est ce qui permet de mesurer correctement les styles basés sur les classes. Mais une fois que les widgets portent leurs propres réglages, le bloc CSS restant en haut de la page est souvent redondant. Essayez de le supprimer et vérifiez la mise en page — si rien ne bouge, vous venez de supprimer un poids mort.
Les images méritent le plus d’attention
- Téléversez de vraies images dans la bibliothèque de médias plutôt que d’incorporer des URL de données. Une image en Base64 ne peut pas être redimensionnée, mise en cache séparément ni chargée en différé, et elle gonfle le HTML de la page lui-même.
- Laissez WordPress servir des tailles responsives au lieu d’imposer partout une seule grande taille.
Ce que fait réellement l’option d’optimisation des images
Celle-ci est plus limitée que son nom ne le suggère, et connaître ses limites vous évite d’en attendre quelque chose qu’elle ne fera pas.
Elle ne s’exécute qu’en mode haute fidélité, et uniquement sur les images en données Base64 — PNG, JPEG ou WebP — dont la taille dépasse environ 135 Ko. Celles-ci sont décodées, réduites pour que leur côté le plus long fasse au maximum 2560 px, puis réencodées. La vue des résultats indique combien ont été traitées et combien d’espace a été gagné.
Ce qu’elle ne fait pas : elle ne touche pas aux images référencées par URL, car ce sont des fichiers sur un serveur que l’outil n’a pas à réécrire. Et en mode composants natifs, elle ne s’exécute pas du tout — les images Base64 y deviennent des emplacements vides étiquetés, à remplir depuis la bibliothèque de médias, ce qui est de toute façon le meilleur résultat.
Le résumé honnête est donc que cette option ne répond qu’à une situation précise : l’import en haute fidélité d’une page dont toutes les images étaient incorporées, généralement une page générée par un outil d’IA. Si vos images sont de vraies URL, l’option n’a pas d’intérêt et la véritable optimisation se produit là où elle doit avoir lieu — dans votre bibliothèque de médias, WordPress générant des tailles responsives.
Surveillez la profondeur d’imbrication
Les arborescences de conteneurs profondes ne sont pas seulement difficiles à modifier — chaque niveau ajoute un nœud DOM et un ensemble supplémentaire de règles CSS générées. Si la carte de structure affiche une profondeur de sept ou huit, simplifiez la source ou définissez une racine de copie plus profonde dans l’arborescence. Un rendu plus plat est à la fois plus rapide et plus facile à maintenir.
Polices
Une page convertie indique les polices utilisées par la source. Si ce ne sont pas des polices que votre site charge déjà, enregistrez-les correctement ou basculez vers la typographie du site afin que la page utilise des polices que vous servez déjà. Ce qu’il faut éviter, c’est de charger une deuxième famille de polices pour une seule section importée.
Réintégrez les comportements de manière native
Les scripts sont supprimés pendant la conversion, ce qui est une bonne chose tant pour les performances que pour la sécurité. Lorsque vous reconstruisez des sliders, des onglets ou des compteurs, utilisez les widgets d’Elementor plutôt que de recoller des scripts tiers — ils font déjà partie de l’ensemble que vous chargez.
Pourquoi une page convertie n’est pas automatiquement gonflée
On peut raisonnablement craindre qu’une conversion automatique enfouisse la page sous les réglages, et que tous ces réglages deviennent du CSS. Deux choses empêchent que cela se produise.
Premièrement, les valeurs responsives ne sont écrites que lorsqu’elles diffèrent du bureau. Un conteneur avec le même padding sur toutes les largeurs reçoit une seule valeur de padding, pas trois. Sur une page de soixante widgets, c’est la différence entre une feuille de style légère et une autre qui comporte deux tiers de règles redondantes.
Deuxièmement, les enveloppes qui ne font manifestement rien sont supprimées plutôt que converties. Chaque conteneur qui survit est un vrai <div> avec ses propres règles générées ; supprimer ceux qui n’ont aucun effet de style retire donc à la fois un nœud DOM et son CSS.
Ce que rien de tout cela ne peut corriger, c’est un balisage source qui était profond dès le départ. Le convertisseur reproduit votre HTML ; il ne le reconçoit pas. Une source à sept niveaux produit une page lourde, quel que soit le soin apporté à chaque niveau. C’est pourquoi aplatir à la source vaut plus que n’importe quel nettoyage après import.
Mesurez, puis nettoyez
Faites passer la page à un test de vitesse avant et après votre passage de nettoyage. En général, les gains proviennent de trois endroits : la suppression du bloc de feuille de style redondant, le remplacement des images surdimensionnées et l’aplatissement d’une arborescence trop imbriquée. Aucune de ces actions ne prend longtemps et, ensemble, elles représentent généralement l’essentiel de la différence.
Surveillez les bons chiffres. Le poids total de la page et le Largest Contentful Paint réagissent au travail sur les images. Le Cumulative Layout Shift réagit à l’attribution de dimensions explicites aux images — un espace réservé que vous avez rempli depuis la bibliothèque de médias en possède, une image Base64 n’en possède souvent pas. Et le nombre de nœuds DOM, que la plupart des rapports affichent et que la plupart des gens ignorent, est celui qui vous indique si l’imbrication est maîtrisée.