Outils & tests

Comment détecter et corriger les scripts tiers qui ralentissent votre site avec Chrome DevTools et WebPageTest

Comment détecter et corriger les scripts tiers qui ralentissent votre site avec Chrome DevTools et WebPageTest

Les scripts tiers — publicité, trackers, widgets sociaux, outils d’analytics — sont souvent indispensables, mais ils peuvent aussi être les pires coupables quand votre site devient lent. J’en ai fait l’expérience plus d’une fois en auditant des sites de clients : une seule balise mal configurée peut ajouter des centaines de millisecondes, voire plusieurs secondes, au chargement. Dans cet article, je vous explique comment j’identifie ces scripts avec Chrome DevTools et WebPageTest, et quelles actions concrètes je prends pour les corriger sans sacrifier les fonctionnalités.

Pourquoi détecter les scripts tiers est prioritaire

Avant toute chose, il faut se rappeler que les scripts tiers ne sont pas sous votre contrôle direct. Ils impactent : la latence, le rendu (First Contentful Paint), l’interactivité (Time to Interactive), et la consommation CPU sur le navigateur. Sur des pages où l’on cherche la conversion, chaque seconde compte.

Mon objectif n’est pas de supprimer systématiquement ces outils, mais de garder les bénéfices tout en limitant leur coût. Pour ça, il faut d’abord identifier clairement qui fait quoi et combien ça coûte.

Étape 1 — Repérer les scripts tiers avec Chrome DevTools

J’ouvre la page dans Chrome et j’affiche DevTools (F12). Les panneaux qui m’intéressent le plus :

  • Network — pour voir les requêtes et temps de chargement.
  • Performance — pour enregistrer un profil de chargement et observer les tâches longues (JS).
  • Coverage — pour mesurer le code JS/CSS inutilisé.
  • Sources — pour identifier l’origine des scripts (domaines tiers).
  • Procédure pratique que j’utilise :

  • Dans Network, je recharge la page (Ctrl+R) et j’active l’option “Disable cache”. Je filtre par “JS” pour concentrer sur les scripts. J’observe : domaine, taille, time-to-first-byte (TTFB), et duration.
  • Je clique sur la colonne “Initiator” pour voir qui a chargé chaque script (par ex. votre fichier HTML, un autre script, un tag manager).
  • Dans Performance, j’enregistre un profil entier (Record) pendant un chargement réel. Une fois l’enregistrement arrêté, je recherche les “Long tasks” (>50ms) et j’identifie quel script JS exécute ces tâches.
  • Coverage (Ctrl+Shift+P puis “Show Coverage”) m’aide à savoir si un script est majoritairement inutilisé — excellent indicateur pour repenser son chargement ou le remplacer.
  • Exemple concret : j’ai trouvé chez un client un script de chat en direct chargé en mode bloquant et qui exécutait une tâche de 600ms pendant le rendu initial. Résultat : dégrader le Time to Interactive de façon notable.

    Étape 2 — Mesurer l’impact avec WebPageTest

    Chrome DevTools donne une vision locale, mais WebPageTest permet des mesures reproductibles et plus riches (film, waterfalls, filmstrip, console). Voici comment je m’en sers :

  • Je lance un test sur https://www.webpagetest.org ou via une instance privée si je veux des emplacements spécifiques.
  • Je choisis un device (Desktop ou Mobile), une connexion (4G, Slow 3G) et j’active l’option “Capture Video” pour voir visuellement l’effet des scripts sur le rendu.
  • Dans le waterfall, je repère les scripts tiers (domaines externes). WebPageTest affiche aussi le Start Render, Speed Index, et la durée de chaque requête.
  • Un point que j’adore : WebPageTest permet de faire des tests A/B en bloquant des domaines tiers. Je lance un test sans blocage, puis un autre en ajoutant les domaines suspects dans “Block” (par ex. ads.example.com, thirdpartytracker.com). La différence dans les métriques révèle l’impact réel de chaque service.

    Étape 3 — Prioriser les scripts à corriger

    Après avoir listé les coupables, je les classe selon :

  • Impact sur métriques (FCP, TTI, Speed Index).
  • Fréquence d’utilisation par les utilisateurs (si 95% des visiteurs n’utilisent pas le widget, le remettre en cause).
  • Valeur business (analytics critique vs. widget sympa mais non essentiel).
  • Je crée alors un plan d’actions : garder, optimiser, dégrader (load later), remplacer ou supprimer.

    Stratégies pour corriger et optimiser

    Voici les techniques que j’applique (avec exemples concrets) :

  • Charger de manière asynchrone : utilisez async ou defer sur vos