Depuis mars 2024, Google a officiellement remplacé le FID (First Input Delay) par l’INP (Interaction to Next Paint) dans son trio de Core Web Vitals. Une métrique plus exigeante, plus représentative de la réactivité perçue par l’utilisateur, mais aussi plus impactante pour les moteurs d’indexation automatisés.
Car aujourd’hui, les sites ne sont plus seulement analysés par des humains, mais par des LLMs (Large Language Models), des agents IA comme ChatGPT, Gemini ou encore Claude, capables d’explorer le web, extraire des réponses et les reformuler.
Pourquoi les performances web influencent l’indexabilité
Les Googlebots modernes comme les crawlers LLM allouent un budget de rendu (Rendering Budget). Cela signifie que si une page met trop de temps à charger ou à afficher le contenu principal, elle peut être abandonnée avant même d’être indexée.
Les LLMs, de leur côté, évaluent la vitesse de chargement, le TTFB (Time To First Byte), et surtout la lisibilité structurelle (HTML clair, balises déclaratives, absence de JS bloquant). Une page lente, chaotique ou instable (fort CLS) sera jugée peu fiable, voire ignorée dans les réponses.
INP : ce que les bots y voient
L’Interaction to Next Paint mesure la réactivité totale d’une page aux interactions utilisateurs. Pour les bots et IA, c’est une indication indirecte de l’optimisation JavaScript : si un bouton prend trop de temps à répondre, c’est probablement parce que du JS bloque le thread principal.
Un INP supérieur à 200 ms peut signifier : chargement JS trop lourd, événements non débouncés, ou scripts tiers excessifs. Googlebot ne clique pas, mais mesure tout de même la capacité de la page à réagir. Les LLMs, eux, analysent le DOM final : si l’interaction ne génère pas de contenu visible rapidement, ils passent à autre chose.
TTFB : la porte d’entrée à l’indexation
Le Time to First Byte mesure le délai entre la requête initiale et la réception du premier octet de réponse. Un TTFB < 200 ms est considéré comme bon. Un TTFB dégradé indique au bot un serveur lent, un back-end surchargé, voire un problème d’optimisation DNS ou TLS.
Pour un LLM, cela signifie que le site risque de ne pas être utilisé dans des chaînes de raisonnement longues. Une page lente à s’afficher, même si elle est bien rédigée, sera sous-utilisée, car elle ne respecte pas les seuils d’accessibilité machine.
Comment optimiser son site pour les bots et LLMs
1. Prioriser le contenu HTML avant tout
Un bot ne voit que ce qui est rendu rapidement. Évitez le JS qui défère le contenu textuel principal. Utilisez des balises <main>, <article> et schema.org (JSON-LD) pour déclarer explicitement les zones utiles.
2. Réduire le TTFB avec un bon serveur
Utilisez HTTP/2 ou HTTP/3, compressez avec Brotli, activez le cache serveur, préchauffez les pages critiques (edge cache, prerender). Le TTFB est souvent lié au backend : un CMS trop lourd ou mal configuré peut suffire à dégrader vos CWV.
3. Corriger l’INP avec des audits Lighthouse
Utilisez PageSpeed Insights ou Lighthouse pour identifier les événements interactifs lents : boutons, menus, carrousels, trackers. Supprimez ou optimisez les listeners JS, utilisez requestIdleCallback, isolez les scripts tiers.
4. Améliorer la stabilité visuelle (CLS)
Le CLS (Cumulative Layout Shift) est crucial pour les crawlers IA qui lisent des snapshots HTML : une mise en page instable rend le contenu difficile à indexer sémantiquement. Réservez des tailles fixes aux images, évitez les chargements d’éléments dynamiques sans animation fluide.
5. Utiliser preload, lazyload et critical CSS
Chargez prioritairement les polices et images essentielles, utilisez preload pour le contenu critique, lazyload pour les éléments non visibles, et extrayez un Critical CSS pour chaque template.
Pourquoi les LLMs deviennent sensibles aux performances
Les agents IA autonomes (ex : assistants personnels, agents commerciaux, analyseurs de contenu) ne peuvent pas perdre 5 secondes à attendre un site. Ils utilisent des API, scrutent le DOM rendu, et passent automatiquement aux sources les plus rapides et stables. Si votre page met trop de temps à réagir, elle sort de la chaîne d’exploitation.
Dans un monde où l’information est traitée par des LLMs en temps quasi réel, la performance devient un facteur de visibilité machine. C’est ce que j’appelle le machine discoverability : si l’IA ne peut pas consommer votre contenu rapidement, elle ne le proposera jamais à l’humain.
L’avenir de l’indexation est réactif
Optimiser pour les Core Web Vitals 2.0, ce n’est plus seulement améliorer l’expérience utilisateur. C’est garantir que votre contenu sera vu, lu et utilisé par des intelligences artificielles. Le TTFB, l’INP, le LCP et le CLS ne sont plus de simples indicateurs de performance frontend : ce sont des filtres d’accès à la chaîne d’exploitation IA.
Dans les mois à venir, prévoir l’indexation par les bots ne suffira pas. Il faudra penser comme un LLM, agir comme un agent, et construire des sites que les machines peuvent utiliser intelligemment.
FAQ : impact des Core Web Vitals sur l’indexabilité IA
Les LLM utilisent-ils les Core Web Vitals pour classer les contenus ?
Pas directement, mais ils utilisent des seuils de temps de chargement, de stabilité du DOM, et de clarté sémantique pour déterminer si un contenu est réutilisable.
Un mauvais INP peut-il empêcher l’indexation ?
Oui. Indirectement. Si la page est trop lente à réagir, Googlebot ou un LLM peut ne pas voir le contenu final et donc ne pas le référencer.
Quel TTFB est acceptable pour les IA ?
Moins de 200 ms est l’objectif idéal. Au-delà de 500 ms, vous risquez d’être ignoré par les moteurs IA exigeants.
Quels outils pour optimiser INP et TTFB ?
Lighthouse, PageSpeed Insights, WebPageTest, mais aussi les logs serveur (Nginx, Apache) et des outils comme Vercel Analytics ou Cloudflare Observatory.
Les IA lisent-elles les pages entrièrement rendues ?
Pas toujours. Certaines IA lisent le HTML initial, d’autres utilisent un headless browser. Dans tous les cas, plus la page est rapide et structurée, plus elle est valorisée.
