Le site d’un cabinet de conseil en recrutement, construit entièrement avec Elementor, affichait un INP (Interaction to Next Paint) de 620 millisecondes sur sa page d’accueil, loin des 200 millisecondes visées pour rester dans la zone verte du rapport. Le client s’inquiétait surtout de son formulaire de candidature, qui semblait « bloqué » pendant une seconde à chaque clic sur mobile.
Sur un site construit avec un page builder, la tentation est de désactiver des fonctionnalités en bloc. Ce billet détaille la méthode inverse, plus longue mais plus sûre : passer chaque script chargé par Elementor et ses widgets au crible, un par un, pour ne couper que ce qui pèse réellement sur l’interactivité.
Étape 1 : lister tout ce qui s’exécute réellement
Avant de toucher à quoi que ce soit, il faut savoir ce qui tourne. L’onglet Performance des outils de développement Chrome, avec un enregistrement centré sur le clic qui pose problème, donne la liste exacte des tâches longues (« long tasks ») et leur script d’origine. Sur ce projet, l’enregistrement a révélé cinq scripts responsables de plus de 80 % du temps de blocage :
elementor-pro/assets/js/webpack-pro.runtime.min.js, chargé sur toutes les pages.- Le widget de formulaire Elementor Pro, avec sa validation en temps réel.
- Un widget de carrousel de témoignages, chargé même hors du champ visible initial.
- Un script tiers de chat en direct, injecté globalement.
- Le gestionnaire d’événements du menu mobile.
Étape 2 : traiter chaque script selon sa vraie utilité
Pour chaque script identifié, la question posée était systématiquement la même : cet élément doit-il être interactif dès le chargement, ou seulement quand l’utilisateur s’en approche ?
Le carrousel de témoignages, par exemple, se trouvait en bas de page. Il n’avait aucune raison de charger sa bibliothèque JavaScript avant que l’utilisateur ne défile jusqu’à lui. La solution a consisté à retirer le widget natif Elementor pour ce bloc précis et à le remplacer par un chargement en différé déclenché par un IntersectionObserver, ajouté via un extrait de code chargé uniquement sur cette page :
document.addEventListener('DOMContentLoaded', function () {
var cible = document.querySelector('.temoignages-carousel');
if (!cible) return;
var observateur = new IntersectionObserver(function (entrees, obs) {
entrees.forEach(function (entree) {
if (entree.isIntersecting) {
var script = document.createElement('script');
script.src = '/wp-content/themes/enfant/js/carousel-temoignages.js';
document.body.appendChild(script);
obs.disconnect();
}
});
});
observateur.observe(cible);
});
Étape 3 : le cas particulier du formulaire
Le formulaire de candidature ne pouvait pas être différé de la même façon : il devait rester utilisable dès l’affichage de la page. Le problème venait ailleurs, dans la validation en temps réel du widget Elementor Pro, qui recalculait l’état complet du formulaire à chaque frappe. La correction a consisté à activer l’option de validation à la soumission plutôt qu’à chaque champ, dans les réglages du widget, ce qui a suffi à supprimer la majorité des tâches longues déclenchées par la saisie.
Étape 4 : sortir le chat en direct du chemin critique
Le script de chat tiers se chargeait de façon synchrone dans le <head>, bloquant le fil principal pendant son initialisation. Il a été déplacé en chargement différé, déclenché soit après trois secondes d’inactivité, soit au premier défilement de la page, via l’attribut data-cfasync combiné à un plugin de gestion de scripts tiers déjà installé sur le site.
Étape 5 : mesurer, page par page
| Page | INP avant | INP après |
|---|---|---|
| Accueil | 620 ms | 180 ms |
| Page candidature | 540 ms | 210 ms |
| Page contact | 410 ms | 140 ms |
Chaque script traité a été mesuré isolément avant de passer au suivant, ce qui a permis d’attribuer précisément le gain à chaque correction plutôt que de tout changer d’un coup sans savoir ce qui avait vraiment compté.
En résumé
Sur un site Elementor, le réflexe de désactiver un module entier de la construction pour gagner en vitesse coûte souvent en fonctionnalités sans garantie de résultat. La méthode script par script prend plus de temps, mais elle laisse un site qui fonctionne exactement comme avant pour l’utilisateur, avec un fil principal enfin disponible quand il clique.
