Ottimizzazione della Velocità del Sito per l'Ecommerce

Google misura l'esperienza della pagina attraverso tre Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Ogni metrica cattura un aspetto diverso dell'esperienza utente nel tuo negozio, e tutte e tre alimentano l'algoritmo di ranking di Google.

Il LCP misura quanto tempo impiega l'elemento visibile più grande a renderizzarsi, tipicamente un'immagine hero o una foto prodotto. Google si aspetta un LCP inferiore a 2,5 secondi. Per l'ecommerce, il principale responsabile è l'immagine prodotto non ottimizzata. Una singola immagine hero da 3 MB su una pagina categoria può portare il LCP oltre i 4 secondi sulle connessioni mobile.

L'INP ha sostituito il First Input Delay a marzo 2024 e misura la reattività durante l'intera sessione della pagina, non solo la prima interazione. Ogni tocco, clic e input da tastiera conta. I siti ecommerce faticano qui a causa del JavaScript pesante di strumenti di analytics, widget di chat e motori di raccomandazione. Ogni script di terze parti compete per il thread principale, ritardando le interazioni dell'utente.

Il CLS traccia gli spostamenti inattesi del layout durante il caricamento della pagina. Nelle pagine prodotto, questo succede comunemente quando le immagini si caricano senza dimensioni definite, quando i badge prezzo si inseriscono dopo il rendering iniziale, o quando le recensioni caricate in modo differito spingono il contenuto verso il basso. Google richiede un CLS inferiore a 0,1 per un punteggio sufficiente.

Le immagini rappresentano dal 50 % al 70 % del peso totale della pagina sulla maggior parte dei siti ecommerce. Una pagina categoria che mostra 40 prodotti con immagini non ottimizzate può superare facilmente i 15 MB. La corretta ottimizzazione delle immagini da sola può dimezzare il tempo di caricamento.

Converti tutte le immagini prodotto nel formato WebP o AVIF. Il WebP offre file dal 25 % al 35 % più piccoli rispetto al JPEG a qualità equivalente, e l'AVIF porta il risparmio al 50 %. Tutti i browser principali ora supportano il WebP, e il supporto AVIF copre oltre il 90 % degli utenti. Servi AVIF con fallback WebP usando l'elemento HTML picture.

Ridimensiona le immagini per corrispondere alle loro dimensioni di visualizzazione. Una miniatura prodotto mostrata a 300x300 pixel non necessita di un file sorgente 2000x2000. Genera dimensioni multiple al momento della build o tramite l'API di trasformazione immagini del tuo CDN. Servi immagini 1x ai display standard e 2x ai display Retina usando attributi srcset.

Implementa il lazy loading per le immagini sotto la piega. La prima riga di prodotti su una pagina categoria dovrebbe caricarsi immediatamente (caricamento eager), mentre tutto il resto dovrebbe usare loading="lazy". Questo riduce drasticamente il peso iniziale della pagina. Un negozio di mobili che abbiamo ottimizzato è passato dal caricare 80 immagini al caricamento iniziale a 12, riducendo il LCP da 4,8 secondi a 1,9 secondi.

Il negozio ecommerce medio carica da 20 a 35 script di terze parti: analytics, heatmap, widget di chat, piattaforme di recensioni, motori di raccomandazione, pixel di retargeting e fornitori di pagamento. Ogni script blocca il thread principale, ritarda l'interattività e gonfia il peso della pagina. Controllare e gestire questi script è uno dei miglioramenti di velocità con il maggiore impatto.

Inizia catalogando ogni script caricato nel tuo negozio. Apri Chrome DevTools, vai nella scheda Rete, filtra per JS e ricarica la pagina. Ordina per dimensione e tempo di caricamento. Quasi certamente troverai script non più necessari, tracker duplicati o strumenti installati per un test e mai rimossi.

