Trois octets économisés par page ne changent rien. Trois cent kilo-octets économisés par page, multipliés par des milliers de visites mensuelles, représentent une quantité de données transférées non négligeable, et un temps de chargement plus court pour chaque visiteur. Sur un projet Elementor typique, trois choix techniques précis expliquent la majorité des kilo-octets superflus, sans qu’aucun discours général sur l’hébergement bas carbone ne soit nécessaire pour les corriger.
Premier choix : la police d’icônes complète
Par défaut, Elementor propose de charger des bibliothèques d’icônes complètes, comme Font Awesome, qui embarquent plusieurs milliers de glyphes alors qu’un projet donné n’en utilise généralement qu’une trentaine. Le réglage Charger Font Awesome uniquement pour les icônes utilisées, disponible dans les réglages avancés d’Elementor, limite le chargement aux seuls glyphes réellement présents sur le site.
Sur un projet audité en 2023, ce seul réglage a fait passer le poids de la police d’icônes de 110 Ko à environ 30 Ko, soit une économie de 80 Ko chargée sur chaque page du site, y compris celles qui n’affichent qu’une ou deux icônes.
Deuxième choix : l’image non redimensionnée
Une image source de 4000 pixels de large, importée directement dans la médiathèque et affichée dans un widget de 600 pixels de large sans passer par une taille intermédiaire adaptée, force le navigateur à télécharger une image bien plus lourde que ce qui est réellement affiché. WordPress génère automatiquement plusieurs tailles d’image à l’importation, mais un widget Elementor mal configuré peut continuer à pointer vers la taille originale plutôt que vers une taille adaptée à son contexte d’affichage.
La vérification consiste à ouvrir le panneau Image du widget concerné et à contrôler le champ Taille de l’image : un réglage sur Original plutôt que sur une taille définie (par exemple Large ou une taille personnalisée) est le signal d’alerte le plus fréquent.
Troisième choix : le script de widget jamais utilisé
Certains widgets Elementor, notamment ceux fournis par des addons tiers, enregistrent leur script et leur feuille de style sur toutes les pages du site, indépendamment de leur présence réelle sur la page affichée. Un widget de calendrier installé pour une seule page d’événements peut ainsi charger son script sur chaque page du site, y compris la page de contact ou les articles de blog qui n’en ont aucun usage.
- identifier les widgets peu utilisés via le panneau Elementor, Rôle du site, qui liste les widgets actifs et permet de désactiver ceux qui ne servent pas ;
- désactiver les widgets natifs non utilisés dans les réglages avancés, ce qui retire leur script du chargement global ;
- pour un addon tiers mal comporté, vérifier s’il propose un réglage de chargement conditionnel avant d’envisager une alternative.
Mesurer avant de corriger
Ces trois corrections ont un intérêt réel uniquement si elles sont mesurées avant et après, sur le même gabarit, avec le même outil. Le panneau Réseau des outils de développement d’un navigateur, filtré par type de fichier (police, image, script), permet de constater directement le poids économisé pour chacun des trois choix évoqués.
Sur un audit d’écoconception, on commence toujours par ces trois points avant de chercher plus loin : ils représentent souvent l’essentiel du gain accessible sans toucher à l’hébergement ni au code du thème.
Un quatrième point souvent négligé : les polices multipliées
Sans faire partie des trois choix retenus ici, un quatrième point mérite d’être surveillé de près sur un audit d’écoconception complet : le nombre de graisses de police réellement chargées. Un site qui charge six graisses différentes d’une même famille, alors que seules deux sont visibles à l’écran, gaspille une bande passante équivalente à celle d’une image moyenne. La vérification consiste à ouvrir les réglages de police du site et à comparer la liste des graisses activées à celles réellement utilisées dans les widgets de titre et de texte.
En résumé
Une police d’icônes complète, une image non redimensionnée et un script chargé pour un widget jamais utilisé : ces trois causes précises expliquent l’essentiel du poids superflu d’un projet Elementor classique. Corrigées une par une et mesurées, elles offrent un gain concret sans nécessiter de changement d’hébergeur ni de refonte technique du site.
