Correggi INP elevato su Shopify: 7 soluzioni comprovate per scendere sotto i 200 ms (2026)

Cos'è l'INP e perché ha sostituito il FID?

Interaction to Next Paint (INP) è uno dei tre di Google Core Web Vitals : le metriche che influenzano direttamente il posizionamento nelle ricerche e misurano l'esperienza utente reale. Misure dell'INP la velocità con cui la tua pagina risponde alle interazioni degli utenti : ogni clic, tocco e pressione di un tasto durante l'intera visita della pagina.

Nel marzo 2024, INP ufficialmente ha sostituito il primo ritardo di ingresso (FID) come Core Web Vital. Perché? Il FID ha misurato solo il ritardo prima del browser iniziato elabora la primissima interazione. Mancava due problemi critici: tempo di elaborazione lento (il lavoro effettivo svolto dal browser) e ritardo nella presentazione (tempo necessario per dipingere il risultato). Inoltre ha ignorato ogni interazione successiva alla prima.

INP risolve tutto questo. Tiene traccia ogni interazione and measures the full round trip — from the moment a user clicks to the moment the screen updates. Each interaction has three phases:

INP riporta il interazione peggiore (tecnicamente il 98° percentile) durante l'intera visita della pagina. Ciò significa che anche una sola interazione lenta, come un pulsante "Aggiungi al carrello" lento o un menu a discesa del filtro lento, può fallire nel tuo punteggio INP.

Perché INP è importante per il tuo negozio Shopify: Un negozio che risponde lentamente sembra rotto. Quando un cliente tocca "Aggiungi al carrello" e non succede nulla per 400 ms, tocca di nuovo e talvolta si ritrova con due articoli o scompare completamente. Uno scarso INP danneggia sia il tuo posizionamento SEO che il tuo tasso di conversione. Vuoi vedere dove si trova il tuo negozio? Esegui un test di velocità gratuito.

La soluzione semplice: ottimizzazione INP automatica

Prima di immergerci nell'ottimizzazione manuale di JavaScript: esiste un approccio più rapido. Thunder Page Speed Optimizer risolve automaticamente molte delle cause più comuni di INP elevato nei negozi Shopify.

Come misurare l'INP sul tuo negozio Shopify

Prima di correggere l'INP, è necessario identificare quali interazioni sono lente e perché. Ecco gli strumenti migliori:

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 });

Cause comuni di INP elevato su Shopify

Prima di dedicarti alle soluzioni, capisci cosa sta causando un INP elevato nel tuo negozio. Ecco i colpevoli più comuni, classificati in base alla frequenza con cui colpiscono i negozi Shopify:

La maggior parte dei negozi Shopify presenta una combinazione di questi problemi. La buona notizia: anche risolvere una o due delle cause principali può migliorare notevolmente il tuo punteggio INP. Esaminiamo le soluzioni. Per ulteriori informazioni su come questi problemi si riferiscono alla velocità complessiva del negozio, consulta la nostra guida completa all'ottimizzazione della velocità di Shopify.

Correzione n. 1: suddivisione di attività JavaScript lunghe

Il thread principale del browser è a thread singolo: può fare solo una cosa alla volta. Quando JavaScript viene eseguito per più di 50 ms senza cedere, diventa a "compito lungo" che blocca le interazioni dell'utente. Se un utente fa clic mentre è in esecuzione un'attività lunga, il browser non può rispondere fino al termine dell'attività, aumentando direttamente il ritardo di input.

Utilizza scheduler.yield() (consigliato)

Il modo moderno di suddividere i compiti lunghi è scheduler.rendimento(). Mette in pausa il codice, consente al browser di gestire le interazioni e il rendering in sospeso, quindi riprende:

// 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();
    }
  }
}

Fallback: setTimeout Pattern

Per i browser che non supportano scheduler.rendimento() ancora, usa il setTimeout(0) Modello :

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();
    }
  }
}

Utilizza requestAnimationFrame per gli aggiornamenti visivi

Quando il gestore eventi deve aggiornare l'interfaccia utente, inserisci le modifiche visive requestAnimationFrame per raggrupparli con il ciclo di rendering del browser:

// 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');
  });
});

Correzione n. 2: ottimizzazione dei gestori eventi

Ogni gestore di eventi eseguito durante l'interazione dell'utente si aggiunge alla fase temporale di elaborazione di INP. L'obiettivo: rendere i tuoi handler il più veloci possibile e rimandare tutto ciò che non è immediatamente visibile.

Eventi di fuoco rapido antirimbalzo

Eventi come scorrimento, ridimensionamento e input vengono attivati molte volte al secondo. Senza rimbalzare, ogni evento esegue il tuo gestore, creando un backlog di attività lunghe:

// 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);
});

Rinviare il lavoro non visivo

Quando un utente fa clic su "Aggiungi al carrello", deve farlo vedi feedback immediato, ma il monitoraggio delle analisi, i controlli dell'inventario e gli aggiornamenti dei consigli possono avvenire dopo l'aggiornamento visivo:

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();
  });
});

Utilizza la delega degli eventi

Invece di associare singoli gestori di clic a dozzine di schede prodotto, utilizza la delega degli eventi con un singolo gestore sul contenitore principale:

// 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);
});

Correzione n. 3: ridurre le dimensioni del DOM

Ogni elemento nel tuo DOM rallenta i ricalcoli del layout. Quando il browser deve aggiornare lo schermo dopo un'interazione (la fase di ritardo della presentazione), deve ricalcolare stili e layout per potenzialmente migliaia di elementi. Google consiglia di mantenere il tuo DOM sotto 1.400 elementi : molti negozi Shopify ne hanno più di 3.000.

