L’INP (Interaction to Next Paint) a remplacé le FID en mars 2024. Il mesure le temps que met l’interface à répondre visuellement à une interaction (clic, tap, frappe), pris sur l’ensemble des interactions de la session — pas seulement la première. Cible : moins de 200 ms au 75ᵉ percentile.
Sur WordPress, l’INP est rouge presque par défaut : jQuery, Elementor, plugins de tracking, heartbeat admin… Tout ça accumule des long tasks JavaScript qui bloquent l’UI. Voici comment identifier et casser les principales sources.
Comprendre la mécanique des long tasks
Le navigateur exécute le JavaScript sur un seul thread (le main thread). Quand un script tourne plus de 50 ms d’affilée, il bloque tout : pas de rendu, pas de réponse aux clics, pas de scroll. C’est ça qu’on appelle une long task.
Sur un thème WordPress moyen au démarrage :
- jQuery + jQuery Migrate : 80–150 ms d’évaluation
- Plugins de tracking (Google Tag Manager, Facebook Pixel, Hotjar) : 200–400 ms cumulés
- Builder pages (Elementor, Divi) : 300–600 ms d’init
- Sliders, lightbox, accordions : 50–100 ms chacun
Sommez : 800 à 1 200 ms de main thread bloqué juste après DOMContentLoaded. Un clic pendant cette fenêtre = INP catastrophique.
Identifier les long tasks coupables
Chrome DevTools → Performance → enregistrer un chargement complet → repérer les barres rouges marquées « Long Task ». Le panneau Bottom-Up donne le script responsable.
Pour la donnée RUM (utilisateurs réels), web-vitals.js expose un attribut attribution qui donne le nom du script et le type d’élément cliqué. 5 KB de JS bien placés valent mieux qu’une semaine d’audits laboratoire.
Casser les long tasks : 4 techniques
1. Defer par défaut
Depuis WordPress 6.3, wp_enqueue_script() accepte un argument strategy :
'defer': téléchargement parallèle, exécution après le parsing HTML'async': téléchargement et exécution dès que disponible (pour l’analytics indépendante)
Auditez vos enqueue : tout ce qui n’est pas strictement nécessaire au render initial doit être en defer. C’est gratuit et l’effet est immédiat sur l’INP.
2. Découper avec scheduler.yield()
Pour vos propres scripts (init de carrousel, gestion d’overlay, compteurs animés), inserez des points de yield :
async function initHeavyComponent() {
prepareData();
await scheduler.yield(); // permet au browser de rendre, gérer un clic, etc.
attachListeners();
await scheduler.yield();
loadOptionalAssets();
}Fallback pour les browsers qui ne supportent pas encore scheduler.yield : await new Promise(r => setTimeout(r, 0)).
3. Désactiver le heartbeat WordPress sur le front
Le heartbeat envoie une requête admin-ajax.php toutes les 15 secondes, même côté front, sans aucune utilité publique. Sur les pages publiques, c’est une long task récurrente qui pénalise l’INP des sessions longues.
Solution propre :
add_action('init', function () {
if (! is_admin()) {
wp_deregister_script('heartbeat');
}
}, 1);Côté admin, gardez-le mais réduisez l’intervalle à 60s en dehors de l’éditeur.
4. Charger conditionnellement les plugins
Un plugin de chat ne sert qu’aux pages contact. Un slider ne sert que sur la home. Asset CleanUp ou Perfmatters permettent de désactiver les CSS/JS d’un plugin sur les pages où il n’est pas utilisé. Effet immédiat sur le bundle initial et donc sur l’INP.
Le meilleur JavaScript pour l’INP est celui qu’on n’envoie jamais au navigateur.
Mesurer le résultat
Lighthouse simule un CPU 4× plus lent — utile pour le worst case mais ne remplace pas la donnée RUM. Comptez 14 jours d’agrégation CrUX pour voir l’effet d’une optimisation INP côté Search Console.
Cible réaliste après les 4 leviers ci-dessus : INP au 75ᵉ percentile sous 150 ms. Au-delà, les gains exigent un refactor JavaScript profond (souvent retirer un plugin lourd entièrement).
Besoin d’un audit INP sur votre site WordPress ? Contactez-nous pour identifier les 3 long tasks les plus coûteuses.