Correction d'un INP élevé sur Shopify : 7 correctifs éprouvés pour obtenir moins de 200 ms (2026)

Qu'est-ce que l'INP et pourquoi a-t-il remplacé le FID ?

L'interaction avec Next Paint (INP) est l'un des trois programmes de Google Core Web Vitals — les métriques qui influencent directement votre classement dans les recherches et mesurent l'expérience utilisateur réelle. Mesures INP à quelle vitesse votre page répond aux interactions des utilisateurs — chaque clic, appui et pression sur une touche tout au long de la visite de la page.

En mars 2024, l'INP officiellement a remplacé le premier délai d'entrée (FID) comme Core Web Vital. Pourquoi? FID a uniquement mesuré le délai avant que le navigateur démarré traitant la toute première interaction. Il a manqué deux problèmes critiques : le temps de traitement lent (le travail réel effectué par le navigateur) et le délai de présentation (le temps nécessaire pour peindre le résultat). Il a également ignoré toutes les interactions après la première.

INP corrige tout cela. Il suit chaque interaction and measures the full round trip — from the moment a user clicks to the moment the screen updates. Each interaction has three phases:

INP signale le pire interaction (techniquement le 98e percentile) sur l'ensemble de la visite de la page. Cela signifie que même une interaction lente – comme un bouton « Ajouter au panier » lent ou une liste déroulante de filtre lente – peut faire échouer votre score INP.

Pourquoi INP est important pour votre boutique Shopify : Un magasin qui répond lentement semble en panne. Lorsqu'un client appuie sur "Ajouter au panier" et que rien ne se passe pendant 400 ms, il appuie à nouveau - et se retrouve parfois avec deux articles ou s'éloigne complètement. Un mauvais INP nuit à la fois à votre classement SEO et à votre taux de conversion. Vous voulez voir où se situe votre magasin ? Exécutez un test de vitesse gratuit.

La solution facile : optimisation automatique de l'INP

Avant de plonger dans l'optimisation manuelle de JavaScript, il existe une approche plus rapide. Thunder Page Speed Optimizer répond automatiquement à plusieurs des causes les plus courantes d'INP élevé dans les magasins Shopify.

Comment mesurer l'INP sur votre boutique Shopify

Avant de corriger INP, vous devez identifier quelles interactions sont lentes et pourquoi. Voici les meilleurs outils :

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const duration = entry.duration;
    const status = duration < 200 ? '🟢' : duration < 500 ? '🟡' : '🔴';
    console.log(
      `${status} INP candidate: ${duration.toFixed(0)}ms`,
      `| Input delay: ${entry.inputDelay?.toFixed(0) ?? '?'}ms`,
      `| Processing: ${entry.processingDuration?.toFixed(0) ?? '?'}ms`,
      `| Presentation: ${(duration - (entry.inputDelay ?? 0) - (entry.processingDuration ?? 0)).toFixed(0)}ms`,
      `| Target: ${entry.target?.tagName ?? 'unknown'}`
    );
  }
}).observe({ type: 'event', buffered: true, durationThreshold: 16 });

Causes courantes d'un INP élevé sur Shopify

Avant de vous lancer dans les correctifs, comprenez ce qui cause un INP élevé sur votre boutique. Voici les coupables les plus courants, classés selon la fréquence à laquelle ils affectent les magasins Shopify :

La plupart des magasins Shopify présentent une combinaison de ces problèmes. La bonne nouvelle : même en corrigeant une ou deux des principales causes, vous pouvez améliorer considérablement votre score INP. Passons en revue les correctifs. Pour plus d'informations sur la manière dont ces problèmes sont liés à la vitesse globale du magasin, consultez notre guide complet d'optimisation de la vitesse Shopify.

Correctif n°1 : diviser les longues tâches JavaScript

Le thread principal du navigateur est monothread : il ne peut faire qu'une seule chose à la fois. Lorsque JavaScript s'exécute pendant plus de 50 ms sans céder, il devient un "tâche longue" qui bloque les interactions des utilisateurs. Si un utilisateur clique pendant qu'une longue tâche est en cours d'exécution, le navigateur ne peut pas répondre tant que la tâche n'est pas terminée, ce qui augmente directement le délai de saisie.

Utilisez planning.yield() (recommandé)

La manière moderne de diviser les tâches longues est planificateur.yield(). Il met votre code en pause, laisse le navigateur gérer les interactions et le rendu en attente, puis reprend :

