Ouvrez l’onglet réseau de votre navigateur sur un site Elementor tout juste installé, avec un thème par défaut et deux ou trois widgets sur la page d’accueil. Vous verrez souvent défiler une dizaine de feuilles de style et autant de scripts, alors que la page n’affiche qu’un titre, une image et un bouton. Ce constat, beaucoup de développeurs WordPress l’ont fait en 2023, et Elementor lui-même l’a reconnu en ouvrant, dans les réglages expérimentaux du plugin, plusieurs options rassemblées sous le nom d’Improved Asset Loading.
Ces options ne sont pas un simple bouton magique qui divise le poids de la page par deux. Ce sont des changements ciblés dans la manière dont Elementor génère et imprime ses fichiers CSS et JS, et dont il gère les polices. Autant les comprendre en détail avant de les activer sur un site en production, car certains réglages peuvent casser l’affichage si votre thème ou vos widgets custom ne s’y attendent pas.
Le poids par défaut d’Elementor, un problème connu
Par conception, Elementor génère un fichier CSS par widget et par device, plus un fichier CSS global pour chaque page ou chaque template. Sur un site avec beaucoup de sections différentes, cela peut représenter plusieurs dizaines de petits fichiers, chacun avec son propre appel HTTP en HTTP/1.1, ou son propre en-tête même en HTTP/2. À cela s’ajoutent les scripts : jQuery, le runtime front d’Elementor, les scripts spécifiques à certains widgets comme les carrousels ou les accordéons, et souvent Font Awesome et Google Fonts chargés en intégralité, même quand une seule icône ou une seule graisse de police est réellement utilisée.
Le résultat concret, c’est un poids de page gonflé artificiellement et un nombre de requêtes qui pénalise le Largest Contentful Paint et le temps de chargement perçu, surtout sur mobile avec une connexion moyenne. Ce n’est pas qu’Elementor soit mal codé : c’est le prix d’un éditeur visuel qui doit rester flexible et compatible avec des milliers de configurations différentes. Mais rien n’empêche de reprendre la main sur ce qui est chargé.
L’Improved Asset Loading, ce que la fonctionnalité change concrètement
Dans Elementor > Réglages > Fonctionnalités expérimentales, vous trouverez un groupe d’options regroupées sous ce nom. Elles agissent à plusieurs niveaux :
- Un chargement plus fin des fichiers CSS des widgets, pour éviter d’imprimer des styles pour des widgets qui ne sont pas présents sur la page en cours.
- Une méthode d’impression du CSS revue, qui privilégie les fichiers externes mis en cache par le navigateur plutôt que du CSS injecté directement dans le
<head>à chaque chargement. - Un chargement conditionnel de Font Awesome et de Google Fonts, activé uniquement si un widget de la page en a réellement besoin.
Chacune de ces options peut être activée indépendamment. C’est important : vous n’êtes pas obligé de tout basculer d’un coup. La bonne pratique consiste à activer un réglage, vérifier l’affichage sur les pages les plus complexes du site, puis passer au suivant.
Font Awesome et Google Fonts chargées seulement si utilisées
C’est sans doute le gain le plus facile à obtenir. Par défaut, de nombreuses installations Elementor chargent l’intégralité de la bibliothèque d’icônes Font Awesome, soit plusieurs dizaines de kilo-octets de CSS et de fichiers de polices, même si votre site n’affiche que trois icônes de réseaux sociaux. Il en va de même pour Google Fonts : si votre thème définit déjà sa typographie et que vous n’avez jamais touché aux réglages de police dans Elementor, il n’y a souvent aucune raison de charger une police Google supplémentaire.
Avec le chargement conditionnel activé, Elementor analyse le contenu de la page au moment de la génération du CSS et n’enqueue la bibliothèque d’icônes ou la police que si un widget de cette page l’utilise réellement. Concrètement, une page de contact sans icône verra disparaître l’appel à Font Awesome, et une page qui n’utilise que la police système du thème ne déclenchera plus d’appel vers les serveurs de Google Fonts.
Un point de vigilance sur les icônes
Si vous insérez des icônes via du HTML personnalisé, un shortcode ou un widget tiers qui ne déclare pas correctement sa dépendance à Font Awesome, elles peuvent disparaître silencieusement une fois le chargement conditionnel activé. Testez systématiquement chaque type de page après l’activation.
CSS inline critique contre fichiers externes : quelle différence
Historiquement, Elementor a proposé une option pour imprimer le CSS directement dans le <head> de la page, en inline, plutôt que de le charger via un fichier .css externe mis en cache. L’idée derrière l’inline était d’éviter une requête HTTP bloquante pour le rendu : le navigateur n’a pas besoin d’aller chercher un fichier séparé, le style est déjà là.
Le problème, c’est que le CSS inline n’est jamais mis en cache par le navigateur. Il est retéléchargé à chaque chargement de page, dans le poids du HTML lui-même, ce qui alourdit chaque requête et empêche de profiter des en-têtes de cache classiques. Sur un site avec beaucoup de pages vues répétées par les mêmes visiteurs, ou avec un bon cache navigateur configuré côté serveur, la méthode externe redevient plus avantageuse.
Avec l’Improved Asset Loading, Elementor privilégie par défaut l’impression via des fichiers CSS externes, générés et mis en cache sur le serveur, ce qui permet au navigateur de les réutiliser d’une page à l’autre. Le compromis à connaître : sur une toute première visite d’un visiteur sans aucun cache, cela ajoute des requêtes HTTP supplémentaires. C’est un arbitrage entre performance de première visite et performance de visite récurrente, à ajuster selon le profil de trafic de votre site.
Impact mesuré sur le poids des pages et les Core Web Vitals
Sur un site vitrine test, construit avec un thème Hello Elementor et une dizaine de widgets standards (titre, image, icônes, formulaire de contact), voici ce que l’activation complète de l’Improved Asset Loading a changé, en comparant l’onglet réseau avant et après sur une page d’accueil typique :
| Mesure | Avant | Après |
|---|---|---|
| Nombre de requêtes CSS/JS | 23 | 15 |
| Poids total transféré | 612 Ko | 430 Ko |
| Requête Font Awesome | présente | absente (page sans icône) |
Ces chiffres ne sont pas une garantie universelle : ils dépendent entièrement du thème, du nombre de widgets, et des extensions tierces installées. Mais la tendance est claire, et cohérente avec ce que rapportent d’autres développeurs de la communauté : moins de requêtes, moins d’octets transférés, et par ricochet un effet positif sur le Largest Contentful Paint, puisque le navigateur a moins de ressources bloquantes à récupérer avant de pouvoir peindre le contenu principal.
Avant d’activer ces options sur un site client en production, faites toujours le test sur un environnement de staging identique, et vérifiez en particulier les pages avec des popups, des formulaires et des widgets tiers : ce sont les premières à révéler un souci de dépendance CSS ou JS mal déclarée.
En résumé
L’Improved Asset Loading n’est pas un simple interrupteur « site plus rapide », c’est un ensemble de réglages fins qui demandent d’être testés un par un. Le chargement conditionnel de Font Awesome et de Google Fonts est le gain le plus simple et le plus sûr à activer sur la majorité des sites. Le choix entre CSS inline et fichiers externes mérite en revanche réflexion selon le profil de vos visiteurs, nouveaux ou récurrents.
Dans tous les cas, ces fonctionnalités restent classées comme expérimentales fin 2023 : elles évoluent encore, et certaines extensions tierces n’ont pas toutes été mises à jour pour s’y adapter proprement. Activez-les progressivement, mesurez avant et après avec l’onglet réseau ou un outil comme PageSpeed Insights, et gardez toujours un moyen simple de revenir en arrière si un widget se met à mal s’afficher.
