SEO velocità sito: come ottimizzare performance e misurarle

Cosa significa “velocità del sito” per la SEO

La velocità del sito in ambito SEO non è solo il tempo di caricamento grezzo: include la rapidità con cui il browser mostra contenuti utili, rende la pagina interattiva e mantiene una presentazione stabile. Per i motori di ricerca e per gli utenti queste sono tre aree pratiche che conviene misurare e ottimizzare.

Metriche chiave: cosa misurare e perché

Core Web Vitals (sintesi)

I Core Web Vitals sono tre metriche focali che descrivono esperienza visiva e interattività: LCP per il tempo di rendering del contenuto principale, INP per la reattività alle interazioni reali, e CLS per la stabilità visiva. Sono misure utilizzate sia in campo sintetico (lab) sia in campo reale (field).

Altre metriche utili

FCP (First Contentful Paint), TTFB (Time To First Byte), e metriche JavaScript come il lavoro della main thread forniscono contesto. Misurare sia dati di laboratorio (Lighthouse/PageSpeed) sia dati utenti reali (Chrome UX Report, Core Web Vitals report in Google Search Console) evita decisioni basate su risultati isolati.

Come la velocità influisce su crawling, indicizzazione e ranking

Distinguere crawling, indicizzazione e ranking aiuta a capire gli effetti della velocità. Una pagina lenta può ridurre l'efficienza di crawl (più tempo per fetch), rendere meno probabile che Google indicizzi risorse pesanti viste solo su desktop e peggiorare l'esperienza che gli utenti usano per giudicare la qualità. Google usa la versione mobile come primaria base per crawling e indicizzazione; dal luglio 2024 Googlebot Smartphone è il crawler predefinito per Search.

Importante: la velocità raramente è l'unico segnale che determina posizionamenti. È però spesso il fattore che frena pagine che per contenuto dovrebbero performare meglio: migliorie di performance aumentano l'usabilità, i tassi di conversione e, indirettamente, i segnali di comportamento che i motori possono usare per il ranking.

Checklist operativa: come diagnosticare velocità e problemi

Strumenti principali

Usa una combinazione di lab e field: PageSpeed Insights (che mostra dati CrUX + Lighthouse), Lighthouse/DevTools (per debug in locale), il report Core Web Vitals in Google Search Console per le tue pagine, e controlli da riga di comando come curl per verifiche rapide del server. Per pagine di terze parti, fallback pratici sono Chrome DevTools e fetch con user-agent personalizzato; per il controllo dell'indicizzazione usa query site: e verifica la pagina con frasi uniche (riproduci la ricerca) — ricordando che site: è un segnale indicativo, non definitivo.

Controlli rapidi da riga di comando

Per verificare solo gli header HTTP: usa curl -I https://example.com/pagina. Per ottenere l'HTML come uno specifico user agent (utile per verificare rendering o varianti per dispositivo): usa curl -A "Mozilla/5.0 (Linux; Android 12)" https://example.com/pagina (non usare -I se vuoi il body). Per cercare intestazioni Link o cache: combina con grep, ad esempio curl -I https://example.com | grep -i Link.

Analisi lab vs field

I test di laboratorio (Lighthouse) simulano condizioni ripetibili e sono ottimi per confronti prima/dopo. I dati reali (CrUX, Core Web Vitals in Search Console, strumenti RUM) mostrano la performance reale dei visitatori e devono guidare le priorità quando differiscono dai test sintetici.

Tecniche pratiche di ottimizzazione

Server, rete e caching

Scegli un'infrastruttura coerente con il traffico e usa una CDN per consegna geografica. Abilita HTTP/2 o HTTP/3, TLS moderno e compressione (brotli/gzip). Imposta header di cache per risorse statiche usando un'intestazione del tipo Cache-Control: public, max-age=SECONDS, immutable dove SECONDS sarà calibrato dalla tua policy di deployment.

Prioritizzazione delle risorse

Riduci il percorso critico di rendering: inserisci il CSS critico inline per above-the-fold, carica il resto in modo asincrono. Usa <link rel="preload" href="/fonts/xyz.woff2" as="font" type="font/woff2" crossorigin> per font critici e <link rel="preconnect" href="https://example-cdn.com"> per anticipare connessioni a terze parti.

Ottimizzazione immagini e media

Usa formati moderni (WebP, AVIF) dove possibile, fornisci immagini responsive con srcset/sizes e dichiara dimensioni (width/height) per evitare spostamenti. Per immagini non immediatamente visibili, usa loading="lazy". Per video valuta poster statici e caricamento differito.

JavaScript: riduzione del carico e interattività

Riduci il JS eseguito al primo paint: split del codice, lazy-load dei bundle non critici, usa async/defer per script esterni e limita i listener che bloccano la main thread. Ridurre i long tasks migliora INP; considera web worker per calcoli pesanti.

Errori comuni e come evitarli

Ecco gli errori che vediamo più spesso e la correzione pratica:

• Affidarsi solo a test lab: combina sempre con dati reali (CrUX, RUM).
• Caricare script di terze parti senza audit: misura impatto e riduci o posticipa l'esecuzione.
• Non dichiarare dimensioni immagine: questo causa CLS facilmente evitabile.
• Cache mal configurata per risorse versionate: usa strategie di cache con fingerprinting dei file.

Come prioritizzare i miglioramenti: un approccio pragmatico

Non tutte le pagine richiedono lo stesso investimento. Prioritizza le azioni dove ottieni il maggior ritorno in termini di traffico reale e obiettivi di business: pagine con molti visitatori, with alta conversione o pagine che servono query competitive. Usa Core Web Vitals in Search Console per trovare cluster di URL con problemi simili e applica correzioni in blocco dove possibile.

Per ogni intervento definisci: ipotesi di impatto, metrica target (lab + field), test A/B o rollout graduale e piano di rollback in caso di regressione.

Verifica e monitoraggio dopo le modifiche

Dopo le ottimizzazioni esegui test sintetici ripetuti (Lighthouse in condizioni controllate) e monitora i dati reali: Core Web Vitals in Search Console e metriche RUM. Controlla anche log del server per cambiamenti nel pattern di crawl e per eventuali errori 4xx/5xx introdotti. Per regressioni dovute a terze parti, prepara una lista di fallback rapidi (es. disabilitare uno script esterno) per intervenire velocemente.

Risorse e controlli rapidi di troubleshooting

Breve checklist di troubleshooting:

• Esegui PageSpeed Insights su una pagina critica: confronta lab vs field.
• Apri Chrome DevTools → Performance per registrare caricamento e long tasks.
• Controlla il report Core Web Vitals in Google Search Console per trend e gruppi di URL.
• Verifica header e Link con curl per confermare preload/display di risorse critiche.

Domande frequenti