Sur la page Contact, il y a une carte pour trouver le bureau. Dans le pied de page, un widget avec les derniers avis de clients. Sur la page d’accueil, une grille avec les photos les plus récentes du profil social de l’entreprise. Ce sont des éléments que presque tous les sites d’entreprise finissent par avoir, et qui s’ajoutent par un copier-coller : le service fournit un extrait de code, généralement une iframe ou un script qui en crée une, et le contenu apparaît dans la page.
La simplicité de l’intégration cache un coût. Chaque iframe est un document web complet, avec son propre HTML, ses propres feuilles de style, ses propres scripts, ses propres polices et ses propres connexions aux serveurs du fournisseur. Une carte interactive peut peser autant que tout le reste de la page réuni. Dans cet article, nous voyons ce que coûtent vraiment ces widgets, comment ils influent sur les Core Web Vitals et quelles alternatives permettent d’offrir les mêmes informations pour une fraction du poids.
Un document dans le document
Une iframe intègre une page web à l’intérieur d’une autre. Le navigateur la charge comme n’importe quelle page : il résout le domaine, ouvre une connexion, télécharge le HTML, puis les feuilles de style, les scripts, les images et les données nécessaires. Pour une carte interactive, cela signifie la bibliothèque de rendu de la carte, les tuiles d’image, les polices, les icônes, les données de configuration et souvent les outils d’analytics du fournisseur. Pour un widget d’avis, le framework avec lequel il est construit, les données des avis, les photos de profil. Pour un fil de réseau social, des dizaines d’images et le code pour les gérer.
Pour des raisons de sécurité, les navigateurs modernes peuvent exécuter les iframes d’autres domaines dans des processus séparés, mais cela ne les rend pas gratuites : les ressources passent quand même par la même connexion réseau, le code s’exécute sur le même processeur et occupe la même mémoire de l’appareil. Sur un smartphone de milieu de gamme, une carte interactive qui s’initialise pendant le chargement de la page ralentit tout le reste.
Comment elles influent sur les Core Web Vitals
L’effet sur le LCP est indirect mais concret : les ressources du widget se disputent la bande passante avec celles de la page, et si le widget est près du haut, comme une carte dans la partie supérieure de la page Contact, il peut retarder l’image ou le texte principal. Le CLS est touché quand l’iframe n’a pas de dimensions réservées : de nombreux widgets démarrent avec une hauteur minimale et s’agrandissent à l’arrivée du contenu, repoussant vers le bas tout ce qui suit. L’INP souffre du travail que font les scripts des widgets pendant et après le chargement, juste au moment où l’utilisateur commence à interagir.
Un détail rend ces problèmes difficiles à repérer. Les scripts de la page ne peuvent pas voir ce qui se passe à l’intérieur des iframes d’autres domaines ; les outils de mesure fondés sur JavaScript, y compris la bibliothèque web-vitals, n’enregistrent donc pas les décalages de mise en page ni les interactions qui s’y produisent. Les données de terrain collectées par Chrome pour le Chrome UX Report, en revanche, peuvent en tenir compte. Le résultat est que les données de votre propre système de monitoring et celles de Search Console peuvent diverger, et le widget intégré est l’une des causes possibles.
Le premier correctif : lazy loading et dimensions
Deux correctifs minimaux doivent être appliqués à toute iframe, et ils ne demandent pas de modifier le widget. Le premier est l’attribut loading="lazy", qui repousse le chargement jusqu’à ce que l’utilisateur fasse défiler la page près de l’iframe. Pour un widget situé dans le pied de page, cela signifie que la plupart des visiteurs, qui n’arrivent pas en bas, ne le chargent jamais. WordPress l’ajoute automatiquement aux iframes du contenu depuis la version 5.7, mais pas à celles insérées dans les modèles du thème ou par des plugins, qu’il faut vérifier.
Le second consiste à réserver de l’espace : des dimensions explicites ou un rapport avec aspect-ratio, et pour les widgets dont la hauteur change, une hauteur minimale égale à la hauteur typique du contenu final. Ainsi l’iframe peut se charger quand elle le veut sans rien décaler.
<iframe src="https://widget.esempio.com/recensioni?azienda=123"
loading="lazy" width="600" height="420"
title="Avis des clients"
style="width: 100%; height: auto; aspect-ratio: 600 / 420; border: 0;"></iframe>Ces correctifs réduisent les dégâts, mais ils n’éliminent pas le coût pour ceux qui font défiler la page jusqu’au widget, ni pour les widgets placés près du haut. Pour ceux-là, il faut des alternatives plus radicales.
Les cartes
La carte interactive est le cas le plus courant et celui qui a la solution la plus efficace : la façade. À la place de la carte, la page affiche une image statique de la zone avec un repère sur le bureau, et un bouton pour ouvrir la carte interactive. Ce n’est que lorsque l’utilisateur le touche que l’image est remplacée par l’iframe. Pour la plupart des visiteurs, qui veulent seulement voir où se trouve le bureau ou obtenir un itinéraire, l’image suffit.
L’image peut être générée avec les services de cartes statiques des principaux fournisseurs, ou préparée une fois pour toutes et hébergée sur votre propre site, puisque l’emplacement d’un bureau change rarement. À côté, un lien d’itinéraire qui, sur un smartphone, ouvre directement l’application de navigation est souvent plus utile que la carte elle-même : celui qui doit rejoindre le bureau veut un itinéraire, pas une carte à déplacer du doigt dans une page web.
<div class="mappa-facciata">
<img src="/media/mappa-sede.webp" width="1200" height="675" loading="lazy"
alt="Plan de la zone avec le bureau au 10 via Roma, Milan">
<button type="button" data-src="https://www.google.com/maps/embed?pb=…">
Ouvrir la carte interactive
</button>
<a href="https://www.google.com/maps/dir/?api=1&destination=Via+Roma+10+Milano">
Itinéraire
</a>
</div>Quelques lignes de JavaScript, au clic sur le bouton, créent l’iframe avec l’adresse indiquée dans l’attribut data-src et la substituent à l’image, avec les mêmes dimensions pour ne rien décaler. C’est la même technique que celle vue pour les vidéos dans l’article sur la vidéo et les Core Web Vitals.
Les avis
Les widgets d’avis des plateformes spécialisées affichent la note moyenne, le nombre d’avis et quelques commentaires récents. C’est une information utile pour la confiance des visiteurs, mais elle change rarement d’heure en heure. Outre le widget, de nombreuses plateformes offrent une interface de programmation permettant de lire les mêmes données : le site peut les récupérer périodiquement, par exemple une fois par jour, les stocker et les afficher en HTML normal, avec ses propres styles. Le résultat est un bloc de quelques kilo-octets, visible immédiatement, sans décalage et sans scripts externes.
Quand la plateforme impose par contrat l’usage de son propre widget, il vaut au moins la peine de choisir la version la plus simple, comme un badge avec la note plutôt qu’un carrousel d’avis, de le charger en différé et de lui réserver de l’espace. Et il vaut la peine de vérifier si le widget est vraiment nécessaire sur toutes les pages ou seulement sur celles où la confiance compte le plus, comme les fiches produit ou la page des services.
Les fils de réseaux sociaux
Les fils des plateformes sociales intégrés dans un site comptent parmi les widgets les plus lourds : des dizaines d’images en haute résolution, des scripts pour les carrousels et les fenêtres de détail, des outils de suivi. Leur valeur pour le visiteur est souvent modeste, et dans la plupart des cas un lien vers le profil social, accompagné de quelques images choisies, remplit la même fonction.
Si le fil est jugé important, l’alternative est la même que pour les avis : récupérer périodiquement les dernières images via l’interface de la plateforme, les enregistrer sur votre propre site dans des formats modernes et aux bonnes dimensions, et les afficher comme une grille d’images normale avec lazy loading. Il existe des plugins WordPress qui font exactement cela ; il vaut mieux choisir ceux qui stockent les images localement plutôt que de les charger depuis les serveurs de la plateforme à chaque visite.
Autres widgets courants
Le même raisonnement s’applique à de nombreux autres éléments intégrés : calendriers de réservation, formulaires de contact provenant de services externes, systèmes de commentaires, prévisions météo, convertisseurs de devises, boutons de partage avec compteurs. Pour chacun, il vaut la peine de se poser trois questions. Est-il vraiment nécessaire à tous les visiteurs, ou seulement à certains ? Peut-il être affiché sous forme statique et chargé sous forme interactive seulement à la demande ? Les données qu’il affiche peuvent-elles être récupérées par le serveur et rendues en HTML ? Presque toujours, au moins une des réponses ouvre la voie à une alternative plus légère. Le tableau général est celui décrit dans l’article sur les scripts tiers.
Confidentialité et consentement
Il y a une raison supplémentaire de préférer les alternatives statiques : de nombreux widgets déposent des cookies et transmettent des données de navigation aux fournisseurs, et dans beaucoup de configurations de bandeaux de cookies ils sont bloqués tant que l’utilisateur n’a pas donné son consentement. Le résultat, s’il est mal géré, est une boîte vide ou un message d’avertissement à la place de la carte, suivi d’un décalage de mise en page à l’arrivée du contenu. Une façade ou un contenu généré par le serveur ne contacte pas le fournisseur avant que ce soit nécessaire, occupe toujours la bonne place et simplifie la gestion du consentement, comme nous l’avons vu en parlant des bandeaux de consentement.
Un exemple : la page Contact
Prenons la page Contact d’un cabinet professionnel : en haut une carte interactive pleine largeur, en dessous un formulaire de contact, dans le pied de page un carrousel d’avis et le fil des dernières photos publiées sur les réseaux sociaux. Sur un smartphone, la page transfère près de trois mégaoctets, ouvre des connexions vers une douzaine de domaines et a un LCP de plus de quatre secondes, parce que le plus grand élément est la carte, qui doit charger ses propres tuiles avant de pouvoir être affichée. Pendant que les avis arrivent, le pied de page s’allonge et décale le contenu.
Il y a trois correctifs : la carte devient une image statique avec des boutons pour l’ouvrir et pour obtenir l’itinéraire ; les avis sont lus une fois par jour par le serveur et affichés sous forme de texte avec la note moyenne ; le fil social est remplacé par un lien vers le profil avec trois images enregistrées localement. La page descend sous trois cents kilo-octets, le LCP devient l’image de la carte, légère et à priorité élevée, et plus rien ne bouge. Les informations offertes aux visiteurs sont exactement les mêmes.
Comment les repérer et les mesurer
Lighthouse signale explicitement les intégrations tierces qui pourraient être remplacées par une façade et indique le poids des ressources de chaque fournisseur. Dans le panneau Réseau de DevTools, en regroupant ou en filtrant les requêtes par domaine, on voit combien de ressources proviennent de chaque service et à quel moment elles se chargent par rapport au reste de la page. Un test avec et sans le widget, par exemple en bloquant le domaine du fournisseur grâce à la fonction prévue dans DevTools, mesure directement son coût sur le LCP et sur le temps de chargement.
Sur le terrain, comparer les données de Search Console avec celles de votre propre système de monitoring, si vous en avez un, peut révéler des problèmes qui se produisent à l’intérieur des iframes. Et pour chaque widget, il vaut la peine de se demander combien de visiteurs l’utilisent vraiment : si moins de cinq pour cent des utilisateurs interagissent avec la carte, les quatre-vingt-quinze pour cent restants en paient le coût sans aucun bénéfice.
En résumé
Les cartes, les avis, les fils de réseaux sociaux et les autres widgets intégrés sont des documents complets à l’intérieur de la page, avec leurs propres ressources et scripts, et ils peuvent peser plus que le reste du site. Ils influent sur le LCP en se disputant la bande passante, sur le CLS quand ils n’ont pas d’espace réservé et sur l’INP par le travail de leurs scripts, parfois d’une façon que les outils de mesure de la page ne voient pas.
Le strict minimum est le lazy loading avec des dimensions réservées. Les meilleures solutions sont les façades, qui ne chargent le widget que lorsque l’utilisateur le demande, et les alternatives générées par le serveur, qui affichent les mêmes données en simple HTML. Elles offrent les mêmes informations pour une fraction du poids, simplifient la gestion de la confidentialité et donnent souvent une meilleure expérience : un lien d’itinéraire est plus utile qu’une carte à faire glisser du doigt.
