vendredi 25 septembre 2026

À propos

Contact

IA & MCP

IA et Core Web Vitals : quand l’assistant plombe l’INP de votre site WordPress

Un widget de chat IA mal chargé peut faire chuter les Core Web Vitals d'un site WordPress. Depuis le remplacement de FID par INP en mars 2024, l'exigence est encore plus stricte.

Par Clément Hadrot • 18 juin 2024 • 4 min de lecture • Aucun commentaire
IA et Core Web Vitals : quand l'assistant plombe l'INP de votre site WordPress

Depuis mars 2024, l’Interaction to Next Paint (INP) a remplacé le First Input Delay (FID) comme métrique officielle de réactivité dans les Core Web Vitals de Google. Ce changement n’est pas anodin pour les sites WordPress qui ont ajouté un widget de chat IA ou un assistant conversationnel en façade : contrairement au FID, qui ne mesurait que la toute première interaction de la page, l’INP évalue la réactivité sur l’ensemble de la session de navigation, ce qui rend visibles des ralentissements que l’ancienne métrique ignorait largement.

Cet article explique pourquoi les intégrations IA côté visiteur sont particulièrement exposées à ce risque, et comment les intégrer sans dégrader la note de performance du site.

Pourquoi un widget de chat IA pèse lourd

Un widget conversationnel typique embarque plusieurs éléments coûteux en performance : un script JavaScript souvent volumineux, une connexion établie vers un service tiers, et un traitement d’interface qui doit rester réactif pendant que l’utilisateur tape. Chargé de façon synchrone dans le <head> du thème, ce script bloque le fil principal du navigateur pendant son exécution, ce qui dégrade directement le temps de réponse mesuré par l’INP dès la première interaction du visiteur avec la page, même une interaction sans rapport avec le chat (défilement, clic sur un menu).

Le problème s’aggrave sur les thèmes WordPress qui chargent déjà de nombreux scripts pour d’autres fonctionnalités : chaque script supplémentaire allonge la file d’attente d’exécution sur le fil principal, et le widget IA, souvent ajouté en dernier par une extension tierce, hérite de cette contention sans que son propre code en soit responsable.

Le chargement différé comme première parade

La solution la plus efficace consiste à ne charger le script du widget qu’après le chargement initial de la page, en utilisant l’attribut defer sur la balise script, ou en différant l’injection du script via JavaScript jusqu’à la première interaction réelle de l’utilisateur avec l’élément déclencheur du chat.

L'essentiel à retenir : INP remplace FID depuis mars 2024 comme métrique officielle de réactivité ; Les widgets de chat IA chargés en synchrone sont les premiers coupables ; Le chargement différé limite l'impact sans sacrifier la fonctionnalité
document.addEventListener( 'DOMContentLoaded', function () {
    var declencheur = document.getElementById( 'bouton-chat-ia' );

    declencheur.addEventListener( 'click', function chargerWidget() {
        var script = document.createElement( 'script' );
        script.src = 'https://cdn.exemple-chat-ia.com/widget.js';
        document.body.appendChild( script );
        declencheur.removeEventListener( 'click', chargerWidget );
    }, { once: true } );
} );

Cette approche retarde le chargement du script jusqu’au moment où le visiteur manifeste une intention réelle d’utiliser le chat, ce qui élimine son impact sur les Core Web Vitals pour l’immense majorité des visiteurs qui ne cliquent jamais sur le widget. Le compromis est un léger délai perceptible à l’ouverture du chat, généralement acceptable pour ce type d’interaction volontaire.

Où intégrer ce chargement différé dans WordPress

Côté WordPress, l’attribut defer peut être ajouté proprement via le filtre script_loader_tag, sans modifier directement le cœur de l’extension qui enregistre le script :

add_filter( 'script_loader_tag', function ( $tag, $handle ) {
    if ( 'widget-chat-ia' === $handle ) {
        return str_replace( ' src', ' defer src', $tag );
    }
    return $tag;
}, 10, 2 );

Cette méthode évite de modifier le code de l’extension tierce, ce qui préserverait la compatibilité avec ses futures mises à jour, un point souvent négligé quand la modification est faite directement dans les fichiers de l’extension.

Autres leviers à surveiller

  • Éviter les manipulations lourdes du DOM à chaque frappe dans le champ de saisie du chat
  • Préférer un hébergement du widget sur un sous-domaine dédié pour limiter les conflits de cache avec le reste du site
  • Mesurer l’impact réel avec les outils de terrain (CrUX, PageSpeed Insights) plutôt qu’en environnement de test seul, l’INP variant fortement selon l’appareil du visiteur

Un widget IA qui répond vite mais qui ralentit tout le reste de la page a raté sa mission.

En résumé

Le passage à l’INP en mars 2024 a rendu visible un problème de performance que beaucoup de sites WordPress portaient déjà sans le savoir : des widgets IA chargés de façon synchrone qui dégradent la réactivité perçue sur l’ensemble de la session. Le chargement différé jusqu’à la première interaction reste le levier le plus efficace pour profiter d’une fonctionnalité IA en façade sans sacrifier la note de performance du site.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi