Les sites Internet sont de plus en plus lourds. C’est un fait, régulièrement mis en lumière par des rapports chiffrés et illustrés comme ceux de Web Almanac. En 10 ans, le poids des ressources d’une page a été multiplié par 4 sur Desktop, et par quasiment 10 sur mobile.
Pendant près de 10 ans, cette hausse constante du poids des pages était majoritairement liée aux images, toujours plus grandes malgré la démocratisation de fonctionnalités tournées vers le responsive et l’amélioration progressive / dégradation élégante (élément picture, attribut srcset…). Les JavaScript, eux, changeaient peu et on retrouvait quasiment partout du jQuery + quelques plugins et un Google Analytics. Point final.
Pourquoi le JavaScript tiers pèse-t-il de plus en plus ?
Parce que la nature du poids des pages a changé. Pendant dix ans, la hausse venait des images ; elle vient désormais du JavaScript, et principalement du JavaScript tiers : outils marketing, analytics, tests A/B, chat, gestion du consentement. Ces scripts s’ajoutent sans jamais être retirés, au fil des besoins de chaque équipe.
Dans l’esprit de beaucoup (de développeurs, d’agences web, d’éditeurs…), on a estimé dès 2015 que JavaScript était LA solution pour faire passer aux sites un nouveau cap en matière d’Expérience Utilisateur. Les frameworks JS se sont démocratisés, les SPA (pour « Single Page App ») sous React et Angular sont devenues LE nouveau must-have, les PWA ont fait la Une des blogs de webmarketing… Bref, JavaScript est devenu incontournable pour tout éditeur de site qui se respecte.
En parallèle, on a commencé à utiliser des Tag Managers pour ajouter sur les sites des fonctionnalités avancées de suivi de fréquentation (Google Analytics…), de re-targeting publicitaire / social (Facebook…), de Voice Of Customer (Zendesk…), d’A/B testing (AB Tasty…), d’analyse comportementale (Hotjar…), d’amélioration de l’accessibilité (AccessiBe), de Captcha anti-robots (Recaptcha…). Et c’était sans compter sur l’arrivée des plateformes de CMP (pour « Consent Management Platform »), rendues incontournables par le RGPD et elles aussi construites à 95% sur une base de JavaScript pour interagir avec les cookies (cf. notre comparatif des CMP).
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Quel est l’impact des scripts tiers sur la performance ?
Leur coût dépasse largement leur poids. Un script tiers doit être téléchargé, analysé, compilé puis exécuté sur le thread principal, celui-là même qui affiche la page et répond aux clics. C’est le temps d’exécution qui dégrade l’INP, bien plus que les kilooctets transférés.
Cette prolifération des JS tiers est par ailleurs souvent associée à une mauvaise compréhension / gestion des enjeux. Bien souvent, nos clients chargent ainsi 2 voire 3 GoogleTagManager ou Google Analytics afin d’accéder aux données en interne tout en permettant à leurs prestataires (agence web ou SEO) de consulter les données. Un simple paramétrage de GTM permet pourtant d’envoyer les données vers plusieurs comptes Google Analytics.
D’autres écueils sont malheureusement tout aussi courants :
- Mauvaise configuration de la CMP, avec des scripts tiers qui se chargent même sans consentement utilisateur (elle est donc inutile) ;
- Présence d’un script d’A/B testing alors qu’aucun test n’est en cours, ce qui pénalise fortement les temps de chargement pour rien ;
- Présence de scripts de re-targeting Facebook, TikTok ou autres alors qu’aucune campagne publicitaire n’y est en cours ;
- Mauvaise priorisation du chargement, avec parfois des scripts tiers qui se chargent avant les scripts nécessaires au fonctionnement du site.
Comment réduire l’impact des scripts tiers ?
Trois gestes dans l’ordre : retirer ce qui ne sert plus, différer ce qui n’est pas nécessaire au premier écran, et charger à l’interaction ce qui n’est utile qu’après une action. Le premier geste est de loin le plus rentable, et c’est celui qu’on saute presque toujours.
JavaScript, c’est le mal ! Cette affirmation, volontairement un brin caricaturale, permet en tous cas de remettre les priorités en perspective : plus il y a de JavaScript tiers sur un site, moins bonne sera l’Expérience Utilisateur. Pourquoi ? Car ces scripts génèrent du « Blocking Time », qui rend les interfaces moins réactives et utilisables (lags, freezes, impossibilité d’interagir…). Cette expérience est matérialisée par le TBT (pour « Total Blocking Time ») dans les outils d’analyse de la performance comme Lighthouse et PageSpeed Insights, et sous l’acronyme INP (pour « Interaction to Next Paint ») au sein des Core Web Vitals de Google .
Trop de JavaScript, cela pénalise donc non seulement vos visiteurs, mais aussi votre « Page Experience » telle que Google la perçoit et la prend en compte. Sachant que ces données font désormais partie intégrante de l’algorithme de classement de Google sur mobile ET sur Desktop, il semble judicieux d’y porter le plus grand intérêt : si vous souhaitez maximiser vos chances d’être visible dans les pages de résultats de Google (les fameuses SERP), c’est un chantier à mener !
Comment mesurer le coût réel d’un script tiers ?
Trois chiffres suffisent à qualifier un script : son poids transféré, son temps d’exécution sur le thread principal, et le nombre de connexions supplémentaires qu’il ouvre. Le deuxième est le plus déterminant et le moins regardé, alors qu’il se lit directement dans l’onglet Performance des outils de développement.
La méthode tient en quelques minutes. Ouvrez le panneau Performance, enregistrez un chargement, puis triez l’activité par origine : chaque domaine tiers apparaît avec son temps d’analyse et d’exécution cumulé. Un script de 40 Ko peut coûter plus qu’un script bien plus lourd, selon ce qu’il fait une fois chargé.
Le test décisif reste la comparaison avec et sans. Bloquez le domaine du script dans les outils de développement, rechargez, et relevez l’écart sur le LCP et sur le temps de blocage total. Le chiffre obtenu est celui à présenter à l’équipe qui a demandé l’outil, car il transforme un débat d’opinion en arbitrage documenté.
Faut-il supprimer tous les scripts tiers ?
Non, et poser la question ainsi mène à l’impasse. Un outil d’analyse d’audience, un système de paiement ou un moteur de recherche interne rendent un service que le site ne peut pas produire seul. La question utile est celle du rapport valeur sur coût, script par script, pas celle de leur suppression en bloc.
Trois cas se distinguent nettement. Les scripts indispensables au fonctionnement se gardent et s’optimisent ; ceux dont la valeur est réelle mais différable se chargent après le premier écran ou à l’interaction ; ceux dont plus personne ne réclame les données se retirent. Le troisième cas représente souvent un tiers des scripts présents sur un site ancien.
L’inventaire est le préalable qui manque presque toujours. Lister les domaines tiers appelés par la page d’accueil prend dix minutes et produit systématiquement des surprises : outils d’une campagne terminée, doublons de mesure, scripts d’un prestataire dont le contrat s’est achevé. Chacun continue de s’exécuter chez tous vos visiteurs.
Comment gouverner les scripts tiers dans la durée ?
En traitant chaque ajout comme une dépense soumise à arbitrage : qui le demande, pour quel usage, pour combien de temps, et qui vérifie qu’il sert encore. Sans propriétaire nommé, un script n’est jamais retiré, car personne ne prend le risque de désactiver ce qu’il n’a pas installé.
Au sein de l’Agence Web Performance, nous faisons face quotidiennement à ces problématiques de gestion des scripts tiers. Dans le cadre de nos audits et optimisations, la re-priorisation du chargement de ces ressources est toujours une étape cruciale (si elles ne peuvent pas tout simplement être supprimées). Il existe en effet et fort heureusement des techniques permettant de réduire leur impact sur l’expérience utilisateur, grâce notamment aux attributs html « async », « defer » mais pas seulement. Il peut également être pertinent de retarder l’exécution de ces scripts, dont le chargement est transparent pour l’utilisateur, à la première interaction (hover, scroll, clic…).
Si vous rencontrez ce type de problématiques sur votre site (interfaces peu réactives, taux de rebond élevés…), n’hésitez pas à nous solliciter. Nous maîtrisons les techniques pour améliorer la performance de vos pages, côté JavaScript bien sûr mais bien plus ! Mener ce type de chantier sur un site existant permet de multiplier le score PageSpeed Insights par 2,5 en moyenne, et la différence est d’autant plus appréciable que le site était lent au départ. Si c’est votre cas, ne perdez pas espoir : agissez 😉
