Un sito web lento allontana i visitatori prima ancora che abbiano visto cosa offri. I dati sono noti: oltre la metà degli utenti abbandona un sito se il caricamento supera i tre secondi. Ma quando il tuo sito è lento, come fai a capire qual è la causa?
Il problema può essere l'hosting, le immagini, il codice, o — molto spesso — una combinazione di tutti e tre. In questo articolo vediamo come diagnosticare ogni componente con strumenti gratuiti e parametri oggettivi, senza fare supposizioni.
Prima di tutto: misurare le prestazioni attuali
Prima di cambiare qualunque cosa, serve un dato di partenza. Non si può migliorare quello che non si misura.
Strumenti di analisi
- PageSpeed Insights (Google): analizza un URL e restituisce un punteggio da 0 a 100 per mobile e desktop, con suggerimenti specifici su cosa migliorare. È il punto di partenza standard per qualsiasi diagnosi.
- GTmetrix: mostra waterfall dettagliato di tutte le richieste del sito, con tempi di caricamento per ogni risorsa (HTML, CSS, JavaScript, immagini, font).
- WebPageTest: permette test da diverse località del mondo e tipi di connessione (3G, 4G, fibra). Utile per capire se la lentezza è geografica o legata alla connessione.
Parametri da osservare
- First Contentful Paint (FCP): quando il primo contenuto visibile appare a schermo. Obiettivo: sotto 1,8 secondi.
- Largest Contentful Paint (LCP): quando il contenuto principale della pagina è visibile. Obiettivo: sotto 2,5 secondi.
- Total Blocking Time (TBT): quanto tempo la pagina resta bloccata durante il caricamento. Obiettivo: sotto 200 millisecondi.
- Cumulative Layout Shift (CLS): quanto gli elementi si spostano durante il caricamento. Obiettivo: sotto 0,1.
Se uno di questi parametri è significativamente fuori soglia, hai già un indizio su dove cercare.
Diagnosi 1: il problema è l'hosting?
L'hosting è spesso il primo sospettato, ma non sempre il colpevole. Ecco come verificarlo.
Segnali di un hosting inadeguato
- Il sito è lento in modo uniforme su tutte le pagine, indipendentemente dal contenuto
- I tempi di risposta del server (TTFB — Time to First Byte) superano 500 ms
- Il sito subisce rallentamenti nelle ore di punta (tipico dell'hosting condiviso)
- Altri siti sullo stesso server (se è un hosting condiviso) influenzano le prestazioni del tuo
Come testare
TTFB: PageSpeed Insights e GTmetrix mostrano il tempo di risposta del server. Un TTFB inferiore a 200 ms è eccellente; tra 200 e 500 ms è accettabile; sopra i 500 ms indica un problema server-side.
Test di carico: strumenti come K6 (open source) o Loader.io (gratuito fino a 10.000 utenti) simulano traffico simultaneo. Se il sito collassa con 20 visitatori simultanei, l'hosting condiviso è probabilmente il collo di bottiglia.
Confronto località: WebPageTest permette di testare il sito da più località. Se il tuo pubblico è in Ticino ma il server è in USA, i 100-150 ms di latenza transatlantica si sommano a ogni richiesta. La soluzione è un CDN (Content Delivery Network) o un server in Europa.
Possibili soluzioni
- Passaggio da hosting condiviso a VPS o server dedicato: 30 – 150 CHF/mese in Svizzera
- Implementazione di una CDN (Cloudflare, BunnyCDN): da gratis a 20 CHF/mese
- Passaggio a un hosting ottimizzato per il CMS utilizzato (es. hosting WordPress-managed)
- Server geograficamente più vicino al tuo pubblico
Diagnosi 2: il problema sono le immagini?
Le immagini sono la causa più comune di lentezza nei siti web. Un'immagine non ottimizzata può pesare 2-3 MB, mentre la stessa immagine ottimizzata può pesare 100-200 KB con una qualità visiva praticamente identica.
Segnali di immagini problematiche
- Le immagini sono caricate a dimensioni piene (4000x3000 px) ma visualizzate in thumbnail (300x200 px)
- Il formato è JPEG non ottimizzato o PNG non compresso
- Le immagini non hanno dimensioni esplicite (width/height), causando CLS
- I waterfall di GTmetrix mostrano richieste di immagini molto pesanti che bloccano il rendering
Come testare
- PageSpeed Insights segnala esplicitamente "Serve images in next-gen formats" (WebP, AVIF) e "Properly size images"
- GTmetrix mostra il peso di ogni immagine nel waterfall
- Squoosh (squoosh.app): strumento gratuito di Google per comprimere immagini e convertirle in WebP
- Lighthouse (integrato in Chrome DevTools): nella sezione "Opportunities" elenca le immagini ottimizzabili
Buone pratiche
- Formato WebP o AVIF invece di JPEG/PNG (risparmio del 30-50% senza perdita di qualità percepita)
- Ridimensionamento lato server: l'immagine deve essere grande quanto serve a schermo, non di più
- Lazy loading (caricamento differito): le immagini visibili solo dopo lo scroll vengono caricate quando servono, non all'apertura della pagina
- Attributi width e height espliciti per prevenire layout shift
Diagnosi 3: il problema è il codice?
Il codice frontend (HTML, CSS, JavaScript) può rallentare il sito in modi meno evidenti ma altrettanto impattanti.
Segnali di codice inefficiente
- JavaScript pesante che blocca il rendering (render-blocking resources)
- CSS non minimizzato o con regole ridondanti
- Plugin o script di terze parti che caricano risorse extra (analytics, pixel, chat, mappe)
- JavaScript eseguito prima che la pagina sia visibile
- Framework frontend sovradimensionati per pagine semplici
Come testare
- Coverage tab in Chrome DevTools (F12 → Ctrl+Shift+P → "Coverage"): mostra quanta percentuale di CSS e JavaScript caricato viene effettivamente utilizzata. Se usi solo il 20% del CSS caricato, stai sprecando larghezza di banda.
- PageSpeed Insights segnala "Render-blocking resources" e "Unused JavaScript/CSS"
- Lighthouse elenca specificamente "Eliminate render-blocking resources" con i file da differire
- WebPageTest mostra l'impact dei singoli script sul tempo di caricamento
Possibili interventi
- Minificazione di CSS, JavaScript e HTML (strumenti: Terser per JS, CleanCSS o cssnano per CSS)
- Differimento del JavaScript non critico (attributi defer o async)
- Caricamento condizionale degli script di terze parti (caricare solo dopo l'interazione dell'utente)
- Eliminazione di plugin/script non utilizzati
- Code splitting: caricare solo il codice necessario per la pagina corrente
Esempi pratici: scenari tipici
Scenario 1 — E-commerce su hosting condiviso. Un negozio online carica in 8 secondi su mobile con TTFB di 1,2 secondi. Dopo il passaggio a un VPS con CDN, il tempo di caricamento si riduce a circa 3,5 secondi. Il miglioramento principale viene dalla componente server-side.
Scenario 2 — Sito aziendale con immagini fuori scala. Una homepage con 5 immagini di dimensioni originali (2-3 MB ciascuna) può pesare 14 MB complessivi. Convertendo in WebP e ridimensionando alle dimensioni effettive di visualizzazione, il peso scende a circa 1,2 MB e il tempo di caricamento da 6 a circa 2 secondi.
Scenario 3 — Sito con molti plugin attivi. Una homepage che carica 30 plugin può impiegare 5 secondi. Disattivando quelli non essenziali e ottimizzando il caricamento differito dei restanti, il tempo si riduce a circa 2 secondi e il JavaScript passa da centinaia di KB a meno di 200 KB.
Diagnosi rapida in 5 minuti
- Apri PageSpeed Insights, inserisci l'URL del tuo sito
- Controlla il TTFB: sopra i 500 ms → probabile problema di hosting
- Cerca "Serve images in next-gen formats" e "Properly size images" → problema immagini
- Cerca "Reduce unused JavaScript/CSS" e "Eliminate render-blocking resources" → problema codice
- Se TTFB è buono ma immagini e codice sono ok → testa su WebPageTest da più località
FAQ
Come faccio a sapere se il mio hosting è troppo economico?
Se il tuo sito costa meno di 10 CHF/mese di hosting, è probabile che sia su un server condiviso con decine o centinaia di altri siti. Il test TTFB nelle ore di punta è il modo più rapido per verificarlo.
WebP è supportato da tutti i browser?
Sì, WebP è supportato da Chrome, Firefox, Safari (dal 2020), Edge e Opera. Per browser molto datati (IE11), si usa il formato JPEG/PNG come fallback.
Quanti plugin/script di terze parti sono troppi?
Non esiste un numero preciso, ma ogni script di terze parti aggiunge richieste HTTP e JavaScript. Se un sito ha più di 10 script di terze parti (analytics, pixel, chat, recensioni, mappe), è quasi certo che alcuni siano sostituibili o caricabili in modo differito.
Meglio un hosting economico o una CDN?
Non sono alternativi. Se hai un hosting economico ma implementi una CDN, i file statici (immagini, CSS, JS) saranno serviti velocemente dalla CDN, ma le richieste dinamiche (PHP, database) resteranno lente. Se il tuo sito ha molto contenuto dinamico, l'hosting va potenziato indipendentemente dalla CDN.
CTA
La lentezza di un sito web ha sempre una causa precisa. Identificarla è il primo passo per risolvere il problema. Se vuoi una diagnosi professionale del tuo sito, contattaci per un audit gratuito delle prestazioni.
Fonti
- Google PageSpeed Insights Docs — sito developers.google.com/speed/docs/insights
- WebPageTest Documentation — sito webpagetest.org/docs
- GTmetrix Knowledge Base — sito gtmetrix.com/knowledge-base
- HTTP Archive ("State of the Web", 2025-2026) — sito httparchive.org
- "Impact of Web Performance on User Experience" — Google Research, 2025
Link interni previsti
- Landing: /landing/siti-web-ticino/
- Secondario: /contatti/
- Correlato: /blog/velocita-sito-web-seo/
