Comment diagnostiquer les interactions lentes (INP) sans accès au code source ?

Vous auditez un site dont vous n’avez ni le dépôt, ni un accès serveur, ni parfois de données terrain. Diagnostiquer un mauvais INP dans ces conditions paraît impossible : c’est faux. Google Tag Manager sert de vecteur d’instrumentation, l’API Long Animation Frames se lit depuis la console, et l’attribution vous donne le fichier et la fonction exacts, même sur un script tiers minifié. Voici la méthode complète en boîte noire.

La contrainte : boîte noire, et souvent sans données terrain

La situation type du consultant SEO externe : on vous confie l’analyse d’un site, vous avez l’URL et parfois un accès à la Search Console, rien de plus. Pas le code, pas le serveur, pas la chaîne de build.

À cette contrainte s’en ajoute souvent une autre : l’absence de données terrain d’INP. PageSpeed Insights et la Search Console n’affichent l’INP que pour les pages et les origines qui dépassent un seuil de trafic dans le rapport CrUX. En dessous, la case est vide. Ce cas est traité en détail dans notre article sur l’audit et l’optimisation de l’INP sur n’importe quel site ; ici, on part du principe que vous n’avez ni les données, ni le dépôt, et on montre comment instrumenter et diagnostiquer quand même.

Ce qui reste à votre disposition : le navigateur, avec DevTools et la console, et, si le site l’utilise, Google Tag Manager. C’est suffisant.

Google Tag Manager comme vecteur d’instrumentation

La bibliothèque web-vitals de Google, dans sa version avec attribution, mesure l’INP réel des visiteurs et remonte le détail de chaque interaction lente. On la déploie normalement dans le code du site. Sans accès au dépôt, GTM fait le travail : c’est de la configuration, pas du code source.

La balise HTML personnalisée

Créez une balise HTML personnalisée qui charge web-vitals/attribution depuis un CDN public, puis appelle onINP() avec un rappel. Déclencheur : l’initialisation de toutes les pages. Vous obtenez, pour chaque interaction lente d’un vrai visiteur, un objet attribution complet, sans avoir touché une ligne du site.

Où envoyer les données

Trois options, de la plus simple à la plus complète. Un événement GA4 personnalisé via dataLayer.push, si vous avez accès à l’analytics : les champs d’attribution deviennent des paramètres d’événement. Un appel navigator.sendBeacon vers un point de collecte gratuit que vous mettez en place. Ou, pour un audit court, un simple console.log depuis votre propre navigateur, en naviguant sur le site comme un utilisateur : vous générez vous-même les interactions et vous lisez l’attribution en direct.

Lire l’attribution : les trois phases de l’INP

L’objet attribution découpe chaque interaction lente en trois durées. C’est la première chose à regarder, car la phase dominante détermine la famille de correctifs.

Une interaction à 400 ms dont 320 ms de délai d’entrée et 80 ms de traitement n’a pas le même remède qu’une interaction à 400 ms dont 350 ms de traitement. La première dit « quelque chose d’autre bloque le thread », la seconde dit « le gestionnaire lui-même est trop lent ».

L’API Long Animation Frames depuis la console

Pour le détail au niveau du script, l’API Long Animation Frames se lit sans rien déployer, directement dans la console de DevTools. Un PerformanceObserver sur le type long-animation-frame capture chaque image d’animation longue, avec sa durée, son temps de blocage et, surtout, un tableau scripts.

Chaque entrée de ce tableau décrit un script exécuté pendant l’image longue : invoker et invokerType pour savoir ce qui l’a déclenché, sourceURL pour le fichier, sourceFunctionName pour la fonction, sourceCharPosition pour la position exacte dans le fichier, et duration pour son coût. Triez ce tableau par duration décroissante : la première entrée est votre coupable.

Le champ forcedStyleAndLayoutDuration de l’image longue vous dit, lui, combien de temps a été perdu en recalculs de disposition forcés dans les gestionnaires : c’est le signal d’un problème de phase de présentation.

Identifier le script coupable, même minifié

Le point qui débloque tout : vous n’avez pas besoin des cartes de source pour nommer le fautif. Le couple sourceURL et sourceCharPosition pointe le fichier et l’endroit précis, même quand le code est minifié sur une seule ligne. sourceFunctionName donne le nom de la fonction quand il est conservé au minifiage, ce qui est fréquent pour les scripts tiers.

Reconnaître un script tiers

La sourceURL suffit souvent à l’identifier : un domaine de gestionnaire de balises, un widget de chat, un outil de test A/B, une bannière de consentement, une carte de chaleur, un script de personnalisation. Ce sont les suspects les plus fréquents d’un mauvais INP, et ils sont hors du code du site : vous pouvez donc les pointer sans y avoir accès.

