Indice — 19 percorsiWeb Agency · Milano

My  Web  Lab

Guida operativa · Performance Web

Audit di performance: come testiamo e ottimizziamo i siti dei nostri clienti

Il nostro processo di audit performance in 5 fasi: misurazione baseline, identificazione colli di bottiglia, piano di ottimizzazione, implementazione e monitoraggio continuo.

Tempo di lettura: 14 min

Blog redesign · Performance Web

Audit di performance: come testiamo e ottimizziamo i siti dei nostri clienti

Un audit di performance è un'analisi sistematica delle metriche, del codice e dell'architettura di un sito per identificare e risolvere i problemi che lo rallentano. Il nostro processo in 5 fasi — misurazione baseline, analisi tecnica, prioritizzazione per impatto, implementazione, monitoraggio — porta mediamente i Core Web Vitals dei siti dei clienti da "Poor/Needs Improvement" a "Good" in 4-6 settimane. Il miglioramento medio che registriamo sul punteggio Lighthouse mobile è di 25-40 punti.

Perché fare un audit di performance: il business case

Un audit di performance non è un esercizio tecnico fine a se stesso: ha un impatto diretto sul business. Le ricerche di Google mostrano che ogni 100ms di miglioramento del tempo di caricamento aumenta le conversioni del 1%. Amazon ha calcolato che ogni 100ms di latenza costa l'1% di vendite. Per un e-commerce italiano che genera 200.000€/anno, ridurre il tempo di caricamento da 4 secondi a 1,5 secondi può valere 30.000-60.000€ di fatturato aggiuntivo. Il ROI dell'ottimizzazione tecnica è spesso il più alto disponibile nel marketing digitale.

Oltre alle conversioni, la performance impatta il SEO organico: le pagine con Core Web Vitals "Good" hanno un vantaggio di ranking rispetto a quelle "Poor" a parità di contenuto. Per i settori competitivi come finance, e-commerce e legal, dove molti competitor producono contenuti simili, la performance tecnica può essere il discriminante che porta il sito in prima posizione. Nei progetti di agenzia SEO che gestiamo, l'audit di performance è sempre la prima fase prima di qualsiasi attività di link building o content marketing.

Fase 1: misurazione baseline

Prima di toccare una riga di codice, misuriamo. Raccogliamo dati da PageSpeed Insights per le 10-20 URL più trafficate del sito, sia per mobile che desktop. Analizziamo Google Search Console (sezione "Esperienza pagina") per i dati reali degli utenti. Testiamo con GTmetrix dalla location di Frankfurt per simulare utenti europei. Tutto va in un foglio di calcolo: questa baseline è il punto di riferimento contro cui misureremo ogni miglioramento.

Le URL da includere nella baseline: homepage, 3-5 pagine di categoria o servizio, 3-5 pagine prodotto o post blog, pagina contatti/checkout. Per ogni URL registriamo: LCP, INP, CLS, FCP, TTFB, punteggio Lighthouse mobile, punteggio Lighthouse desktop, peso totale della pagina (KB), numero di richieste, e JavaScript iniziale (KB). Questa tabella diventa il report iniziale per il cliente e la roadmap delle ottimizzazioni.

Fase 2: analisi tecnica approfondita

Con i dati baseline in mano, analizziamo le cause tecniche. Per ogni URL con problemi: apriamo Chrome DevTools e registriamo il profilo di caricamento, identifichiamo le long task con il Performance panel, controlliamo il waterfall in Network per risorse render-blocking e request chain, e esaminiamo il Coverage per il JavaScript non utilizzato. Usiamo `@next/bundle-analyzer` per i siti Next.js per mappare il peso delle dipendenze.

Nella fase di analisi tecnica usiamo anche WebPageTest con la modalità "filmstrip": produce uno screenshot ogni 500ms durante il caricamento, mostrando esattamente cosa vede l'utente in ogni momento. Questo è particolarmente utile per identificare problemi di CLS (vedi quando il layout salta) e per comunicare al cliente il problema in modo visivo. Un video del caricamento su dispositivo mobile reale vale più di mille numeri in una tabella per convincere un cliente dell'urgenza dell'ottimizzazione.

