Un e-commerce di moda con cinque mercati attivi arriva da noi con un problema semplice da enunciare: la pagina prodotto impiega quasi tre secondi a mostrare l'immagine principale, e il tasso di abbandono su mobile è il doppio di quello su desktop. La domanda del cliente era: quanto costa risolverlo?
La risposta onesta è che non si sa finché non si misura, e che quasi sempre il novanta per cento del miglioramento viene da due o tre interventi. Il resto è lavoro che fa sentire bene chi lo scrive e non sposta niente per chi usa il sito.
Dove si perdeva il tempo
Abbiamo preso i dati di campo dal browser degli utenti reali, non solo il laboratorio. Il laboratorio dice cosa succede su una macchina in condizioni ideali; i dati di campo dicono cosa succede a un cliente con un telefono di tre anni fa su rete mobile in centro città.
| Metrica | Prima (p75) | Dopo (p75) |
|---|---|---|
| LCP — comparsa dell'immagine prodotto | 2,91 s | 1,08 s |
| INP — risposta al tocco sul filtro | 412 ms | 84 ms |
| CLS — spostamento del layout | 0,24 | 0,01 |
| JavaScript scaricato | 1.180 kB | 310 kB |
Le tre modifiche che hanno pesato
Le immagini arrivavano in formato sbagliato
Il catalogo serviva JPEG a piena risoluzione ridimensionati via CSS: 800 kB per una foto che sullo schermo occupava 380 pixel. Abbiamo introdotto AVIF con ripiego su WebP, dimensioni multiple servite in base alla larghezza reale del dispositivo, e il caricamento prioritario solo sulla prima immagine. Da sola, questa modifica ha tolto 1,2 secondi.
Il font veniva caricato due volte
Un tema ereditato importava la famiglia tipografica dal CSS e un componente la richiedeva di nuovo con un tag proprio. Il browser scaricava due volte lo stesso file e mostrava il testo solo alla fine. Una riga rimossa e un font-display impostato correttamente hanno eliminato mezzo secondo di attesa e quasi tutto lo spostamento del layout.
Gli script di terze parti bloccavano l'interazione
Sette tag di analisi e marketing partivano tutti al caricamento, sul filo principale. Ne abbiamo tenuti tre, spostati dopo il primo disegno della pagina e caricati in un worker separato dove possibile. Il tempo di risposta al tocco è passato da 412 a 84 millisecondi.
Quello che non ha funzionato
Abbiamo provato anche il rendering lato server dei filtri, il precaricamento speculativo delle pagine prodotto e la compressione Brotli a livello massimo. Insieme hanno prodotto meno di centocinquanta millisecondi, contro giorni di lavoro. Sono rimasti fuori dalla consegna e lo abbiamo scritto nel rapporto.
Se una modifica non si vede nei dati di campo entro due settimane dal rilascio, non era una modifica di performance: era una preferenza tecnica.
Il budget, per non tornare indietro
Un sito veloce torna lento in sei mesi se nessuno lo controlla. Abbiamo messo una soglia nella pipeline: se un rilascio supera il peso concordato o peggiora le metriche oltre una certa percentuale, la build si ferma e chi ha aperto la modifica riceve il confronto.
# budget applicato a ogni pull request budgets: - resourceType: script maxSize: 340 kB - resourceType: image maxSize: 180 kB # per immagine - metric: LCP maxValue: 1800 ms - metric: CLS maxValue: 0.05 onFailure: block-merge
Il risultato commerciale
Sei settimane dopo il rilascio, il tasso di conversione da mobile è salito del trentaquattro per cento e il tasso di abbandono sulla pagina prodotto è sceso di diciannove punti. Non attribuiamo tutto alla velocità — nello stesso periodo è cambiata anche la fotografia di prodotto — ma il segmento su rete lenta, che non ha visto altre differenze, è migliorato in modo comparabile.
RAG in produzione: perché i prototipi non arrivano agli utentiArticolo successivo Leggi l'articoloAvete un progetto in mente?
La prima chiamata è tecnica e dura mezz'ora. Capiamo se possiamo essere utili, e ve lo diciamo anche quando la risposta è no.