Gli indicatori di prestazione web sono diventati un passaggio obbligato degli audit, e spesso producono liste interminabili di raccomandazioni la cui metà non ha alcun effetto misurabile. Su un negozio PrestaShop, cinque cantieri concentrano l’essenziale del guadagno disponibile.
Misurare dove serve
Punto preliminare, e cambia tutto.
Gli strumenti di audit eseguono un test unico in condizioni simulate. Sono utili per diagnosticare, non misurano ciò che vivono i tuoi visitatori.
I dati di campo, raccolti sulle visite reali, sono quelli che contano. Sono accessibili nel rapporto dedicato della Search Console, e spesso differiscono nettamente dai risultati di laboratorio.
Tre ragioni per questo scarto: i tuoi visitatori hanno dispositivi e connessioni vari, arrivano su pagine diverse da quella che testi, e una parte di loro naviga con una cache già calda.
Il metodo: diagnostica in laboratorio, decidi sul campo. Un problema visibile in test ma assente dai dati reali non è prioritario.
Cantiere 1: l’immagine principale della scheda prodotto
È quasi sempre l’elemento che determina il tuo indicatore principale di caricamento, ed è il cantiere più redditizio.
Quattro azioni, in ordine di effetto.
Non caricarla in differita. L’immagine visibile all’arrivo deve caricarsi immediatamente. Un caricamento differito applicato a tutte le immagini senza distinzione ritarda proprio quella che conta.
Precaricarla, segnalando al browser che è prioritaria. Così parte ancora prima dell’analisi completa della pagina.
Servire la dimensione giusta. Un’immagine da 2000 pixel mostrata a 600 spreca diverse centinaia di kilobyte. I formati adattivi risolvono il caso.
Usare un formato moderno, che riduce il peso dal 30 al 50% a qualità percepita equivalente.
Queste quattro azioni si trattano in una giornata e producono in genere il guadagno più visibile di tutto il lavoro sulle prestazioni.
Cantiere 2: la stabilità visiva
Il secondo cantiere per redditività, perché le cause sono poche e facili da identificare.
Cinque fonti di spostamento su un negozio.
Le immagini senza dimensioni dichiarate. Il browser non riserva lo spazio e il contenuto salta quando l’immagine arriva. Dichiarare larghezza e altezza basta.
I banner inseriti dopo il caricamento: cookie, promozioni, annunci. Riserva il loro spazio o mostrali in sovrapposizione.
I font personalizzati. Il testo appare prima in un font sostitutivo, poi cambia, il che sposta l’impaginazione. Un precaricamento e un’impostazione di visualizzazione adeguata limitano l’effetto.
I blocchi dei moduli caricati in asincrono: recensioni, prodotti simili, chat. Ognuno spinge il contenuto che lo segue.
La pubblicità e le integrazioni di terze parti, la cui altezza varia.
Metodo di diagnosi: apri una scheda prodotto con gli strumenti di sviluppo, attiva l’indicatore di spostamento del layout e ricarica. Le zone che si muovono appaiono immediatamente.
Cache di Pagina e Ottimizzazione Velocità PrestaShop 8 e 9Cache di pagina, Critical CSS e ottimizzazione avanzata per PrestaShop 8 e 9.€149.00
Cantiere 3: la reattività alle interazioni
È l’indicatore più recente e il peggio trattato sui negozi, perché le sue cause sono meno evidenti.
Misura il tempo tra un’azione del visitatore e la risposta visibile. Su un negozio, tre interazioni concentrano i problemi.
I filtri a faccette, quando l’elaborazione della selezione blocca il thread di esecuzione prima ancora della richiesta di rete.
L’aggiunta al carrello, quando innesca diverse elaborazioni sincrone prima del riscontro visivo.
L’apertura del menu su mobile, se il menu viene costruito al momento del clic invece che al caricamento.
Tre correzioni, applicabili senza rifacimenti.
Dare un riscontro visivo immediato, prima dell’elaborazione. Un pulsante che cambia stato al clic migliora l’indicatore anche se l’elaborazione dura lo stesso tempo.
Spezzare le elaborazioni lunghe per ridare la mano al browser tra due passaggi.
Ridurre il codice eseguito al clic, in particolare gli script di terze parti agganciati agli stessi eventi.
Cantiere 4: il tempo di risposta del server
Condiziona tutti gli altri indicatori: nulla può apparire prima che il server abbia risposto.
Tre leve, in ordine di effetto su PrestaShop.
La cache di pagina completa. Trasforma una generazione dinamica nel servizio di un file pronto. È il guadagno più importante sulle pagine categoria e prodotto.
La cache applicativa, sui dati di catalogo, che evita di ricalcolare ciò che non è cambiato.
L’ottimizzazione delle query più lente, identificate nel log del database.
Due precauzioni sulla cache di pagina. Deve essere invalidata correttamente ai cambi di prezzo e di stock, pena la visualizzazione di informazioni false. E deve escludere le pagine personalizzate: carrello, account, checkout.
Punto spesso trascurato: la cache serve solo i visitatori che arrivano dopo il primo. Su un catalogo di diecimila pagine con un traffico moderato, gran parte delle visite resta non in cache. La generazione anticipata della cache, sulle pagine più visitate, tratta questo punto.
Cantiere 5: gli script di terze parti
Il cantiere più ingrato e spesso il più redditizio.
Un negozio medio carica tra otto e venti script esterni: analytics, pubblicità, chat, recensioni, cookie, mappe. Ognuno è stato aggiunto per una buona ragione e nessuno è mai stato tolto.
Tre azioni.
Inventariare. Elenca gli script caricati su una scheda prodotto, con peso e tempo di esecuzione. Gli strumenti di sviluppo lo danno in pochi minuti.
Eliminare ciò che non serve più. Troverai quasi sempre uno strumento di analisi abbandonato o un pixel di una campagna terminata.
Differire ciò che resta. Una chat, uno strumento di recensioni o una misurazione secondaria non hanno bisogno di caricarsi prima della visualizzazione del contenuto.
Aggiungi un punto di governance: condiziona gli script pubblicitari al consenso, cosa comunque obbligatoria, con l’effetto secondario di alleggerire la pagina per chi rifiuta.
Ciò che non serve a nulla
Quattro raccomandazioni frequenti il cui effetto è nullo o marginale su un negozio.
Minificare l’HTML. Il guadagno si conta in kilobyte, invisibile di fronte al peso delle immagini.
Ridurre il numero di richieste a ogni costo. Questa raccomandazione risale ai protocolli vecchi. Sui protocolli attuali, il multiplexing rende il numero di richieste molto meno determinante.
Eliminare tutti i font personalizzati. Un font ben caricato costa poco e serve la tua identità. Il problema è il modo di caricamento, non il font.
Puntare al cento su cento in uno strumento di audit. Il punteggio non è l’obiettivo, le soglie di campo sì.
L’ordine e il ritmo
Una sequenza su tre mesi.
Settimana 1: rilevazione dei dati di campo, per tipo di pagina, per sapere dove sei davvero.
Settimane 2 e 3: cantieri 1 e 2, immagine principale e stabilità visiva. Sono i più rapidi e i più visibili.
Settimane da 4 a 6: cantiere 4, cache server, che richiede test e un’invalidazione curata.
Settimane 7 e 8: cantiere 5, inventario e pulizia degli script di terze parti.
Poi: cantiere 3, reattività, che è il più tecnico e il cui effetto si misura sulla durata.
Un punto di metodo: i dati di campo si basano su una finestra scorrevole di diverse settimane. Non trarre conclusioni prima di un mese da una modifica.
Il modulo Cache di Pagina e Ottimizzazione Velocità per PrestaShop copre il quarto cantiere su PrestaShop 8 e 9: cache di pagina completa con invalidazione ai cambi di prezzo e di stock, esclusione automatica delle pagine personalizzate, generazione anticipata sulle pagine più visitate e caricamento differito degli script non critici.
