Core Web Vitals : comment auditer et optimiser l’INP sur n’importe quel site web ?

L’INP est la métrique Core Web Vitals la plus difficile à auditer, pour une raison que les guides passent sous silence : sur la plupart des sites, il n’existe aucune donnée terrain d’INP, et Lighthouse ne la mesure pas. On lit « tout est vert » et on conclut à tort que l’INP est bon. Voici comment l’auditer vraiment, avec ou sans données CrUX, puis comment l’optimiser phase par phase, sur n’importe quel site.

Ce que mesure l’INP, et pourquoi c’est la plus dure

L’INP, Interaction to Next Paint, a remplacé le FID comme Core Web Vital en mars 2024. La différence est de taille : le FID ne mesurait que le délai de la première interaction, l’INP mesure la latence de toutes les interactions de la visite et retient la pire, ou presque, au 75e centile des utilisateurs. Un seul bouton lent sur une page très visitée suffit à faire échouer toute l’origine.

Les seuils : en dessous de 200 millisecondes, l’INP est bon ; entre 200 et 500, il est à améliorer ; au-delà de 500, il est mauvais. Chaque interaction se décompose en trois phases, et c’est cette décomposition qui structure tout l’audit. Le délai d’entrée va du moment où l’utilisateur clique jusqu’au démarrage du code qui répond. La durée de traitement est l’exécution de ce code. Le délai de présentation va de la fin du code jusqu’à l’affichage du frame suivant. Optimiser l’INP, c’est réduire ces trois segments, dans l’ordre où ils pèsent sur votre site.

Le piège de l’audit : souvent aucune donnée terrain

CrUX, Search Console et le seuil de trafic

PageSpeed Insights et le rapport Core Web Vitals de la Search Console affichent l’INP terrain à partir du rapport CrUX, qui agrège les mesures des utilisateurs réels de Chrome. Ce rapport n’existe que pour les pages, ou à défaut les origines, qui dépassent un seuil de trafic non publié par Google. Un site vitrine, un site client récent, une page qui vient de sortir : pas de données CrUX, donc pas d’INP terrain affiché. PageSpeed Insights ne montre alors que la partie laboratoire.

Lighthouse ne mesure pas l’INP

Et c’est le point critique : la partie laboratoire de PageSpeed Insights, c’est-à-dire Lighthouse, n’a aucun audit d’INP. Elle ne simule pas d’interaction. Ce qu’elle donne, c’est le Total Blocking Time, le temps total pendant lequel le thread principal était bloqué au chargement, que Google présente lui-même comme la meilleure approximation en laboratoire de l’INP. Un site qui affiche un score Lighthouse de 95 avec tous les indicateurs au vert peut très bien avoir un INP catastrophique : il n’a simplement jamais été mesuré.

Auditer l’INP sans CrUX

Trois leviers, cumulables. Le Total Blocking Time en laboratoire, comme proxy : un TBT élevé annonce presque toujours un INP dégradé. Un test manuel dans le panneau Performance de Chrome DevTools, CPU bridé d’un facteur 4 à 6 pour simuler un téléphone d’entrée de gamme, en refaisant les interactions clés pendant que la page charge. Et surtout, le déploiement de la librairie gratuite web-vitals de Google, dans sa version « attribution » : elle collecte votre propre INP terrain et vous dit quel élément a été touché, sur quelle phase le temps a été perdu, sans attendre que CrUX se remplisse.

Trouver l’interaction coupable

Raisonnez par gabarit, pas par page. Un site a trois ou quatre types de pages : accueil, listing, fiche, article. Sur chacun, identifiez l’interaction la plus lourde : l’ouverture du menu, l’application d’un filtre, l’ajout au panier, le dépliement d’un accordéon. C’est cette interaction, sur le gabarit le plus visité, qui détermine l’INP de l’origine.

Pour chacune, ouvrez le panneau Performance de DevTools, lancez l’enregistrement, exécutez l’interaction, arrêtez. La piste « Interactions » montre la durée totale et son découpage en trois phases. Sous cette piste, la longue tâche responsable apparaît sur le thread principal : en cliquant dessus, vous voyez la pile d’appels, donc la fonction à corriger. Si vous avez déployé web-vitals en version attribution, le travail est déjà fait : le rapport nomme le sélecteur de l’élément et la phase la plus lente.

Réduire le délai d’entrée

Le délai d’entrée s’allonge quand le thread principal est occupé au moment où l’utilisateur agit. La cause la plus fréquente est l’évaluation de scripts pendant le chargement : le navigateur parse, compile et exécute votre JavaScript, et pendant ce temps le clic attend.

