La velocità di un sito web è definita dalla capacità delle pagine di caricarsi e rispondere alle interazioni dell’utente entro soglie precise, misurate dai Core Web Vitals di Google: LCP inferiore a 2,5 secondi, INP inferiore a 200ms e CLS inferiore a 0,1. Seguire i passaggi per migliorare veloci siti significa agire in modo sistematico su server, immagini, codice e risorse, nell’ordine corretto. Solo il 62% delle origini mobile supera il test LCP: questo dato rivela quanto margine di miglioramento esista ancora per la maggior parte dei siti aziendali. Secondo Google, la probabilità di abbandono aumenta del 32% tra 1 e 3 secondi di caricamento. Ogni secondo perso costa visitatori, posizioni nei risultati di ricerca e vendite.
Come valutare le prestazioni attuali del sito
Prima di intervenire, serve capire dove si trovano i problemi. Senza dati precisi, qualsiasi modifica è un tentativo alla cieca.
Gli strumenti di analisi principali
Tre strumenti coprono la maggior parte delle esigenze di analisi per un sito aziendale:
- PageSpeed Insights: analizza una singola URL e restituisce sia dati di laboratorio (simulati) sia dati di campo reali provenienti dal database CrUX di Google. È il punto di partenza più diretto per capire come Google valuta il sito.
- Lighthouse: integrato in Chrome DevTools, genera report dettagliati su performance, accessibilità e SEO tecnica. Utile per diagnosi approfondite in fase di sviluppo.
- GTmetrix: offre waterfall chart dettagliate che mostrano l’ordine di caricamento di ogni risorsa. Permette di identificare file pesanti o richieste che rallentano il rendering.
La distinzione tra dati di laboratorio e dati di campo è fondamentale. I dati di laboratorio simulano condizioni controllate e sono riproducibili, ma non riflettono l’esperienza reale degli utenti. I dati di campo, raccolti da Chrome su utenti reali, sono quelli che Google usa per il posizionamento. Per una analisi performance completa del sito, leggi sempre entrambi i tipi di dati insieme.
Come leggere i report e stabilire le priorità
Dopo aver raccolto i dati, concentrati sulle pagine con più traffico e sulle metriche che non superano le soglie. Un punteggio basso su LCP in una pagina prodotto di un e-commerce ha un impatto diretto sulle conversioni. Annota quali metriche falliscono e su quali dispositivi: mobile e desktop spesso mostrano problemi diversi.
Un consiglio: esegui la prima analisi su almeno tre pagine chiave del sito (homepage, pagina prodotto o servizio, pagina di contatto) per avere un quadro rappresentativo e non basarti solo sulla homepage.
Quali sono i passaggi fondamentali per migliorare il TTFB?
Il TTFB (Time to First Byte) è la metrica che misura il tempo che il server impiega a rispondere alla prima richiesta del browser. Un server lento rende vane le altre ottimizzazioni frontend: anche immagini perfettamente compresse e codice pulito non bastano se il server risponde in 2 secondi.
Strategie concrete per ridurre il TTFB
- Scegli un hosting performante. Un piano di hosting condiviso economico è spesso la causa principale di TTFB elevati. Passare a un hosting con SSD NVMe, PHP 8.x e risorse dedicate riduce i tempi di risposta in modo misurabile.
- Attiva il caching server. Strumenti come Redis o Memcached memorizzano in memoria le query al database più frequenti. Su WordPress, plugin di caching come WP Rocket o W3 Total Cache implementano questa logica senza richiedere configurazioni server manuali.
- Usa una CDN (Content Delivery Network). Una CDN distribuisce i file statici del sito su server geograficamente vicini all’utente. Cloudflare, ad esempio, offre un piano gratuito che riduce la latenza per visitatori lontani dal server principale.
- Elimina i redirect inutili. Ogni redirect aggiunge un round-trip HTTP. Una catena di tre redirect può aggiungere 300–600ms al TTFB percepito.
- Controlla le query lente al database. Su siti WordPress con molti plugin, query non ottimizzate rallentano ogni risposta del server. Plugin come Query Monitor aiutano a identificarle.
Un consiglio: dopo aver cambiato hosting o attivato il caching, misura il TTFB con PageSpeed Insights a distanza di 24 ore per verificare l’effetto reale, non solo quello immediato.
Come ottimizzare il Largest Contentful Paint (LCP)?
L’LCP misura il tempo di caricamento dell’elemento principale visibile nella viewport, di solito un’immagine hero o un blocco di testo grande. Migliorare il preload dell’immagine hero ha portato in test di Google a riduzioni da 2,6s a 1,9s. Questo tipo di intervento è tra i più efficaci in termini di rapporto sforzo/risultato.
Identificare e prioritizzare l’elemento LCP
Il primo passo è sapere esattamente quale elemento il browser considera LCP. PageSpeed Insights lo evidenzia nel report. Nella maggior parte dei siti aziendali si tratta dell’immagine principale in cima alla pagina.
Una volta identificato l’elemento, applica questi interventi nell’ordine indicato:
- Aggiungi
fetchpriority="high"all’immagine LCP. Questo attributo HTML segnala al browser di scaricare quell’immagine prima di qualsiasi altra risorsa non critica. - Rimuovi
loading="lazy"dall’immagine LCP. Il lazy loading ritarda il caricamento delle immagini fuori dalla viewport, ma applicato all’elemento LCP produce l’effetto opposto a quello desiderato. - Usa formati moderni: WebP o AVIF. WebP pesa in media il 25–35% in meno rispetto a JPEG a parità di qualità visiva. AVIF offre compressione ancora superiore ma ha compatibilità browser leggermente inferiore. Per una guida dettagliata su come ottimizzare le immagini web, Andreafreelance ha una risorsa dedicata.
- Specifica sempre width e height nelle immagini. Senza questi attributi, il browser non riserva spazio per l’immagine durante il caricamento, causando spostamenti di layout.
- Precarica l’immagine LCP con
<link rel="preload">. Inserito nell’<head>della pagina, questo tag avvia il download dell’immagine prima che il browser analizzi il corpo della pagina.
Confronto tra formati immagine per il web
| Formato | Compressione | Compatibilità browser | Uso consigliato |
|---|---|---|---|
| JPEG | Media | Universale | Fotografie senza trasparenza |
| WebP | Alta | Ottima (Chrome, Firefox, Safari) | Immagini generali, hero image |
| AVIF | Molto alta | Buona (Chrome, Firefox) | Immagini dove la dimensione è critica |
| PNG | Bassa | Universale | Grafica con trasparenza |
Un consiglio: converti tutte le immagini in WebP come standard minimo. Usa AVIF solo per immagini dove ogni kilobyte conta, come le hero image sopra i 200KB.
Come migliorare INP e CLS del sito web?
INP e CLS misurano rispettivamente la reattività alle interazioni dell’utente e la stabilità visiva della pagina. Sono le metriche più difficili da correggere perché dipendono da comportamenti dinamici del codice e delle risorse.
Ridurre l’INP con JavaScript ottimizzato
JavaScript bloccante e long tasks compromettono la metrica INP, rallentando la risposta a clic, tap e input da tastiera. Un long task è qualsiasi operazione JavaScript che occupa il thread principale per più di 50ms. Interrompere questi task e differire gli script non critici riduce l’INP fino a 300ms.
Le azioni più efficaci per migliorare l’INP:
- Differisci gli script non critici con l’attributo
deferoasync. Script di analytics, chat widget e pixel di tracciamento non devono bloccare il rendering della pagina. - Spezza i long tasks in operazioni più piccole usando
setTimeouto la Scheduler API. Questo libera il thread principale tra un’operazione e l’altra. - Carica gli script di terze parti in modo condizionale. Rimuovere o rinviare script di terze parti poco critici migliora l’INP senza compromettere le funzionalità principali del sito.
- Riduci il JavaScript totale caricato. Ogni libreria aggiunta ha un costo. Valuta se ogni script presente è davvero necessario o se può essere sostituito con codice nativo più leggero.
Stabilizzare il layout con le correzioni CLS
Il CLS misura quanto gli elementi della pagina si spostano durante il caricamento. Un banner che appare dopo 2 secondi e spinge il testo verso il basso è un esempio classico di CLS elevato. Aggiungere attributi width e height alle immagini e usare font in self-hosting con font-display: optional riduce lo spostamento visivo in modo misurabile.
Le correzioni principali per il CLS:
- Specifica sempre le dimensioni di immagini e video nell’HTML.
- Usa
font-display: optionalper i font web: il browser usa il font di sistema se quello personalizzato non è ancora disponibile, evitando il layout shift. - Ospita i font direttamente sul server del sito invece di caricarli da Google Fonts o altri CDN esterni.
- Riserva spazio fisso per banner, annunci e contenuti dinamici prima che vengano caricati.
Un consiglio: testa il CLS su mobile con una connessione 4G simulata in Lighthouse. Gli spostamenti di layout sono molto più evidenti su connessioni lente e su schermi piccoli.
Come mantenere le performance nel tempo?
Ottenere buoni punteggi una volta non basta. Le performance di un sito degradano nel tempo per l’aggiunta di nuovi plugin, aggiornamenti di tema, script di marketing e contenuti non ottimizzati. L’ottimizzazione continua con monitoraggio e audit regolari è la pratica che distingue i siti che mantengono alte prestazioni da quelli che regrediscono.
Strumenti e pratiche per il monitoraggio costante
Usa questi strumenti in modo regolare:
- Google Search Console: la sezione «Esperienza pagina» mostra i dati CrUX aggregati per il sito e segnala le URL con problemi di Core Web Vitals.
- CrUX Dashboard: disponibile tramite Looker Studio, permette di visualizzare l’andamento storico delle metriche nel tempo.
- CoreDash: strumento dedicato al monitoraggio dei Core Web Vitals in tempo reale, utile per chi gestisce più siti o vuole alert automatici su regressioni.
Tieni presente che i dati CrUX impiegano fino a 28 giorni per riflettere i cambiamenti effettivi di performance. Pianifica le verifiche su base mensile e non aspettarti risultati immediati nei dati di campo.
Il processo di monitoraggio efficace segue questi passi:
- Esegui un audit completo con PageSpeed Insights dopo ogni modifica significativa al sito.
- Controlla Search Console ogni due settimane per individuare nuove URL con problemi.
- Rivedi l’elenco dei plugin attivi ogni trimestre ed elimina quelli non necessari.
- Testa le performance dopo ogni aggiornamento di tema o plugin principale.
Un consiglio: crea un foglio di calcolo con i punteggi LCP, INP e CLS delle pagine principali, aggiornato mensilmente. Avere uno storico visivo rende immediatamente evidente qualsiasi regressione.
Punti chiave
La velocità del sito migliora in modo affidabile solo seguendo un ordine preciso: TTFB prima, poi LCP, INP e CLS, con monitoraggio continuo per mantenere i risultati nel tempo.
| Punto | Dettagli |
|---|---|
| Misura prima di intervenire | Usa PageSpeed Insights e Lighthouse per identificare le metriche critiche prima di qualsiasi modifica. |
| Il TTFB è la priorità assoluta | Un server lento vanifica ogni ottimizzazione frontend: affronta hosting e caching come primo passo. |
| LCP dipende dalle immagini | Usa fetchpriority, WebP e preload per portare l’LCP sotto i 2,5 secondi sulle pagine chiave. |
| INP e CLS richiedono codice pulito | Differisci JavaScript non critico e specifica le dimensioni delle immagini per eliminare instabilità e ritardi. |
| Il monitoraggio previene le regressioni | Controlla Search Console e i dati CrUX ogni mese per intercettare i problemi prima che peggiorino. |
La mia esperienza sull’ottimizzazione della velocità
Dopo oltre 20 anni di lavoro su siti WordPress, WooCommerce e Prestashop, ho imparato una cosa che molti professionisti scoprono tardi: l’ordine degli interventi conta quanto gli interventi stessi.
Ho visto aziende spendere ore a comprimere immagini e installare plugin di caching, ottenendo miglioramenti marginali, perché il vero problema era un hosting condiviso con TTFB di 1,8 secondi. Finché non si risolve il server, tutto il resto è cosmesi.
L’errore più comune che incontro è trattare l’ottimizzazione della velocità come un evento singolo invece che come una pratica continua. Un sito che oggi supera tutti i Core Web Vitals può regredire in tre mesi dopo l’installazione di un plugin di marketing mal configurato o un aggiornamento di tema che introduce CSS non necessario. La struttura di un sito aziendale performante va progettata con la velocità come vincolo, non come rifinitura finale.
Un’altra osservazione concreta: investire in un hosting di qualità superiore è quasi sempre la mossa con il miglior ritorno. Il risparmio di 10–15 € al mese su un piano economico si paga con tassi di conversione più bassi e posizioni peggiori nei risultati di ricerca. I dati parlano chiaro: miglioramenti del tasso di conversione tra il 10 e il 30% sono documentati per siti che passano da tempi di caricamento lenti a pagine veloci. Questo è un argomento economico, non solo tecnico.
Il mio consiglio finale è semplice: segui la sequenza TTFB, LCP, INP, CLS. Non saltare passaggi. Misura dopo ogni intervento. E tratta il monitoraggio mensile come parte ordinaria della gestione del sito, non come un’attività straordinaria.
— Andrea
Andreafreelance per la velocità e le performance del tuo sito
Se hai letto questa guida e riconosci i problemi descritti nel tuo sito, il passo successivo è un intervento professionale strutturato. Andreafreelance offre servizi di restyling e ottimizzazione sito web che includono analisi delle performance, correzione delle metriche Core Web Vitals e ottimizzazione tecnica completa. Con oltre 20 anni di esperienza su WordPress, WooCommerce e Prestashop, ogni progetto parte da dati reali e produce risultati misurabili. Se cerchi anche un web developer esperto che gestisca l’intero processo, dalla diagnosi all’implementazione, Andreafreelance è il riferimento giusto per PMI e professionisti digitali italiani.
Domande frequenti
Cos’è il TTFB e perché influisce sulla velocità?
Il TTFB (Time to First Byte) misura il tempo che il server impiega a rispondere alla prima richiesta del browser. Un TTFB elevato rallenta tutte le altre metriche di performance, incluso l’LCP.
Quali sono le soglie dei Core Web Vitals nel 2026?
Le soglie definite da Google sono: LCP inferiore a 2,5 secondi, INP inferiore a 200ms e CLS inferiore a 0,1, misurati al 75° percentile nei dati di campo CrUX.
Quanto tempo ci vuole per vedere i miglioramenti nei dati Google?
I dati CrUX impiegano fino a 28 giorni per riflettere i cambiamenti reali di performance. Pianifica le verifiche su base mensile dopo ogni intervento significativo.
Il formato WebP migliora davvero le performance?
WebP riduce il peso delle immagini del 25–35% rispetto a JPEG a parità di qualità visiva. Questa riduzione accelera il caricamento dell’LCP e migliora l’esperienza su connessioni mobili.
Come si riduce il CLS su un sito WordPress?
Specifica sempre width e height nelle immagini, usa font-display: optional per i font web e ospita i font direttamente sul server del sito. Questi tre interventi eliminano la maggior parte degli spostamenti di layout.