I pattern problematici più frequenti che troviamo

  • Immagini non ottimizzate: JPEG da 2-5 MB serviti alle dimensioni originali senza srcset, senza WebP/AVIF (presente in ~80% dei siti analizzati)
  • JavaScript di terze parti sincrono nel <head>: analytics, chat widget, pixel marketing che bloccano il render per 300-600ms
  • CSS monolitico da 400-800 KB con >85% di regole inutilizzate (tipico dei temi WordPress generici e dei builder come Elementor/Divi)
  • Assenza di CDN: tutto il traffico colpisce il server di origine con TTFB >800ms da utenti fuori dalla regione del server
  • Query N+1 al database: ogni elemento di una lista fa una query separata, portando a 30-50 query per pagina
  • Font Google Fonts caricati da CDN esterna invece di self-hosted: DNS lookup aggiuntivo + FOUT
  • Mancanza di Cache-Control sugli asset statici: ogni visita ri-scarica CSS e JS anche se non cambiati
  • DOM eccessivamente grande: >3000 nodi DOM generati da builder visivi che impattano l'INP

Fase 3: prioritizzazione per impatto

Non tutti i problemi valgono uguale. Ordiniamo ogni intervento per il suo impatto stimato sulle metriche Core Web Vitals e per la difficoltà di implementazione. La matrice impatto/sforzo: interventi ad alto impatto e basso sforzo prima (ottimizzazione immagini, CDN, defer degli script), poi alto impatto/alto sforzo (refactoring CSS, ottimizzazione database), e per ultimi quelli a basso impatto relativo. Presentiamo al cliente un piano con stima di tempo e impatto atteso per ogni intervento.

Un esempio concreto di prioritizzazione che facciamo spesso: un sito e-commerce WordPress con LCP di 6 secondi. Le opportunità nell'ordine di impatto stimato: (1) Ottimizzare immagini in WebP/AVIF → stima -2s di LCP, effort 4 ore. (2) Attivare Cloudflare CDN e APO → stima -1,5s di LCP, effort 2 ore. (3) Defer degli script di terze parti → stima -0,8s LCP e -200ms INP, effort 3 ore. (4) CSS critico inline → stima -0,5s FCP, effort 4 ore. Totale: circa 13 ore di lavoro per passare da LCP 6s a 1,2s. Ogni ulteriore ottimizzazione (database, architettura) aggiunge sforzo con rendimenti decrescenti.

Fase 4: implementazione con test a ogni step

Implementiamo le ottimizzazioni una alla volta (o in gruppi logici) per poter misurare l'impatto di ciascuna. Dopo ogni cambiamento: deploy su staging, PageSpeed Insights sull'URL corrispondente, confronto con la baseline. Questo approccio incrementale permette di identificare casi in cui un'ottimizzazione teoricamente corretta peggiora le metriche in pratica — accade più spesso di quanto si pensi, specialmente con il CSS critico inline. Per i siti in realizzazione siti web ex novo, l'audit avviene prima del go-live.

Un caso reale: durante un'implementazione di CSS critico inline su un sito React, la prima versione del CSS estratto non includeva le regole per il font-face della font primaria. Risultato: LCP migliorato di 0,3s (come previsto), ma CLS peggiorato di 0,15 (inatteso) per un FOUT causato dal font non incluso nel critico. Senza il test incrementale avremmo potuto pubblicare in produzione un peggioramento del CLS. Il testing a ogni step non è burocrazia: è l'unico modo per sapere cosa sta davvero succedendo.

