Il contesto: un e-commerce che perdeva clienti senza saperlo
Un e-commerce con circa 3.000 prodotti, costruito in PHP con un framework custom ormai datato, aveva tempi di caricamento medi di 4.8 secondi. Il cliente si era accorto del problema quando ha notato un calo progressivo delle vendite negli ultimi 6 mesi, nonostante il traffico fosse rimasto stabile. Il tasso di abbandono del carrello era salito al 78% e Google aveva iniziato a penalizzare il sito nei risultati di ricerca, con un calo del 22% nel traffico organico.
Il primo tentativo del cliente era stato cambiare hosting, passando da un shared hosting a un VPS con piu risorse. Risultato: da 5.1 secondi a 4.8 secondi. Un miglioramento irrilevante che confermava quello che sospettavo: il problema non era il server, ma il codice. Mi ha contattato come sviluppatore PHP freelance per un audit tecnico completo, con un obiettivo chiaro: scendere sotto i 2 secondi di caricamento senza riscrivere l intero applicativo.
L audit tecnico: come ho identificato i colli di bottiglia
Ho condotto l audit in 3 fasi. Prima fase: profiling delle pagine critiche (homepage, listing di categoria, scheda prodotto, checkout) usando strumenti come Chrome DevTools, GTmetrix e query logging sul database. Seconda fase: analisi del codice PHP con focus sulle query generate per ogni pagina. Terza fase: analisi degli asset statici (immagini, CSS, JavaScript).
I tre problemi principali emersi dall audit
L audit ha rivelato tre colli di bottiglia che da soli causavano l 85% della lentezza:
- Query SQL senza indici: la pagina di listing eseguiva una query con filtri su categoria, prezzo e disponibilita. Nessuno di questi campi aveva un indice. Ogni query faceva un full table scan su 3.000 righe con 4 JOIN. Tempo medio: 1.2 secondi per query, con 6-8 query per pagina
- Nessun sistema di cache: ogni pagina veniva rigenerata da zero ad ogni richiesta. Il catalogo prodotti cambiava forse 2-3 volte al giorno, ma il server ricalcolava tutto migliaia di volte
- Immagini non ottimizzate: le foto prodotto venivano servite nel formato originale (JPEG da 2-4MB) ridimensionate via CSS. Nessun lazy loading, nessuna conversione in formati moderni
L intervento: cosa ho fatto concretamente
Ottimizzazione del database
Ho analizzato le query piu lente con EXPLAIN e ho aggiunto indici composti sui campi piu interrogati: (category_id, is_available, price) per i listing e (slug) per le schede prodotto. Ho riscritto le JOIN nella pagina di listing per ridurre il numero di query da 8 a 2, usando subquery ottimizzate. Il tempo medio di risposta del database e passato da 1.2 secondi a 45 millisecondi per query.
Implementazione della cache
Ho implementato un sistema di cache a due livelli. Il primo livello e una cache delle query di catalogo con chiave basata sui parametri di filtro, con TTL di 1 ora e invalidazione automatica su ogni operazione di scrittura (inserimento prodotto, modifica prezzo, cambio disponibilita). Il secondo livello e una cache delle pagine HTML per i visitatori non autenticati, con invalidazione granulare per categoria. Risultato: il 90% delle richieste viene servito dalla cache senza toccare il database.
Ottimizzazione degli asset
Ho scritto uno script PHP che ha processato tutte le 3.000 immagini prodotto in batch: conversione in WebP con fallback JPEG, generazione di 3 dimensioni per ogni immagine (thumbnail, listing, full) e implementazione del lazy loading nativo con attributo loading="lazy". Ho anche abilitato la compressione Gzip sul server e configurato header di cache per gli asset statici con scadenza a 30 giorni.
Quanto e costato in termini di tempo
L intero intervento ha richiesto 4 giorni di lavoro distribuiti su una settimana:
- Giorno 1: audit completo e report con priorita di intervento
- Giorno 2: ottimizzazione database (indici, riscrittura query)
- Giorno 3: implementazione sistema di cache
- Giorno 4: ottimizzazione immagini, compressione, test e deploy
Non ho riscritto una riga di logica di business. Ho lavorato esclusivamente sulle performance, toccando i punti con il massimo impatto e il minimo rischio.
Risultati misurabili
- Tempo medio di caricamento: da 4.8 secondi a 1.9 secondi (riduzione del 60%)
- Core Web Vitals tutti in zona verde dopo 2 settimane dalla messa in produzione
- Largest Contentful Paint (LCP): da 4.2s a 1.4s
- Cumulative Layout Shift (CLS): da 0.25 a 0.04
- Traffico organico aumentato del 35% nei 3 mesi successivi all intervento
- Tasso di conversione migliorato del 18% — piu vendite con lo stesso traffico
- Peso medio della pagina: da 4.2MB a 680KB
- Tasso di abbandono carrello: dal 78% al 61%
Il ROI dell ottimizzazione delle performance
Il cliente vendeva in media 40 ordini al giorno con uno scontrino medio di 85 euro. L aumento del 18% nel tasso di conversione ha significato circa 7 ordini in piu al giorno, ovvero 595 euro di fatturato aggiuntivo quotidiano. Il costo dell intero intervento si e ripagato nel primo mese. A 3 mesi dall intervento il cliente ha stimato un incremento netto di circa 45.000 euro di fatturato attribuibile alle performance migliorate.
Cosa rende un e-commerce veloce?
Dalla mia esperienza come sviluppatore PHP, i fattori che impattano di piu sulle performance di un e-commerce sono, in ordine di importanza: query database ottimizzate con indici corretti, un sistema di cache efficace con invalidazione granulare, immagini ottimizzate in formati moderni e un hosting adeguato al traffico. Notare che l hosting e ultimo: nella maggior parte dei casi il collo di bottiglia e il codice, non il server. Un audit tecnico mirato costa una frazione del cambio di hosting e produce risultati incomparabilmente superiori.