Controlla la dimensione del tuo DOM

Controlla la dimensione attuale del DOM nella console di 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);
});

Fonti comuni di DOM Bloat su Shopify

• Mega menu — Spesso esegue il rendering di tutti i contenuti a discesa anche se nascosti. Utilizzare il rendering lento o visibilità del contenuto: auto per le sezioni fuori schermo.
• Selettori di varianti di prodotto — I negozi con più di 50 varianti possono visualizzare elementi di opzioni nascosti per ciascuna di esse. Varianti di carico su richiesta.
• Elenchi di collegamenti a piè di pagina — I mega-link a piè di pagina con dozzine di colonne aggiungono centinaia di elementi DOM sotto la piega.
• Duplicati mobili/desktop nascosti — I temi che rendono la navigazione sia mobile che desktop (nascondendola con CSS) raddoppiano gli elementi DOM.

Utilizza la visibilità dei contenuti per i contenuti fuori schermo

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

Questa proprietà CSS indica al browser di saltare il lavoro di rendering per gli elementi fuori schermo. Quando l'utente scorre vicino a loro, il browser li visualizza appena in tempo. Ciò migliora direttamente la fase di ritardo della presentazione dell'INP perché ci sono meno elementi da ricalcolare durante le interazioni. Per ulteriori informazioni sulla riduzione problemi relativi al layout, consulta la nostra guida CLS.

Correzione n. 4: eliminazione del thrashing del layout

Il thrashing del layout si verifica quando JavaScript alterna la lettura e la scrittura delle proprietà del layout DOM in un ciclo. Ogni lettura forza il browser a ricalcolare in modo sincrono il layout e, se scrivi immediatamente dopo, viene forzata la lettura successiva un altro ricalcolo.

// 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';
  });
}

Proprietà che attivano il layout forzato: offsetAltezza, offsetWidth, getBoundingClientRect(), scorri in alto, altezzacliente getComputedStyle(). Quando uno di questi viene letto dopo una scrittura DOM, il browser deve ricalcolare il layout in modo sincrono.

Controlla il JavaScript del tuo tema per questi modelli: sono particolarmente comuni nei layout della griglia dei prodotti, nelle intestazioni permanenti e nelle implementazioni di scorrimento infinito.

Correzione n. 5: doma gli script di terze parti

Gli script di terze parti sono i killer INP silenziosi nei negozi Shopify. Ogni app che installi può aggiungere JavaScript che viene eseguito a ogni caricamento della pagina e, cosa più importante, a ogni interazione dell'utente. Gli script di analisi che tengono traccia dei clic, i widget di revisione che vengono elaborati al passaggio del mouse e i widget di chat che intercettano gli eventi competono tutti per il thread principale.

Controlla l'impatto degli script di terze parti

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 Pannello di rete → filtra per "JS" → ordina per dimensione per vedere quali script vengono caricati:

• Analitica : Google Analytics, Meta Pixel, TikTok Pixel spesso aggiungono ascoltatori di eventi
• Recensioni — Yotpo, Judge.me, Loox possono elaborare eventi di scorrimento e clic
• Chatta — Tidio, Zendesk e Gorgia intercettano eventi di clic a livello di pagina
• Upsell/Cross-sell — ReConvert, le app Bold spesso aggiungono gestori alle interazioni del carrello

Approccio manuale: differimento con trigger di interazione

Carica script di terze parti non critici solo dopo la prima interazione dell'utente, quando la pagina è già reattiva:

<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>

Questo modello funziona ma è fragile: è necessario mantenere manualmente l'elenco degli script, gestire le dipendenze tra gli script e garantire che nulla si rompa quando gli script vengono caricati in modo non corretto. Questo è esattamente ciò che Thunder automatizza: identifica quali script sono sicuri da differire, gestisce le loro dipendenze e li carica nell'ordine ottimale. Leggi di più su gestione di script di terze parti su Shopify.

Avanzato: Web Worker e Code Splitting

Per i negozi con funzionalità personalizzate complesse (configuratori di prodotto avanzati, calcoli dei prezzi in tempo reale o ricerca lato client) queste tecniche avanzate possono ridurre notevolmente i tempi di elaborazione.

Sposta il calcolo pesante sui Web Worker

I Web Worker eseguono JavaScript su un thread separato, completamente indipendente dal thread principale. Ciò significa che i calcoli pesanti non bloccheranno le interazioni dell'utente:

// 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);
});

Suddivisione del codice per JavaScript del tema

Non caricare tutti i JavaScript in anticipo. Dividi il codice in modo che ogni pagina carichi solo ciò di cui ha bisogno:

// 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 });

Le importazioni dinamiche riducono il payload JavaScript iniziale, il che significa meno blocchi del thread principale durante i primi momenti critici in cui è più probabile che gli utenti interagiscano. Ciò riduce anche l'impatto di Risorse che bloccano il rendering nel tuo negozio.

Correzioni INP manuali rispetto a Thunder: confronto affiancato

Ecco come si confronta l'approccio manuale con il lasciare che Thunder gestisca automaticamente l'ottimizzazione INP:

Le correzioni manuali offrono un controllo granulare ma richiedono una significativa esperienza JavaScript e una manutenzione continua. Thunder gestisce automaticamente le ottimizzazioni di maggior impatto, in particolare il differimento degli script e la gestione di terze parti. Molti sviluppatori combinano entrambe le cose: installano Thunder per il lavoro pesante, quindi applicano correzioni manuali per i colli di bottiglia del codice personalizzato. Vedi i piani tariffari Thunder.

Domande frequenti