Minimisez le travail du fil principal sur Shopify : Correction de l'avertissement PageSpeed (2026)

Solution rapide avec Thunder

Ce que fait réellement le fil principal

Le fil conducteur du navigateur est la voie unique où se déroule le travail de page le plus visible. Il analyse le HTML, analyse le CSS, calcule les styles applicables, calcule la mise en page, peint les pixels, gère les entrées et exécute JavaScript. Lorsque JavaScript est en cours d'exécution, le navigateur ne peut pas simultanément répondre à une pression, mettre à jour la mise en page ou peindre un nouveau cadre.

Lighthouse divise cela en catégories telles que l'évaluation de script, l'analyse et la compilation de script, le style et la mise en page, le rendu, l'analyse HTML et CSS et le garbage collection. Les marchands Shopify voient souvent l'évaluation des scripts dominer le rapport, car les scripts d'application s'exécutent sur chaque page, même lorsque le client n'ouvre jamais le widget.

C'est pourquoi l'avertissement est important au-delà du score de laboratoire. Un travail élevé sur le fil principal gonfle le temps de blocage total, et le temps de blocage total est un signal de laboratoire fort pour une réelle douleur d'interaction. Le seuil INP de Google pour une bonne expérience est inférieur à 200 ms ; si le thread principal est occupé, le clic attend.

Pourquoi les magasins Shopify déclenchent cet avertissement

Étape 1 : Trouver les tâches longues

Ouvrez Chrome DevTools, accédez à Performances, enregistrez le chargement d'une page et recherchez les longues tâches jaunes. Toute tâche de plus de 50 ms bloque le thread principal suffisamment longtemps pour être prise en compte dans le temps de blocage total.

// Quick field debugging in the browser console
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long task:', Math.round(entry.duration), 'ms');
  }
}).observe({ type: 'longtask', buffered: true });

If the worst tasks come from third-party domains, use our Guide des scripts tiers. If they come from your own theme bundle, continue below.

Étape 2 : différer les scripts de thème non critiques

Scripts dans la tête sans analyse de bloc de report et en compétition pour le thread principal plus tôt. Pour les scripts de thème qui n'ont pas besoin d'être exécutés avant l'apparition du contenu, utilisez defer :

<script src="{{ 'theme.js' | asset_url }}" defer></script>

Soyez prudent avec les dépendances. Si un sélecteur de variantes dépend d'une bibliothèque globale chargée avant lui, conservez l'ordre. N'ajoutez pas aveuglément de l'asynchrone à tout ; async peut exécuter des fichiers dans le désordre. Thunder gère le report tenant compte des dépendances pour les scripts d'application, ce qui représente généralement le gain le plus important.

Étape 3 : Charger les widgets uniquement en cas de besoin

Les discussions, les carrousels d'avis, les blocs de recommandations et les intégrations de vidéos n'ont souvent pas besoin d'être initialisés au chargement de la page. Chargez-les lorsqu'ils sont visibles ou après une interaction.

const widget = document.querySelector('[data-reviews-widget]');

const observer = new IntersectionObserver((entries) => {
  if (!entries.some((entry) => entry.isIntersecting)) return;

  import('./reviews-widget.js').then((module) => {
    module.init(widget);
  });

  observer.disconnect();
}, { rootMargin: '300px' });

if (widget) observer.observe(widget);

Ce modèle maintient le JavaScript inutilisé hors du chemin critique. Pour les images et les intégrations, associez-le à notre Guide de chargement paresseux de Shopify.

Étape 4 : diviser les longues tâches JavaScript

If your theme loops through hundreds of DOM nodes, recalculates prices, updates filters, or renders search results in one big block, yield back to the browser between chunks.

async function renderProducts(products) {
  for (let i = 0; i < products.length; i += 12) {
    renderProductBatch(products.slice(i, i + 12));

    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }
}

This does not reduce total work, but it prevents one long task from blocking input. That helps INP, especially on mobile where CPU throttling makes every millisecond of script work more expensive. For deeper JavaScript cleanup, use our Guide d'optimisation JavaScript de Shopify.

Étape 5 : évitez les modifications de la mise en page

La mise en page se produit lorsque le code lit à plusieurs reprises les valeurs de mise en page et écrit les modifications DOM dans la même boucle. Chaque lecture peut forcer le navigateur à recalculer la mise en page de manière synchrone.

// Bad: read and write in the same loop
cards.forEach((card) => {
  const height = card.offsetHeight;
  card.style.minHeight = height + 20 + 'px';
});

// Better: batch reads, then batch writes
const heights = cards.map((card) => card.offsetHeight);
cards.forEach((card, index) => {
  card.style.minHeight = heights[index] + 20 + 'px';
});

Cela est important pour les pages de collection, les tiroirs à ajout rapide, les en-têtes collants et les galeries multimédias de produits. Si PageSpeed ​​affiche à la fois un travail sur le fil principal et un coût de style/mise en page élevé, inspectez d'abord ces composants interactifs.

Correction manuelle vs Thunder Fix

Retestez les bonnes métriques

Après les modifications, retestez d'abord le mobile. Regardez le temps de blocage total dans Lighthouse, l'INP dans les données de terrain et la répartition des catégories de threads principaux. Ne recherchez pas un score parfait sur une seule manche synthétique ; comparez plusieurs exécutions et utilisez le tableau de bord des performances Web de Shopify pour connaître les tendances des utilisateurs réels.

Si votre LCP est également élevé, le prochain goulot d'étranglement peut être votre image de héros. Utilisez notre Guide de préchargement des images de héros Shopify et le plus large Guide d'optimisation de la vitesse Shopify. Si PageSpeed signale également Temps de blocage total Shopify élevé, chaînes de requêtes critiques, ou Rembourrage énormes charges utiles réseau, corrigez ces diagnostics dans la même passe d'audit. Pour connaître les options de tarification et d'automatisation, voir Tarification Thunder.

Références et Validation

Utilisation Répartition du travail principal de Lighthouse comme source de vérité sur ce que mesure le diagnostic. Il sépare l'évaluation des scripts, l'analyse, le style et la mise en page, le rendu et les autres travaux du navigateur afin que vous puissiez savoir si le problème concerne le code de votre thème, la pile de votre application ou la quantité de DOM que le navigateur doit traiter.

Pour la réactivité, recoupez-vous avec web.dev. Un magasin peut paraître visuellement chargé tout en ayant l'impression d'être brisé si le fil principal est occupé lorsque le client appuie sur une variante, ouvre le tiroir du panier ou clique sur la caisse. C'est pourquoi Thunder se concentre autant sur le report des scripts tiers : il donne au navigateur la possibilité de répondre avant que le visiteur ne perde patience.