Improved Asset Loading ne charge que le CSS et le JS strictement nécessaires à la page affichée, au lieu d’empiler les feuilles de style de tous les widgets installés sur le site. Ce réglage, présent dans les fonctionnalités expérimentales d’Elementor depuis plusieurs versions, change la donne quand il faut tenir en même temps deux exigences qui se regardent rarement dans le même projet : la performance et l’accessibilité numérique.
Sur un site porté par une collectivité territoriale, ces deux exigences ne sont pas de simples options qualité : elles conditionnent l’usage réel du service par des publics parfois éloignés du numérique, avec des connexions lentes et des besoins d’accessibilité concrets. Voici le retour d’expérience d’une mise en conformité RGAA menée en parallèle de l’activation de l’Improved Asset Loading, avec les points de friction qu’on ne voit pas dans la documentation officielle.
Pourquoi activer l’Improved Asset Loading sur ce type de site
Un site institutionnel accumule vite des dizaines de widgets Elementor différents : accordéons pour les FAQ, formulaires de contact, cartes interactives, galeries de délibérations, compteurs de statistiques. Sans l’Improved Asset Loading, chaque page charge le CSS et le JS de tous les widgets disponibles sur le site, même ceux qui ne sont utilisés nulle part sur la page consultée.
L’option se trouve dans Elementor > Réglages > Fonctionnalités expérimentales, sous le nom e_font_icon_svg et e_optimized_assets_loading selon les versions. Une fois activée, seuls les fichiers correspondant aux widgets réellement présents sur la page sont enregistrés dans la file d’attente, via les hooks internes d’Elementor qui inspectent la structure du document avant le rendu final.
Ce que l’accessibilité impose en parallèle
La mise en conformité RGAA d’un site de collectivité couvre un périmètre large : contraste des couleurs, navigation au clavier, structure des titres, alternatives textuelles. Sans entrer dans le détail de cet audit, un point mérite d’être isolé ici parce qu’il croise directement le sujet de l’Improved Asset Loading : certains widgets Elementor injectent des scripts qui posent des attributs ARIA au moment du rendu côté client, pas au moment du rendu serveur.
Concrètement, un widget Accordéon ou Onglets ajoute aria-expanded, aria-controls et role="tablist" via son fichier JavaScript associé. Si ce fichier JS n’est pas chargé parce que l’Improved Asset Loading a mal détecté sa présence sur la page (cas fréquent avec un widget imbriqué dans un modèle Elementor Pro appelé dynamiquement), les attributs disparaissent silencieusement. Le rendu visuel reste identique, mais un lecteur d’écran perd toute information sur l’état du composant.
Le protocole de recette qu’on a mis en place
Pour éviter ce genre de régression invisible, l’équipe a construit un protocole de recette croisé, à appliquer avant chaque mise en production :
- Vérifier au clavier (tabulation, entrée, échap) chaque composant interactif sur un échantillon de gabarits représentatifs
- Inspecter la sortie HTML avec les outils développeur pour confirmer la présence des attributs ARIA attendus
- Comparer le poids des ressources chargées avant et après activation, page par page, avec l’onglet Réseau du navigateur
- Rejouer le parcours avec un lecteur d’écran (NVDA en priorité, gratuit et largement utilisé) sur les gabarits critiques : accueil, formulaire de contact, annuaire des services
Les cas particuliers rencontrés sur des modèles complexes
Les modèles Elementor Pro appelés via le Theme Builder (en-tête, pied de page, archives) posent un problème spécifique : l’Improved Asset Loading analyse la page au moment de sa construction, mais certains modèles sont injectés plus tard dans le cycle de rendu, notamment via des shortcodes ou des appels à Elementor\Plugin::instance()->frontend->get_builder_content(). Dans ce cas, le mécanisme de détection des assets peut rater des widgets qui n’apparaissent pas encore dans le DOM analysé.
La parade a consisté à forcer l’enregistrement des styles et scripts critiques pour ces modèles particuliers, via un filtre déclenché sur elementor/frontend/before_enqueue_scripts, plutôt que de désactiver l’Improved Asset Loading pour l’ensemble du site et perdre le gain de performance sur toutes les autres pages.
Extrait du filtre utilisé
add_action( 'elementor/frontend/before_enqueue_scripts', function() {
if ( is_page_template( 'templates/annuaire.php' ) ) {
wp_enqueue_script( 'elementor-accordion' );
wp_enqueue_style( 'elementor-accordion' );
}
} );Ce que ce chantier a changé dans notre méthode
Avant ce projet, les tests d’accessibilité et les audits de performance étaient menés par deux personnes différentes, à deux moments différents du cycle de production. Ce croisement a montré qu’un réglage purement technique, pensé pour la vitesse de chargement, pouvait avoir un impact direct sur la restitution de contenu par les technologies d’assistance.
Le protocole de recette décrit plus haut est désormais systématique sur tous les projets Elementor destinés au secteur public, même quand aucune obligation légale RGAA stricte ne s’applique. Le réflexe reste utile : un widget qui perd ses attributs ARIA silencieusement n’aura jamais de ticket de support, puisque la personne concernée ne saura simplement pas que le composant existe.
En résumé
L’Improved Asset Loading apporte un gain de performance mesurable et réel sur des sites institutionnels riches en widgets, à condition de vérifier que chaque composant interactif conserve ses attributs d’accessibilité une fois le mécanisme activé. Le risque ne se situe pas dans la fonctionnalité elle-même, mais dans les modèles complexes appelés en dehors du cycle de rendu standard, où la détection automatique des assets montre ses limites. Un protocole de recette qui combine test clavier, inspection du DOM et mesure de poids reste, à ce jour, la seule façon fiable de sécuriser ce type d’activation sur un projet sensible.