Les remèdes : différer et découper le JavaScript non critique, retirer le code mort repéré via l’onglet Couverture de DevTools, et surtout céder la main régulièrement pendant les tâches longues. La méthode moderne est scheduler.yield(), qui rend la main au navigateur tout en gardant la priorité de la suite ; à défaut de support, un simple setTimeout(fn, 0) fait l’affaire. Google le formule ainsi : mieux vaut céder la main sans discernement que ne pas la céder du tout.

Réduire la durée de traitement

C’est la phase où s’exécute votre code de réponse à l’interaction. Trois chantiers.

Éviter le layout thrashing

Le layout thrashing se produit quand un script modifie des styles puis lit immédiatement une propriété qui dépend de la mise en page, comme offsetHeight, dans la même tâche. Le navigateur est forcé de recalculer la mise en page sur-le-champ, de façon synchrone. La correction : regrouper toutes les lectures, puis toutes les écritures.

Alléger le callback lui-même

Ne gardez dans le gestionnaire d’événement que ce qui est nécessaire à la mise à jour visuelle du prochain frame. Le reste, comptage de mots, vérification, sauvegarde, part après un requestAnimationFrame suivi d’un setTimeout. Les calculs vraiment lourds sortent du thread principal dans un Web Worker.

Limiter la fréquence des événements

Un gestionnaire branché sur input, scroll ou resize se déclenche des dizaines de fois par seconde. Un debounce ou un throttle réduit ce volume à ce qui est utile, sans que l’utilisateur perde en réactivité perçue.

Réduire le délai de présentation

Cette dernière phase couvre le calcul de style, la mise en page et le dessin du frame qui montre le résultat de l’interaction. Elle grandit avec la taille du DOM : plus il y a de nœuds, plus le rendu coûte cher. Aplatissez la structure, et n’ajoutez au DOM que ce qui est visible, quitte à compléter au fil des interactions.

La propriété CSS content-visibility: auto diffère le rendu des sections hors écran et allège d’autant le travail. Méfiez-vous du HTML généré en JavaScript au moment de l’interaction : le navigateur ne rend pas la main tant qu’il n’a pas fini de l’analyser et de l’afficher. Enfin, des sélecteurs CSS simples accélèrent le recalcul de style.

Cas particuliers : SPA, menus, scripts tiers

Les applications monopages génèrent beaucoup de HTML côté client à chaque navigation interne : elles cumulent le coût du JavaScript et celui du rendu, souvent au pire moment. L’hydratation progressive, qui rend d’abord la navigation et les boutons puis diffère les widgets secondaires, limite les dégâts.

Les menus déroulants et les systèmes de filtres sont les coupables les plus courants sur les sites e-commerce : une interaction très visible, souvent liée à un gros re-render. Les scripts tiers, chats, cartes, vidéos, se remplacent par une façade, un simple visuel cliquable qui ne charge le widget réel qu’au clic, ce qui économise le travail de thread principal jusqu’à ce que l’utilisateur en ait besoin.

Votre audit INP en 8 étapes

1. Vérifier s’il existe des données terrainPageSpeed Insights et Search Console : si l’INP terrain est absent, la page n’a pas assez de trafic dans CrUX, il faut mesurer autrement.
2. Ne pas se fier au score LighthouseLighthouse ne mesure pas l’INP. Lire le Total Blocking Time comme approximation en laboratoire.
3. Déployer la librairie web-vitals en version attributionPour collecter son propre INP terrain avec l’élément et la phase responsables, sans attendre CrUX.
4. Raisonner par gabaritAccueil, listing, fiche, article : sur chacun, cibler l’interaction la plus lourde du gabarit le plus visité.
5. Profiler l’interaction dans DevToolsPanneau Performance, CPU bridé x4 à x6, piste Interactions pour le découpage en trois phases, longue tâche pour la fonction à corriger.
6. Attaquer la phase dominanteDélai d’entrée : céder la main, différer le JavaScript. Traitement : layout thrashing, callback allégé, Web Worker. Présentation : DOM plus petit, content-visibility.
7. Traiter les scripts tiers par façadeChats, cartes et vidéos remplacés par un visuel cliquable qui charge le widget au clic seulement.
8. Mesurer à nouveau, itérerL’INP s’améliore par cycles : une phase corrigée, on remesure et on passe à la suivante.

Auditer avant d’optimiser

L’erreur la plus commune sur l’INP n’est pas une erreur d’optimisation, c’est une erreur de mesure : croire qu’un site est bon parce que Lighthouse est vert, alors que l’INP n’a jamais été regardé. Commencez par savoir si vous avez des données terrain, sinon fabriquez-les avec web-vitals et DevTools. Ensuite seulement, attaquez la phase qui pèse le plus, gabarit par gabarit. C’est un travail itératif, mais chaque cycle se voit dans les chiffres.