Le WordPress d'aujourd'hui, décodé pour les développeurs

SEO & GEO

Un score Lighthouse qui chute après un configurateur de devis en iframe

Symptôme sur un site de BTP, diagnostic du poids de l'iframe tierce, correctif par chargement différé, prévention par un budget de performance.

Par WordPress Développement • 13 janvier 2022 • 4 min de lecture • Aucun commentaire
Un score Lighthouse qui chute après un configurateur de devis en iframe

92 puis 58 : c’est le score Lighthouse mobile mesuré avant puis après l’intégration d’un configurateur de devis en ligne, sur la page de contact d’un site vitrine spécialisé en travaux de rénovation énergétique. L’outil, fourni par un prestataire tiers sous forme d’iframe à coller directement dans une page, avait été ajouté sans test de performance préalable, l’urgence commerciale ayant primé sur la vérification technique.

Symptôme : une page qui devient lente sans changement visible

Rien, à l’œil nu, ne distingue la nouvelle page de son ancienne version : le configurateur s’affiche correctement, la mise en page reste cohérente avec le reste du site. Seul un audit Lighthouse révèle l’ampleur du problème, avec une chute de 34 points sur le score de performance mobile, et un temps de blocage total qui passe d’environ 80 millisecondes à plus de 600 millisecondes sur la même page.

Diagnostic : une iframe qui embarque son propre écosystème de scripts

L’onglet réseau des outils de développement du navigateur révèle la cause : l’iframe du configurateur charge, indépendamment du reste de la page, ses propres bibliothèques JavaScript, une police de caractères personnalisée, et un script de suivi analytique propre au prestataire. Ce chargement s’exécute immédiatement à l’ouverture de la page, avant même que le visiteur n’ait manifesté une quelconque intention d’utiliser le configurateur.

L'essentiel à retenir : Le score de performance a chuté de 34 points après intégration ; L'iframe embarquait ses propres scripts hors du contrôle du site ; Le chargement différé au clic a résolu l'essentiel du symptôme

Aucun de ces scripts n’est sous le contrôle direct du site : ils sont servis depuis le domaine du prestataire, ce qui empêche toute optimisation classique comme la minification ou la mise en cache locale. Le seul levier disponible consiste à retarder le moment où ce chargement se déclenche.

Correctif : charger l’iframe au clic plutôt qu’à l’ouverture de la page

La solution retenue remplace l’iframe directe par un aperçu statique (une capture d’écran du configurateur avec un bouton d’appel à l’action), et ne charge l’iframe réelle qu’au moment où le visiteur clique sur ce bouton :

document.querySelector('.charger-configurateur').addEventListener('click', function (e) {
    var conteneur = document.querySelector('.configurateur-conteneur');
    var iframe = document.createElement('iframe');
    iframe.src = conteneur.dataset.src;
    conteneur.appendChild(iframe);
    e.target.remove();
});

Ce script, ajouté via l’enqueue classique d’un fichier JavaScript propre au thème, ne dépend d’aucune extension tierce. Le résultat mesuré après correctif : un score Lighthouse remonté à 87, le visiteur qui ne clique jamais sur le configurateur n’ayant plus jamais à charger le moindre script du prestataire.

Une limite assumée du correctif

Ce gain de performance se paie d’un coût d’interaction : le visiteur qui souhaite utiliser le configurateur doit désormais patienter un court instant après son clic, le temps que l’iframe et ses scripts se chargent réellement. Ce compromis a été jugé acceptable au regard du gain global constaté sur l’ensemble des visiteurs de la page, dont une minorité seulement utilise effectivement le configurateur.

Prévention : instaurer un budget de performance avant toute nouvelle intégration

Pour éviter qu’un incident similaire ne se reproduise avec un futur outil tiers, l’équipe a mis en place une règle simple : tout nouvel élément intégré par iframe ou script externe doit faire l’objet d’un audit Lighthouse comparatif avant et après intégration en environnement de préproduction, avec un seuil d’alerte fixé à une perte de dix points de score.

  • Tester systématiquement en préproduction avant toute mise en ligne d’un outil tiers embarqué.
  • Privilégier un chargement différé au clic ou au défilement pour tout élément non indispensable à l’affichage initial de la page.
  • Documenter le budget de performance accepté par type de page, pour objectiver la décision plutôt que de la laisser à l’appréciation ponctuelle de chacun.

En résumé

Une iframe tierce reste, du point de vue de la performance, une boîte noire dont le contenu échappe largement au contrôle du site qui l’intègre. Retarder son chargement jusqu’à une action explicite du visiteur constitue souvent le levier le plus efficace, faute de pouvoir optimiser directement des scripts hébergés et gérés par un prestataire externe.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi