Ottimizzazione della velocità su Shopify: da 4,8 s a 1,2 s, e cosa l'ha fatta davvero

A ogni proprietario di negozio è stato detto che il suo sito è lento, e a molti è stato mostrato uno screenshot di PageSpeed come prova. Il problema non è lo screenshot. Il problema è che il lavoro sulla velocità ha una lunga coda di modifiche da 20 ms l'una e una testa corta di modifiche che valgono interi secondi — e di solito si affrontano nell'ordine sbagliato.

MioMio è passato da 4,8 s a 1,2 s. Quattro volte più veloce su mobile. Ecco cosa stava nella testa di quella distribuzione, più o meno in ordine di resa.

1. Strategia di rendering — il singolo guadagno maggiore

La vecchia vetrina renderizzava lato client. Il visitatore scaricava un guscio HTML, poi un bundle JavaScript, poi aspettava che il bundle chiedesse il catalogo, poi aspettava di nuovo le immagini implicate da quella richiesta. Quattro giri sequenziali prima che comparisse qualcosa di significativo.

Il rendering lato server li comprime in uno. La prima risposta contiene già la griglia prodotti, i testi e gli URL delle immagini. Il browser può iniziare a scaricare le immagini mentre JavaScript è ancora in download, perché le vede nel markup.

Non è una micro-ottimizzazione, e nessuna sforbiciata al bundle la sostituisce. Una pagina di catalogo renderizzata lato client ha un pavimento fissato dalla profondità della propria cascata di richieste. Il rendering lato server toglie il pavimento.

2. Immagini — il guadagno maggiore in byte

Su un catalogo di moda le immagini sono circa l'80% dei byte trasferiti. Tre modifiche, in ordine decrescente di valore:

• →Formati moderni. WebP contro JPEG ottimizzato è una riduzione del 25-35% a qualità visivamente identica. È una modifica alla build, non al design.
• →Dimensioni corrette. Servire un master da 2000px in uno spazio da 400px spreca circa il 96% dei pixel. Un srcset responsive per breakpoint lo risolve una volta e ovunque.
• →Lazy loading onesto. Tutto sotto la piega prende loading="lazy". Tutto sopra, esplicitamente no: caricare in lazy l'immagine hero è una penalità LCP autoinflitta, ed è frequente.

Accompagna sempre il tutto con dimensioni esplicite o un aspect-ratio. Le immagini che arrivano senza spazio riservato causano spostamenti di layout, e il CLS è il Core Web Vital più economico da correggere e quello più spesso lasciato rotto.

<img
  src="/hero.webp"
  alt="Campagna autunnale"
  width="1600" height="900"
  fetchpriority="high"
/>

3. Script di terze parti — la tassa invisibile

Una vetrina tipica porta analytics, un widget CRM, una chat, uno o due pixel e una piattaforma di recensioni. Presi singolarmente sono tutti «leggeri». Insieme bloccano il thread principale più dell'intera applicazione.

Qui passano da Partytown, che sposta gli script di terze parti in un web worker. Il thread principale smette di competere con una chat per il diritto di disegnare la pagina. Dove uno script non è spostabile, viene rimandato alla prima interazione.

Prima di ricorrere agli strumenti, fai la versione gratuita di questo audit: elenca ogni script di terze parti e per ciascuno indica la persona che si accorgerebbe se sparisse. Gli script senza proprietario sono il guadagno più rapido disponibile, perché eliminarli non costa nulla.

4. Font — pochi byte, molto blocco

I web font sono raramente un problema di banda e spesso un problema di blocco. Un font caricato con un @import CSS viene scoperto solo dopo il parsing del foglio di stile, il che mette un giro di rete in serie con il rendering.

• →Preconnect all'origine dei font, così l'handshake TLS avviene in parallelo invece che su richiesta.
• →Carica i font con <link> nell'head del documento, non con @import dentro il CSS.
• →Usa font-display: swap, così il testo compare subito con un fallback invece di tenere in ostaggio il rendering.
• →Riduci ai set di caratteri realmente usati. Un sito con cirillico e latino non ha bisogno degli interi range greco e vietnamita.

5. Cache e distribuzione

Gli asset statici — immagini, font, bundle con hash — prendono una cache immutabile di un anno. L'hash nel nome del file rende automatica l'invalidazione, quindi non c'è ragione di essere prudenti:

Cache-Control: public, max-age=31536000, immutable

Una CDN davanti a tutto questo avvicina fisicamente i byte al visitatore. Per un negozio ucraino con clienti ucraini conta meno di quanto suggerisca il marketing — ma per lo stesso negozio con traffico europeo è la differenza fra 40 ms e 300 ms su ogni asset.

Misurare la cosa giusta

PageSpeed Insights esegue un test di laboratorio su hardware simulato. È uno strumento di diagnosi, non un tabellone. Google posiziona sui dati di campo — Core Web Vitals raccolti da utenti Chrome reali, su dispositivi e reti reali.

I due divergono di continuo. Un punteggio di laboratorio di 95 con un LCP di campo fallito significa che gli utenti reali hanno hardware più lento e connessioni peggiori della simulazione. Fidati dei dati di campo e usa il laboratorio per capire il perché.

Vale la pena guardare tre numeri: LCP sotto 2,5 s, INP sotto 200 ms, CLS sotto 0,1. Tutto il resto è dettaglio diagnostico al servizio di questi tre.

Quanto vale davvero la velocità

Il beneficio dei Core Web Vitals sul posizionamento è reale ma modesto — un criterio di spareggio fra risultati comparabili più che una leva. Il beneficio sulla conversione non è né modesto né sottile. Su questo progetto il caricamento sceso da 4,8 s a 1,2 s ha coinciso con un +25% di conversione nel primo trimestre, insieme a un rebranding.

La formulazione onesta è questa: la velocità raramente vince posizioni da sola, e porta con affidabilità fatturato dal traffico che hai già. Ottimizza per il secondo e accetta il primo come bonus.