Le signal technique que Google surveille (et que 90 % des sites WordPress ignorent encore)

Pourquoi l’INP, c’est le nouveau juge de paix

Avant, on regardait le FID (First Input Delay) : il mesurait la réactivité du site au premier clic. Maintenant, Google veut évaluer toutes les interactions, d’où l’INP. En gros, si ton site met plus de 200 ms entre la clic et le rendu visuel suivant, tu es dans le rouge :contentReference[oaicite:1]{index=1}.

• Bon ≤ 200 ms
• À améliorer 200‑500 ms
• Mauvais ≥ 500 ms

Les trois phases de l’INP

Une interaction = trois étapes : input delay, traitement JS, et présentation du frame. Si une des étapes traîne, l’INP explose :contentReference[oaicite:2]{index=2}. On y va phase par phase :

1. Input delay

C’est le temps entre le clic et le début de l’exécution du code JS. Si tu charges trop de JS ou que ton main thread est occupé, c’est mort.

2. Traitement JS

Une fonction longue (ex : manipulation du DOM, boucles lourdes) bloque tout.

3. Présentation

Le navigateur doit générer le rendu visuel. Si des tâches bloquent le thread, ça ajoute du lag.

WordPress : 5 tweaks ultra-pratiques

1. Alléger le JS : supprime les plugins inutiles, combine et minifie JS avec WP Rocket ou Autoptimize. Charge les scripts essentiels en “defer” ou “async” :contentReference[oaicite:3]{index=3}.
2. Web workers : utilise un plugin (ex. WP Web Workers) pour déporter les calculs lourds hors du main thread.
3. Audit TBT : Lighthouse ou PSI donnent le Total Blocking Time. Corrige les fonctions qui traînent :contentReference[oaicite:4]{index=4}.
4. Lazy loading JS non critique : comme WordPress 6+, charge les scripts en Intersection Observer.
5. CDN + cache : utilise un CDN (Cloudflare, BunnyCDN) et active le cache page + objet. Résultat : moins de latence, thread plus dispo.

Shopify : rapidité et ecommerce friendly

1. Thème léger : évite les thèmes bourrés de fonctionnalités inutiles. Privilégie les thèmes “OS 2.0” optimisés vitesse :contentReference[oaicite:5]{index=5}.
2. Compression & lazy : compresse images (TinyPNG), active la lazy loading intégrée et utilise WebP :contentReference[oaicite:6]{index=6}.
3. JS tiers : trier / reporter : si tu utilises LiveChat, trackers, pixels, reporte-les via Tag Manager. Charge-les après interaction.
4. Code splitting : découpe les scripts via performance.js pour ne charger que ce qui est nécessaire selon la page :contentReference[oaicite:7]{index=7}.
5. Apps critiques only : limite les applications Shopify – chaque app injecte du JS/iframe.

Webflow : no-code, mais performant

Webflow sort du lot : CDN intégré, code minifié, lazy loading auto. Mais tu peux encore améliorer :contentReference[oaicite:8]{index=8} :

1. Audit natif : Webflow détecte CSS/JS non utilisés, supprime les classes inutiles.
2. Limiter les animations : les interactions complexes génèrent du JS lourd. Simplifie ou désactive les animations sur mobile.
3. Prerender / preload : dans les settings, ajoute les polices et fichiers critiques en préchargement.
4. Chargement différé des embeds : pour les YouTube, maps, embed externes – charge-les après scroll ou clic.

Tester, corriger, recommencer

• PageSpeed Insights : pour chaque page, prend le score INP et TBT.
• Chrome DevTools : onglet Performance > observe les interactions lentes et quel script les bloque :contentReference[oaicite:9]{index=9}.
• Champ réel : GSC (Search Console) pour voir les pages pénalisées en INP.

-> Dépiste les interactions lentes, corrige, teste à nouveau. Répète jusqu’à sous 200 ms.

Check‑list express pour éviter les grosses erreurs

• Moins de plugins / apps inutiles
• JS allégé, minifié, différé
• Web workers pour charges lourdes
• Lazy loading & code splitting
• CDN, cache, compression (Gzip/Brotli)
• Audit & testing réguliers (PSI, DevTools, Search Console)

Exemples concrets

• WordPress + formulaire : le bouton envoie un e-mail via AJAX lourd ? Résultat : > 600 ms. Solution : déporter le mail via web worker ou API, allègement du DOM. INP descend à 180 ms.
• Shopify + live chat : le chat charge dès l’accès page = gros JS avant interaction. Correctif : reporté après premier clic ou scroll. INP gagne 150 ms.
• Webflow + animation scroll : animation « fade-in » à chaque scroll = thread saturé. On réduit aux éléments clés + passe à CSS : INP passe de 300 à 190 ms.

En résumé

L’INP, c’est le nouveau standard de performance. Pour le maîtriser, tu dois auditer, alléger, déporter, tester. Sur WordPress, Shopify ou Webflow, chaque plateforme a ses armes : plugins, thèmes, lazy loading, CDN, code split. A toi de jouer, interaction par interaction.

FAQ

Qu’est-ce que l’INP ?

Interaction to Next Paint : elle mesure la latence visuelle après chaque interaction utilisateur. Objectif : <200 ms.

Comment tester l’INP ?

PageSpeed Insights, devtools Chrome performance, et Google Search Console (champ réel).

Pourquoi <200 ms ?

Google considère ce seuil comme “agréable à l’usage” pour l’expérience utilisateur :contentReference[oaicite:10]{index=10}.

INP et mobile, c’est plus dur ?

Oui : mobile = CPU moins rapide. Allège encore plus le JS, images, animations et plugins.

Combien de temps pour voir une amélioration ?

Tu peux descendre de 400→200 ms en quelques heures : focus sur le JS non critique à reporter, lazy loading, web workers.