// Before: One long task blocking the main thread
async function processProducts(products) {
  for (const product of products) {
    updateProductCard(product);  // DOM updates
    calculatePricing(product);   // Heavy computation
    renderReviews(product);      // More DOM work
  }
}

// After: Yields between iterations so browser stays responsive
async function processProducts(products) {
  for (const product of products) {
    updateProductCard(product);
    calculatePricing(product);
    renderReviews(product);

    // Yield to the browser between each product
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    }
  }
}

Solution de repli : modèle setTimeout

Pour les navigateurs qui ne prennent pas en charge planificateur.yield() encore, utilisez le setTimeout(0) Modèle :

function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processProducts(products) {
  for (let i = 0; i < products.length; i++) {
    updateProductCard(products[i]);

    // Yield every 5 iterations to balance throughput and responsiveness
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Utilisez requestAnimationFrame pour les mises à jour visuelles

Lorsque votre gestionnaire d'événements doit mettre à jour l'interface utilisateur, enveloppez les modifications visuelles dans requestAnimationFrame pour les regrouper avec le cycle de rendu du navigateur :

// Bad: DOM updates interleaved with logic
button.addEventListener('click', () => {
  const data = computeExpensiveData();
  element.style.height = data.height + 'px';  // Forces layout
  element.textContent = data.label;
  element.classList.add('active');
});

// Good: Separate computation from rendering
button.addEventListener('click', () => {
  const data = computeExpensiveData();
  requestAnimationFrame(() => {
    element.style.height = data.height + 'px';
    element.textContent = data.label;
    element.classList.add('active');
  });
});

Correctif n°2 : optimiser les gestionnaires d'événements

Chaque gestionnaire d'événements qui s'exécute lors d'une interaction utilisateur s'ajoute à la phase de temps de traitement d'INP. Le but : rendre vos handlers aussi rapides que possible, et différer tout ce qui n'est pas immédiatement visible.

Événements anti-rebond à tir rapide

Des événements tels que le défilement, le redimensionnement et la saisie se déclenchent plusieurs fois par seconde. Sans rebondir, chaque événement exécute votre gestionnaire, créant ainsi un arriéré de tâches longues :

// Bad: Fires on every keystroke in search
searchInput.addEventListener('input', (e) => {
  fetchSearchResults(e.target.value);  // API call on every keypress!
  renderSuggestions();
});

// Good: Debounce to max once per 300ms
let debounceTimer;
searchInput.addEventListener('input', (e) => {
  clearTimeout(debounceTimer);
  debounceTimer = setTimeout(() => {
    fetchSearchResults(e.target.value);
    renderSuggestions();
  }, 300);
});

Différer les travaux non visuels

Lorsqu'un utilisateur clique sur « Ajouter au panier », il doit voir commentaires immédiats — mais le suivi des analyses, les vérifications d'inventaire et les mises à jour des recommandations peuvent avoir lieu après la mise à jour visuelle :

addToCartButton.addEventListener('click', async () => {
  // 1. Visual feedback FIRST (what the user needs to see)
  showCartAnimation();
  updateCartCount();

  // 2. Defer non-visual work
  requestIdleCallback(() => {
    trackAnalyticsEvent('add_to_cart');
    updateRecommendations();
    syncInventory();
  });
});

Utiliser la délégation d'événement

Au lieu d'attacher des gestionnaires de clics individuels à des dizaines de fiches produits, utilisez la délégation d'événements avec un seul gestionnaire sur le conteneur parent :

// Bad: 50 individual handlers on a collection page
document.querySelectorAll('.product-card').forEach(card => {
  card.addEventListener('click', handleProductClick);
});

// Good: One handler via event delegation
document.querySelector('.product-grid').addEventListener('click', (e) => {
  const card = e.target.closest('.product-card');
  if (card) handleProductClick(card);
});

Correctif n°3 : réduire la taille du DOM

Chaque élément de votre DOM ralentit les recalculs de mise en page. Lorsque le navigateur doit mettre à jour l'écran après une interaction (la phase de retard de présentation), il doit recalculer les styles et la mise en page pour potentiellement des milliers d'éléments. Google recommande de conserver votre DOM sous 1 400 éléments — de nombreux magasins Shopify en comptent plus de 3 000.

Auditez la taille de votre DOM

Vérifiez la taille actuelle de votre DOM dans la console Chrome DevTools :

console.log('DOM elements:', document.querySelectorAll('*').length);
console.log('Max depth:', document.querySelector('[data-max-depth]')?.dataset.maxDepth);

// Find the heaviest sections
document.querySelectorAll('section, div[class]').forEach(el => {
  const count = el.querySelectorAll('*').length;
  if (count > 100) console.log(count, el.className || el.tagName);
});

Sources courantes de ballonnements du DOM sur Shopify

• Méga menus — Restitue souvent tout le contenu de la liste déroulante même lorsqu'il est masqué. Utilisez un rendu paresseux ou visibilité du contenu : auto pour les sections hors écran.
• Sélecteurs de variantes de produits — Les magasins avec plus de 50 variantes peuvent afficher des éléments d'option cachés pour chacune d'entre elles. Variantes de chargement sur demande.
• Listes de liens de pied de page — Les méga-liens de pied de page avec des dizaines de colonnes ajoutent des centaines d'éléments DOM sous le pli.
• Doublons cachés sur mobile/ordinateur de bureau — Les thèmes qui affichent à la fois la navigation sur mobile et sur ordinateur (en masquant une avec CSS) doublent les éléments DOM.

Utiliser la visibilité du contenu pour le contenu hors écran

/* Skip rendering for sections below the fold */
.product-recommendations,
.footer-mega-links,
.recently-viewed {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px; /* Estimated height */
}

Cette propriété CSS indique au navigateur d'ignorer le travail de rendu pour les éléments hors écran. Lorsque l'utilisateur les fait défiler, le navigateur les restitue juste à temps. Cela améliore directement la phase de délai de présentation d'INP car il y a moins d'éléments à recalculer lors des interactions. Pour en savoir plus sur la réduction Problèmes liés à la mise en page , voir notre guide CLS.

Correctif n°4 : éliminer les problèmes de mise en page

La mise en page se produit lorsque JavaScript alterne entre la lecture et l'écriture des propriétés de mise en page DOM dans une boucle. Chaque lecture force le navigateur à recalculer la mise en page de manière synchrone - et si vous écrivez immédiatement après, la lecture suivante force un autre recalcul.

// Bad: Layout thrashing — forces layout recalc on EVERY iteration
function resizeCards() {
  const cards = document.querySelectorAll('.product-card');
  cards.forEach(card => {
    const height = card.offsetHeight;      // READ (forces layout)
    card.style.minHeight = height + 'px';  // WRITE (invalidates layout)
    // Next iteration's read forces ANOTHER layout recalculation
  });
}

// Good: Batch reads, then batch writes
function resizeCards() {
  const cards = document.querySelectorAll('.product-card');

  // Phase 1: Read all values
  const heights = Array.from(cards).map(card => card.offsetHeight);

  // Phase 2: Write all values (only one layout recalc)
  cards.forEach((card, i) => {
    card.style.minHeight = heights[i] + 'px';
  });
}

Propriétés qui déclenchent une disposition forcée : offsetHauteur, offsetLargeur, getBoundingClientRect(), scrollTop, hauteur du client, et getComputedStyle(). Lorsque l'un d'entre eux est lu après une écriture DOM, le navigateur doit recalculer la disposition de manière synchrone.

Vérifiez le JavaScript de votre thème pour ces modèles : ils sont particulièrement courants dans les mises en page de grille de produits, les en-têtes collants et les implémentations de défilement infini.

Correctif n°5 : apprivoiser les scripts tiers

Les scripts tiers sont les tueurs INP silencieux sur les magasins Shopify. Chaque application que vous installez peut ajouter du JavaScript qui s'exécute à chaque chargement de page et, plus important encore, à chaque interaction de l'utilisateur. Les scripts d'analyse qui suivent les clics, les widgets d'examen traités au survol et les widgets de discussion qui interceptent les événements sont tous en compétition pour le fil principal.

Auditez l'impact de vos scripts tiers

In Chrome DevTools, record a Performance trace while interacting with your page. In the Main thread flame chart, look for long tasks from third-party domains. You can also use the Panneau Réseau → filtrer par "JS" → trier par taille pour voir quels scripts se chargent :

• Analyse — Google Analytics, Meta Pixel, TikTok Pixel ajoutent souvent des auditeurs d'événements
• Avis — Yotpo, Judge.me, Loox peuvent traiter les événements de défilement et de clic
• Bavarder — Tidio, Zendesk et Gorgias interceptent les événements de clic sur toute la page
• Vente incitative/vente croisée — Les applications ReConvert et Bold ajoutent souvent des gestionnaires aux interactions avec le panier

Approche manuelle : différer avec déclencheur d'interaction

Chargez les scripts tiers non critiques uniquement après la première interaction utilisateur, lorsque la page est déjà réactive :

<script>
  // Load non-critical scripts after first user interaction
  const loadDeferredScripts = () => {
    // Analytics
    const ga = document.createElement('script');
    ga.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXX';
    ga.async = true;
    document.head.appendChild(ga);

    // Chat widget
    const chat = document.createElement('script');
    chat.src = 'https://cdn.chatwidget.com/widget.js';
    chat.async = true;
    document.head.appendChild(chat);

    // Remove listeners after loading
    ['click', 'scroll', 'keydown', 'touchstart'].forEach(event =>
      document.removeEventListener(event, loadDeferredScripts)
    );
  };

  ['click', 'scroll', 'keydown', 'touchstart'].forEach(event =>
    document.addEventListener(event, loadDeferredScripts, { once: false, passive: true })
  );
</script>

Ce modèle fonctionne mais est fragile : vous devez gérer la liste des scripts manuellement, gérer les dépendances entre les scripts et vous assurer que rien ne se casse lorsque les scripts se chargent dans le désordre. C'est exactement ce que Thunder automatise: il identifie quels scripts peuvent être différés en toute sécurité, gère leurs dépendances et les charge dans l'ordre optimal. En savoir plus sur gestion des scripts tiers sur Shopify.

Avancé : Web Workers et fractionnement de code

Pour les magasins dotés de fonctionnalités personnalisées complexes (configurateurs de produits avancés, calculs de prix en temps réel ou recherche côté client), ces techniques avancées peuvent réduire considérablement le temps de traitement.

Déplacer les calculs lourds vers les Web Workers

Web Workers exécutent JavaScript sur un thread séparé, complètement indépendant du thread principal. Cela signifie que des calculs lourds ne bloqueront pas les interactions des utilisateurs :

// pricing-worker.js — runs on a separate thread
self.addEventListener('message', (e) => {
  const { products, discountRules } = e.data;
  const calculated = products.map(p => ({
    ...p,
    finalPrice: applyDiscountRules(p, discountRules),
    savings: calculateSavings(p, discountRules),
  }));
  self.postMessage(calculated);
});

// main.js — keeps the main thread free
const pricingWorker = new Worker('/pricing-worker.js');

variantSelector.addEventListener('change', () => {
  // Show loading state immediately (fast — on main thread)
  showPriceLoading();

  // Offload heavy calculation to worker (won't block interactions)
  pricingWorker.postMessage({
    products: getSelectedProducts(),
    discountRules: window.discountRules,
  });
});

pricingWorker.addEventListener('message', (e) => {
  // Update UI with results (fast — just DOM updates)
  updatePriceDisplay(e.data);
});

Fractionnement de code pour le thème JavaScript

Ne chargez pas tout JavaScript à l'avance. Divisez le code pour que chaque page ne charge que ce dont elle a besoin :

// Instead of loading everything in theme.js:
// import './product-zoom.js';
// import './cart-drawer.js';
// import './mega-menu.js';
// import './search-autocomplete.js';

// Load only when needed:
if (document.querySelector('.product-media')) {
  import('./product-zoom.js');
}
if (document.querySelector('.cart-drawer')) {
  import('./cart-drawer.js');
}

// Or load on first interaction:
document.querySelector('.search-input')?.addEventListener('focus', () => {
  import('./search-autocomplete.js').then(mod => mod.init());
}, { once: true });

Les importations dynamiques réduisent la charge utile JavaScript initiale, ce qui signifie moins de blocages du thread principal pendant les premiers moments critiques où les utilisateurs sont les plus susceptibles d'interagir. Cela réduit également l’impact de ressources bloquant le rendu sur votre boutique.

Correctifs manuels INP vs Thunder : comparaison côte à côte

Voici comment l'approche manuelle se compare au fait de laisser Thunder gérer automatiquement l'optimisation INP :

Les correctifs manuels vous offrent un contrôle granulaire mais nécessitent une expertise JavaScript importante et une maintenance continue. Thunder gère automatiquement les optimisations les plus percutantes, en particulier le report des scripts et la gestion tierce. De nombreux développeurs combinent les deux : installez Thunder pour le gros du travail, puis appliquez des correctifs manuels pour les goulots d'étranglement du code personnalisé. Voir les plans tarifaires Thunder.

Foire aux questions