Tool stack completo per l'audit

  • PageSpeed Insights: dati CrUX + Lighthouse per ogni URL, punto di partenza per ogni audit
  • GTmetrix: waterfall dettagliata e test da Frankfurt con storico delle metriche nel tempo
  • WebPageTest: filmstrip video del caricamento, confronto A/B tra versioni, test su dispositivi reali
  • Chrome DevTools (Performance, Network, Coverage, Layers): analisi tecnica profonda, indispensabile per INP e long task
  • @next/bundle-analyzer: mappa visuale peso dipendenze JS per Next.js, identifica immediatamente i moduli pesanti
  • Lighthouse CI in GitHub Actions: verifica regressioni ad ogni PR, blocca deploy sotto soglia
  • Google Search Console: dati reali Core Web Vitals su 28 giorni, segmentati per URL e dispositivo
  • Vercel Analytics: Web Vitals per deployment in produzione, con comparazione tra deploy consecutivi
  • web-vitals npm library: misurazione INP, LCP, CLS in produzione inviata al tuo analytics custom

Risultati tipici dei nostri audit

I risultati variano in base al punto di partenza, ma i pattern sono consistenti. Siti WordPress con temi generici: LCP da 6-8s a 2-3s dopo ottimizzazione immagini, CDN e CSS critico. Siti Next.js con dipendenze non ottimizzate: INP da 400ms a 80ms dopo code splitting e defer degli script pesanti. E-commerce con catalogo immagini non ottimizzato: tempo caricamento pagina categoria da 4s a 1,2s. Ogni progetto è diverso, ma la metodologia è la stessa.

Un caso studio concreto: un cliente nel settore retail italiano con sito WordPress su hosting condiviso Aruba. Situazione iniziale: LCP mobile 7,2s, INP 480ms, CLS 0,28, punteggio Lighthouse mobile 34. Interventi eseguiti in 3 settimane: migrazione hosting a VPS Hetzner + Nginx + Redis, ottimizzazione immagini in WebP con ShortPixel, defer di tutti gli script di terze parti, CSS critico inline, rimozione 12 plugin inutilizzati. Risultato finale: LCP 2,1s, INP 145ms, CLS 0,04, punteggio Lighthouse mobile 88. Il traffico organico è cresciuto del 23% nei 3 mesi successivi all'ottimizzazione.

Fase 5: monitoraggio continuo

Le performance si degradano nel tempo. Ogni aggiornamento di plugin, nuovo script di marketing, o campagna pubblicitaria con tracking pesante può vanificare settimane di ottimizzazione. Per i clienti nel piano di gestione siti web impostiamo: alert automatici su Google Search Console per degradazioni nei Core Web Vitals, report mensile con andamento delle metriche, revisione trimestrale dell'audit completo. La performance non è un progetto finito: è una pratica continua.

Quando vale la pena fare un audit di performance

Un audit di performance ha ROI misurabile: studi di Google e Amazon mostrano correlazioni tra velocità e conversioni (ogni secondo di ritardo costa ~7% di conversioni). È particolarmente urgente se: il sito ha punteggio Lighthouse mobile sotto 50, Google Search Console segnala URL con stato "Poor", la bounce rate è alta (>70%) su mobile, o stai pianificando campagne a pagamento su traffico che poi arriva su landing page lente.

Dalla nostra esperienza a Milano, i settori dove l'impatto dell'ottimizzazione è più immediato e misurabile: e-commerce (conversioni dirette), studi legali e professionali (form di contatto), strutture ricettive (prenotazioni), e PMI con campagne Google Ads (Quality Score + conversion rate). In tutti questi settori il costo di un audit è recuperato nel giro di settimane dalle conversioni aggiuntive e dal risparmio in costo per clic sui Ads. Se vuoi capire l'impatto specifico per il tuo business, contattaci per un'analisi gratuita delle tue performance: valutiamo le 5 URL principali senza impegno e ti diamo una stima concreta del potenziale di miglioramento.

Articolo a cura diMy Web Lab — Agenzia Web Milano

Siamo un team di designer e sviluppatori specializzati in SEO, Next.js e crescita digitale per PMI italiane. Costruiamo siti che portano traffico reale e clienti reali.

Lavora con noi →

Risorse correlate

Tutte le guide →

Hai un progetto in mente?

Parliamone.

Contattaci ora