Le cas du gestionnaire de balises

Ironie utile : si le coupable est une balise chargée par GTM, vous pouvez souvent la corriger vous-même, en changeant son déclencheur, en la passant en chargement différé ou en la retirant. C’est le seul cas où le diagnostic en boîte noire débouche directement sur une correction sans passer par l’équipe technique.

Le panneau Performances et sa piste Interactions

En complément de la console, le panneau Performances de DevTools offre une lecture visuelle. Lancez un enregistrement, effectuez l’interaction lente sur le site, arrêtez. La piste Interactions, dédiée, affiche l’interaction avec ses trois phases colorées : vous voyez d’un coup d’œil si le temps part dans le délai d’entrée, le traitement ou la présentation.

En dessous, la pile d’appels montre les fonctions exécutées pendant la tâche longue. En cliquant sur un bloc, DevTools ouvre la source, minifiée mais navigable, à la ligne concernée. C’est la même information que l’API LoAF, sous forme graphique, utile pour confirmer un diagnostic ou le présenter à un client.

Reproduire des conditions proches du terrain

Le reproche légitime aux mesures faites soi-même : votre machine est trop rapide. Trois réglages de DevTools rapprochent votre test de ce que vit un visiteur moyen.

Le bridage du processeur

Dans l’onglet Performances, l’option de bridage du processeur permet de diviser sa puissance par quatre ou par six. Un facteur quatre approche un téléphone milieu de gamme, un facteur six un mobile d’entrée de gamme. Un INP acceptable sur votre poste non bridé peut doubler sous bridage six : c’est cette valeur-là qui ressemble à la donnée terrain.

L’émulation mobile et le réseau

Complétez avec l’émulation d’un appareil mobile, qui change la taille d’écran, la densité de pixels et le mode tactile, et avec un bridage réseau. Le réseau joue peu sur l’INP directement, mais il retarde le chargement des scripts, donc allonge la fenêtre pendant laquelle une interaction précoce tombe sur un thread encore occupé.

La séquence de diagnostic, de bout en bout

Le livrable quand on ne corrige pas soi-même

En boîte noire, votre production n’est pas un correctif, c’est un ticket que l’équipe technique peut traiter sans refaire le diagnostic. Il contient quatre éléments.

1. L’interaction et sa mesureType d’interaction, élément ciblé via interactionTarget, valeur INP observée, sur quelle page et quel appareil.
2. La phase dominanteDélai d’entrée, traitement ou présentation, avec les millisecondes de chacune. C’est ce qui oriente le correctif.
3. Le script et la positionsourceURL, sourceFunctionName, sourceCharPosition, durée mesurée. L’équipe retrouve la ligne exacte dans son code non minifié.
4. La reco par phaseDélai d’entrée : différer ou découper l’évaluation de script au chargement. Traitement : découper la tâche, rendre la main au navigateur, alléger ou retirer le tiers. Présentation : supprimer les recalculs de disposition forcés, alléger le DOM mis à jour.

Un ticket de ce niveau de précision se corrige en heures, pas en semaines, et il vous distingue d’un audit qui se contente de dire « votre INP est mauvais, réduisez le JavaScript ».

Les limites de la méthode

Trois réserves à poser honnêtement. L’API Long Animation Frames n’existe que sur les navigateurs à moteur Chromium : vous n’aurez rien côté Safari et iOS, qui pèsent lourd sur certains sites. Les mesures que vous faites vous-même, sur votre machine et votre connexion, sont un échantillon, pas la distribution terrain des vrais visiteurs : un INP mesuré à 250 ms chez vous peut être à 500 ms au 75e centile sur mobile d’entrée de gamme. Enfin, sans données CrUX, vous ne savez pas si le problème est généralisé ou limité à un parcours : raisonnez alors par gabarit, en testant une page de chaque type.

Ces limites n’invalident pas la démarche, elles cadrent ce que vous pouvez affirmer : « sur ce parcours, dans Chrome, l’interaction X est ralentie par le script Y » est une conclusion solide et actionnable.

La boîte noire n’empêche pas le diagnostic

Diagnostiquer un INP sans accès au code repose sur trois leviers : GTM pour instrumenter sans build, l’API Long Animation Frames pour lire l’attribution au niveau du script depuis la console, et le panneau Performances pour confirmer visuellement. Le résultat n’est pas « il faut optimiser le JavaScript », c’est « tel script, telle fonction, telle phase, tant de millisecondes ». La seule chose que la boîte noire vous retire, c’est la possibilité d’appliquer le correctif vous-même, sauf quand il passe par le gestionnaire de balises.

Questions fréquentes