- Core Web Vitals, Crescita eCommerce, eCommerce, engineering, Francesco Guiducci, liquid optimization, Roma, total blocking time
- Francesco Guiducci
Mobile Speed Shopify 2026: Core Web Vitals e Diagnosi Tecnica
Risposta diretta: la velocità mobile di uno store Shopify si migliora individuando il collo di bottiglia reale, non applicando un trucco universale. Uso dati reali quando disponibili, Core Web Vitals, test di laboratorio, waterfall di rete e analisi delle risorse per costruire una baseline, formulare una causa e verificare l’effetto di ogni intervento.
Su mobile la stessa pagina può comportarsi in modo molto diverso rispetto a un desktop potente: rete, CPU, memoria e interazioni rendono più evidente il costo di immagini, JavaScript, app, font, video e componenti del tema. Per questo non parto mai da “Shopify è lento” o “l’app X rallenta”: parto dal template e dalla metrica che sta realmente peggiorando.
Prima regola
Non ottimizzo un punteggio: ottimizzo una causa. Se il problema è l’immagine hero, rimuovere un’app irrilevante non serve. Se il problema è JavaScript di terze parti, comprimere ancora le immagini non risolve l’interattività.
1. Quali Core Web Vitals guardo su Shopify
Shopify misura le performance dello storefront attraverso LCP, INP e CLS e rende disponibili report basati su dati reali dei visitatori. Come riferimento operativo, Shopify considera “buono” un LCP entro 2,5 secondi, un INP entro 200 ms e un CLS entro 0,1, valutati al 75° percentile. Non uso però queste soglie come promessa commerciale: servono per capire dove investigare.
| Metrica | Cosa misura | Cause che verifico |
|---|---|---|
| LCP | Rapidità con cui compare il contenuto principale | Hero, immagine prodotto, font, CSS bloccante, priorità della risorsa, rendering tardivo |
| INP | Reattività alle interazioni | JavaScript lungo, listener, app, varianti, filtri, ricerca, menu, carrello |
| CLS | Stabilità visiva | Immagini senza spazio riservato, font, banner, app block, contenuti caricati dopo |
2. Dati reali e test di laboratorio non sono la stessa cosa
Un test sintetico è utile per riprodurre una pagina in condizioni controllate e analizzare rete, main thread e waterfall. I dati sul campo descrivono invece ciò che è accaduto agli utenti reali. Possono divergere, e non è un errore.
Quando ho abbastanza traffico parto dai report Web Performance di Shopify e dai dati reali disponibili; uso PageSpeed Insights o strumenti di laboratorio per investigare la causa. Se lo store è nuovo o ha poco traffico, il laboratorio pesa di più nella diagnosi iniziale, ma lo tratto come simulazione e non come prova definitiva dell’esperienza di tutti gli utenti.
Esempio pratico
La home può ottenere un buon LCP in laboratorio e avere comunque INP mediocre per utenti reali se un menu, un filtro o un’app eseguono molto JavaScript quando la persona interagisce. Guardare solo il numero iniziale significa perdere metà del problema.
3. LCP: identificare l’elemento prima di ottimizzarlo
La prima domanda è: qual è l’elemento LCP su quella pagina? Può essere una hero, una foto prodotto, un banner o un blocco di testo. Dopo averlo identificato controllo:
- dimensione effettiva dell’asset rispetto allo spazio visualizzato;
- formato e compressione;
- responsive image e varianti di dimensione;
- priorità di caricamento;
- eventuale lazy loading applicato erroneamente above-the-fold;
- CSS o JavaScript che ritardano il rendering;
- catena di richieste prima che il browser scopra la risorsa.
Non applico quindi lazy loading indiscriminato: un’immagine che deve diventare LCP può richiedere l’opposto, cioè essere scoperta e richiesta prima.
4. INP: quando il sito sembra caricato ma reagisce lentamente
INP riguarda la risposta alle interazioni. Su Shopify mi interessano soprattutto menu, selezione varianti, filtri, ricerca predittiva, quantità, carrello, drawer e componenti aggiunti dalle app.
Controllo task JavaScript lunghi, event listener, rendering provocato da una singola azione e codice che viene eseguito anche su pagine dove non serve. Se un’app introduce il costo, verifico prima se può essere configurata meglio o caricata in modo più selettivo; sostituirla è una decisione successiva, non automatica.
Diagnosi INP
- L’interazione lenta è sempre la stessa o varia?
- Il problema esiste anche su una copia del tema senza modifiche recenti?
- Quale script occupa il main thread durante l’interazione?
- La funzione dipende da un’app o dal tema?
- Il codice viene caricato globalmente pur servendo solo su alcuni template?
- Dopo la modifica varianti, carrello e tracking continuano a funzionare?
5. CLS: correggere lo spostamento, non nasconderlo
Per il CLS cerco elementi che cambiano posizione dopo il primo rendering: immagini senza dimensioni riservate, font, banner promozionali, widget, recensioni, app block e sezioni asincrone.
La soluzione corretta preserva lo spazio o rende prevedibile il rendering. Nascondere un componente utile solo per far sparire il movimento non è ottimizzazione: è perdita di funzione.
6. Immagini: il problema non è soltanto il peso del file
Una buona gestione immagini considera insieme peso, dimensioni erogate, densità dello schermo, priorità e posizione nella pagina. Una foto da migliaia di pixel servita dentro una card piccola spreca banda; un’immagine hero caricata troppo tardi può danneggiare LCP anche se è compressa.
| Situazione | Intervento che verifico |
|---|---|
| Hero above-the-fold | Dimensione corretta, priorità, discovery precoce, niente lazy indiscriminato |
| Griglia prodotti | Responsive sizes, dimensioni coerenti con la card, lazy sotto la piega |
| Immagini editoriali lunghe | Caricamento differito quando non immediatamente visibili |
| Video/background | Poster, autoplay realmente necessario, costo di rete e rendering |
7. App e script di terze parti: misurare prima di rimuovere
Shopify indica tra i fattori che influenzano la web performance app, librerie di terze parti, analytics, codice del tema, immagini e video. Questo non significa che ogni app sia un problema: alcune lavorano quasi soltanto in Admin o backend; altre modificano direttamente lo storefront.
Per le app frontend controllo richieste, JavaScript, CSS, app embed, blocchi e comportamento prima/dopo. Se una funzione genera valore reale, l’obiettivo può essere renderla meno costosa invece di eliminarla.
8. Tema e Custom Liquid: dove cerco il costo reale
Su Online Store 2.0 non controllo soltanto theme.liquid. Una personalizzazione può vivere in sezioni, snippet, asset, template JSON, app block o Custom Liquid salvato nelle impostazioni del template. Individuare la sorgente corretta evita di “ottimizzare” un file che non genera il problema.
Quando tocco il tema lavoro su una copia, confronto prima/dopo e faccio regression sulle funzioni collegate. Il miglioramento deve sopravvivere a mobile, varianti, ricerca, menu, carrello e tracking.
9. Il mio metodo di diagnosi performance
- Baseline: salvo metrica, URL, dispositivo e condizioni del test.
- Segmentazione: capisco se il problema riguarda home, prodotto, collezione o tutto il sito.
- Elemento/codice responsabile: isolo LCP, task JS, layout shift o richiesta sospetta.
- Ipotesi: definisco quale modifica dovrebbe incidere sulla causa.
- Intervento minimo: cambio una cosa alla volta quando possibile.
- Retest: ripeto il controllo in condizioni comparabili.
- Regression: verifico le funzioni principali dello store.
- Dati reali: quando disponibili, controllo l’andamento successivo nei report.
10. Cosa non prometto con un intervento performance
Non prometto un punteggio 100, una posizione Google o un aumento percentuale delle vendite. Performance, ranking e conversione dipendono da più fattori e non posso attribuire automaticamente una variazione a un singolo intervento.
Il risultato tecnico che posso verificare è diverso: identificare una causa, ridurne il costo senza rompere lo store e documentare il prima/dopo nelle condizioni testate.
11. Checklist prima di chiudere un lavoro di velocità Shopify
- URL e template problematici identificati.
- Baseline salvata prima della modifica.
- LCP/INP/CLS investigati separatamente.
- App e script analizzati senza rimozioni casuali.
- Immagini above-the-fold trattate diversamente da quelle sotto la piega.
- Modifica testata su mobile e desktop.
- Varianti, menu, ricerca, carrello e tracking verificati.
- Nessun contenuto utile nascosto soltanto per migliorare il punteggio.
- Nuovo test confrontabile con la baseline.
- Dati reali ricontrollati quando il volume lo permette.
Fonti ufficiali
Sono Francesco Guiducci, Shopify specialist freelance e sviluppatore di app Shopify. Se vuoi individuare il collo di bottiglia prima di modificare il tema, questi controlli rientrano nel mio Audit Shopify.
Aggiornato il 13 settembre 2026.