Diferisci gli script non critici usando l'attributo defer o async. I pixel di analytics e marketing non devono caricarsi prima del rendering della pagina. Spostali sotto la piega o caricali dopo l'evento DOMContentLoaded. Per i widget di chat, ritarda l'inizializzazione fino a quando l'utente scorre o dopo un timeout di 5 secondi.

Considera l'uso di un tag manager come Google Tag Manager con caricamento basato su trigger. Invece di attivare ogni script al caricamento della pagina, configura i trigger in modo che i pixel di retargeting si attivino solo sulle pagine prodotto, i widget di chat carichino dopo 10 secondi di inattività e i widget di recensioni carichino solo quando la sezione recensioni entra nel viewport. Questo approccio ha ridotto il tempo di blocco del thread principale del 40 % in un negozio di arredamento che abbiamo ottimizzato.

Il Time to First Byte (TTFB) misura quanto tempo impiega il tuo server a rispondere con il primo byte di HTML. Google raccomanda un TTFB inferiore a 800 millisecondi, ma i migliori siti ecommerce raggiungono meno di 200 millisecondi. Un TTFB lento ritarda tutto ciò che segue: rendering, caricamento risorse e interattività.

I piani di hosting condiviso non possono fornire un TTFB costante per negozi con più di qualche centinaio di prodotti. Le query al database necessarie per costruire pagine categoria con filtri, ordinamento e verifiche di inventario richiedono risorse dedicate. Passa a un VPS, server dedicato o una piattaforma ecommerce gestita che gestisce lo scaling dell'infrastruttura.

Implementa il caching di pagina completa per le pagine categoria e prodotto. La maggior parte delle pagine prodotto cambia raramente, e servire una risposta HTML dalla cache elimina completamente le query al database. Varnish, Redis o il layer di cache integrato della tua piattaforma possono ridurre il TTFB da 1,5 secondi a meno di 100 millisecondi per le pagine in cache.

Usa un CDN con cache perimetrale per servire asset statici e pagine in cache da posizioni vicine ai tuoi clienti. Un CDN riduce la latenza dal 50 % all'80 % per i visitatori geograficamente distanti. Per i negozi internazionali, questo è essenziale. Un cliente britannico che accede a un negozio ospitato negli USA senza CDN aggiunge da 150 a 250 millisecondi di latenza per ogni richiesta.

Il percorso di rendering critico è la sequenza di passaggi che il browser compie per convertire HTML, CSS e JavaScript in pixel renderizzati. Ottimizzare questo percorso significa assicurare che il browser possa mostrare contenuto significativo il più rapidamente possibile, anche mentre risorse aggiuntive si stanno ancora caricando.

Inserisci il tuo CSS critico direttamente nell'head HTML. Il CSS critico è il set minimo di stili necessario per renderizzare il contenuto sopra la piega. Strumenti come Critical o Penthouse possono estrarlo automaticamente. Inserendo da 10 a 15 KB di CSS critico inline, il browser può dipingere la vista iniziale senza attendere il download di fogli di stile esterni.

Precarica le risorse chiave che il browser scopre tardi nel processo di analisi. I web font, le immagini hero e i bundle JavaScript critici dovrebbero usare tag link rel="preload" nell'head HTML. Senza precaricamento, il browser scopre queste risorse solo dopo aver analizzato file CSS o JavaScript, aggiungendo centinaia di millisecondi di ritardo.

Elimina le risorse che bloccano il rendering differendo CSS e JavaScript non critici. Carica il tuo foglio di stile completo in modo asincrono usando il trucco media="print" con un gestore onload che lo cambia in media="all". Questo permette al browser di renderizzare la pagina usando il CSS critico inline mentre il foglio di stile completo si scarica in background.

Per i negozi Shopify, i template Liquid del tema e i blocchi delle app spesso iniettano script e stili che bloccano il rendering. Controlla il tuo file theme.liquid e sposta gli script delle app non essenziali al caricamento differito. Ogni risorsa che blocca il rendering aggiunge da 100 a 300 millisecondi al rendering iniziale.