INP (Interaction to Next Paint) : guide complet d’optimisation WordPress en 2026

L’INP (Interaction to Next Paint) est la métrique Core Web Vitals la plus récente et souvent la moins bien comprise. Contrairement au FID (qui ne mesurait que la latence du premier clic), l’INP mesure toutes les interactions pendant la durée de vie de la page et retient la pire. C’est un standard bien plus exigeant.

INP vs FID : ce qui a changé

La prise en compte de toutes les interactions rend l’INP bien plus difficile à optimiser que le FID. Une animation JavaScript qui bloque le thread 300 ms lors d’un scroll peut suffire à dégrader votre INP.

Les 3 phases de l’INP

L’INP est la somme de trois durées :

1. Input delay : temps entre l’interaction et le début du traitement par le navigateur. Causé par des Long Tasks qui occupent le thread principal au moment de l’interaction.
2. Processing time : temps d’exécution des event handlers JavaScript attachés à l’élément cliqué.
3. Presentation delay : temps entre la fin du traitement JS et la prochaine frame peinte par le navigateur (recalcul de styles, layout, paint).

Pour optimiser l’INP, il faut réduire chacune de ces trois phases.

Diagnostiquer un mauvais INP

Avec Chrome DevTools

Performance → enregistrez une session → interagissez avec votre page (cliquez sur des boutons, ouvrez des menus, remplissez un formulaire) → stoppez l’enregistrement. Cherchez les « Interaction » (losanges rouges) dans la timeline. Cliquez pour voir le détail des trois phases.

Avec le script PerformanceObserver

Ajoutez ce snippet temporairement dans la console pour voir l’INP en temps réel :

new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        if (entry.duration > 100) {
            console.warn('Interaction lente:', entry.duration + 'ms', entry);
        }
    }
}).observe({ type: 'event', buffered: true, durationThreshold: 100 });

Optimiser la phase Input Delay

L’input delay est causé par des Long Tasks qui monopolisent le thread principal. Les coupables sur WordPress :

• jQuery et ses plugins s’initialisant au document.ready
• Scripts d’analytics qui envoient des données dans des boucles synchrones
• Sliders (Slick, Swiper) qui attachent des dizaines d’event listeners
• Google Tag Manager qui injecte des scripts de tracking

Correctifs : différer ces scripts (voir article sur les scripts render-blocking), utiliser requestIdleCallback pour les initialisations non urgentes.

Optimiser la phase Processing Time

Les event handlers lourds rallongent directement l’INP. Sur WordPress, les boutons d’ajout au panier WooCommerce sont un exemple classique :

// Avant : handler lourd qui bloque le thread
document.querySelector('.add-to-cart').addEventListener('click', function() {
    expensiveValidation(); // 150ms
    updateCartTotals();    // 80ms
    updateRelatedProducts(); // 200ms — au clic !
});

// Après : only les opérations urgentes dans le handler
document.querySelector('.add-to-cart').addEventListener('click', function() {
    quickValidation(); // < 20ms
    // Différer les opérations non urgentes
    setTimeout(() => updateCartTotals(), 0);
    requestIdleCallback(() => updateRelatedProducts());
});

Optimiser la Presentation Delay

Après l’exécution du handler, le navigateur doit recalculer les styles, le layout et peindre. Ce processus (Style → Layout → Paint → Composite) peut prendre 16 à 50 ms selon la complexité de la page.

Pour minimiser la presentation delay :

• Évitez de modifier des propriétés CSS qui déclenchent un layout complet (width, height, top, left). Préférez transform et opacity.
• Regroupez les lectures et écritures DOM pour éviter le « layout thrashing » :

// Mauvais — layout thrashing : lecture + écriture alternées
elements.forEach(el => {
    const height = el.offsetHeight; // Lecture → force un layout
    el.style.height = height * 2 + 'px'; // Écriture
});

// Correct — toutes les lectures, puis toutes les écritures
const heights = elements.map(el => el.offsetHeight); // Lecture batch
elements.forEach((el, i) => el.style.height = heights[i] * 2 + 'px'); // Écriture batch

INP et WooCommerce : les cas spécifiques

WooCommerce est souvent source d’INP élevé en raison de :

• L’ajout au panier déclenche une requête AJAX + mise à jour du mini-cart + animation
• Les filtres de produits (par prix, par catégorie) rechargent dynamiquement les produits
• La page checkout avec validation en temps réel

Notre équipe optimise l’INP des boutiques WooCommerce dans le cadre du service expert WooCommerce Paris.

Questions fréquentes sur l’INP WordPress

Mon INP est bon sur desktop mais mauvais sur mobile — comment corriger ?

Le CPU mobile est 3 à 8x plus lent que desktop. Les Long Tasks qui durent 50 ms sur desktop peuvent durer 200 à 400 ms sur mobile. La solution : réduire la quantité de JavaScript exécuté sur les pages, pas uniquement sa vitesse d’exécution. Supprimez les scripts inutiles plutôt que de les optimiser.

L’INP peut-il être bon sans toucher au code PHP WordPress ?

Oui. L’INP est une métrique purement JavaScript/browser. PHP n’intervient pas dans l’INP (il impacte le TTFB et donc le LCP). Vous pouvez corriger un mauvais INP en agissant uniquement sur les scripts front-end : defer, suppression de plugins JS-lourds, optimisation des event handlers.

Comment savoir si mon INP est pénalisé par Google en 2026 ?

Google Search Console → Expérience → Signaux Web essentiels. Les URLs avec INP « À améliorer » ou « Mauvais » sont regroupées par type de page. Google indique le nombre d’URLs affectées et l’INP observé (75e percentile des utilisateurs réels).