par Un site technologique charge des dizaines de scripts, et la plupart ne viennent pas de votre équipe. Chat, analytics, A/B testing, carte de consentement, lecteur vidéo : chacun ajoute sa part de latence. Quand les Core Web Vitals se dégradent, le réflexe est de réécrire le CSS ou de compresser les images. C’est souvent une erreur de cible. Le coupable se cache souvent dans les balises script que vous n’avez jamais écrites, et il se mesure bien avant de se corriger.
Pourquoi les scripts tiers pèsent plus lourd que votre propre code
Les Core Web Vitals reposent sur trois mesures : le Largest Contentful Paint pour la vitesse d’affichage, le First Input Delay pour la réactivité, et le Cumulative Layout Shift pour la stabilité visuelle. Google a annoncé en 2020 l’intégration de ces signaux à son algorithme pour la mi-2021, la fameuse mise à jour de l’expérience des pages. Depuis, un widget de chat mal chargé peut coûter plus cher qu’une image non compressée. Pour comprendre comment ces métriques s’articulent avec le reste du travail SEO, le blog viareferencement.com détaille la mécanique.
Un script tiers s’exécute sur le thread principal du navigateur, celui qui doit aussi peindre la page et répondre au premier clic. Il télécharge ses dépendances, ouvre des connexions vers des domaines inconnus, puis attend des données avant de rendre quoi que ce soit. Votre code maison, lui, vous le connaissez, vous le versionnez, vous le testez. Le script d’un prestataire change sans prévenir, du jour au lendemain, et votre LCP bouge avec lui.
Ce que Lighthouse ne vous montrera jamais vraiment
Lighthouse reste l’outil que tout le monde ouvre en premier. Il tourne en laboratoire, avec une limitation de débit simulée, sur un poste de bureau ou un profil mobile fictif. Le problème, c’est qu’il effectue un « cold load » : la page se charge comme si personne ne l’avait jamais visitée, sans cache, sans cookie, sans session.
C’est le chargement le plus lent possible, donc le plus flatteur pour un rapport. Dans la vraie vie, un visiteur qui revient a déjà en cache la moitié de vos scripts. Mais il subit aussi une connexion instable et un onglet ouvert en arrière-plan, une combinaison qu’aucun audit de labo ne reproduit fidèlement.
Autre angle mort : la limite de temps. Un audit de laboratoire coupe souvent le chargement au bout de quelques secondes et note ce qu’il a pu observer. Un script tiers qui met du temps à répondre mais finit par s’exécuter passe parfois sous le radar. Ce qui compte pour l’utilisateur, c’est le décalage entre le moment où il clique et le moment où la page réagit. Aucun rapport de labo ne reproduit cette attente réelle.
Repérer les scripts qui coûtent le plus
Avant de supprimer quoi que ce soit, il faut savoir qui consomme. Ouvrez l’onglet Réseau de votre navigateur, rechargez la page en mode navigation privée et triez par taille de transfert, puis par temps de blocage. Vous verrez vite que trois ou quatre domaines concentrent le coût réel. Les balises script du head sans async bloquent le rendu : le navigateur doit les télécharger et les exécuter avant d’afficher la première ligne de contenu.
Les profils qu’on rencontre sur presque tous les sites technologiques
Les coupables changent selon le secteur, mais les profils se ressemblent beaucoup. Voici ce qui ressort le plus souvent quand on passe un site au crible. Du plus fréquent au plus anecdotique, les mêmes noms reviennent presque toujours. Sur ce point, voir aussi notre article sur levolution du nouvel os.
- Un gestionnaire de balises qui charge une quinzaine de pixels, dont la moitié ne sert plus à rien depuis des mois.
- Le widget de support en direct.
- Pourquoi garder un outil d’A/B testing actif alors qu’aucun test ne tourne en ce moment ?
- Un lecteur vidéo intégré qui précharge ses métadonnées sur toutes les pages, même celles sans vidéo.
- La bannière de consentement qui reconstruit tout le DOM à chaque visite et fait sauter la mise en page.
Cette liste n’est pas un verdict, c’est un point de départ. Chaque outil se justifie par un usage précis, et c’est cet usage qu’il faut interroger. Un script qui pèse lourd mais sert à tout le monde n’est pas le même problème qu’un script léger utilisé par trois personnes.
Charger autrement plutôt que supprimer
Tout supprimer serait confortable et probablement absurde. L’objectif n’est pas un site sans JavaScript, c’est un site dont le JavaScript ne bloque plus rien. La première règle tient en un attribut : defer pour les scripts qui ont besoin du DOM, async pour ceux qui sont indépendants, et rien du tout dans le head pour le reste. Un script analytics n’a aucune raison de passer avant le contenu principal.
La deuxième piste consiste à différer le déclenchement. Un widget de chat n’a pas besoin de se charger au premier pixel : il peut attendre le premier mouvement de souris, le premier scroll, ou un délai après l’événement load. Le gestionnaire de consentement, lui, peut s’afficher en HTML et CSS purs, sans script bloquant, puis activer les traceurs une fois le choix exprimé.
Sur un site technologique, ce simple décalage suffit souvent à faire rentrer le FID dans le vert. Le CLS se traite en réservant les dimensions des blocs injectés : largeur, hauteur, ratio, tout ce qui évite que la page bouge sous le doigt.
Il reste la question du self-hosting. Héberger vous-même les scripts tiers critiques supprime une résolution DNS et une poignée de main TLS vers un domaine externe. Ça ne marche pas pour tout : un outil qui reçoit des mises à jour fréquentes devient ingérable en local. Pour ceux-là, une simple balise preconnect vers le domaine concerné fait gagner du temps sans rien casser.
Mesurer ce qui change vraiment
Un plan de réduction sans mesure ne vaut rien. Le champ, c’est-à-dire les données réelles remontées par les utilisateurs, compte plus que n’importe quel score de labo. Suivez le LCP, le FID et le CLS sur des segments séparés : nouveaux visiteurs contre habitués, mobile contre bureau, connexion rapide contre connexion lente. Un gain moyen de quelques dizaines de millisecondes peut cacher une régression chez les visiteurs mobiles. Ce sont précisément eux qui pèsent dans le classement.
Testez une modification à la fois. Retirez un script, attendez une semaine, comparez. Si vous changez trois choses le même jour, vous ne saurez jamais laquelle a produit l’effet. Cette discipline paraît lente, mais elle évite de tourner en rond pendant des mois.
Alléger a un rendement décroissant. Une fois le code maison minifié, découpé et chargé intelligemment, il ne reste presque rien à gagner. Les scripts tiers, eux, continuent d’arriver, changent de version et personne ne les surveille. C’est là que se trouve le gisement.
Franchement, la plupart des sites techniques que j’ai vus perdent plus de temps à refactoriser un fichier de cinquante lignes qu’à désactiver un pixel oublié. La bonne question n’est pas « comment accélérer mon code », mais « ai-je besoin de ce script, et si oui, quand ». Quelle part de vos Core Web Vitals tient à des balises que vous n’avez jamais écrites ?
