Se il tuo sito ha superato il check su PageSpeed Insights ma le pagine continuano a perdere posizioni, il problema quasi certamente non è dove stai guardando. La velocità del sito web è una delle variabili SEO più sottovalutate dai marketer, non perché non la conoscano, ma perché si fermano ai sintomi superficiali e non scavano fino alle cause reali.
Questo articolo esplora i 10 fattori che rallentano un sito web in modo silenzioso, sistematico e spesso invisibile ai report standard. Non troverai “comprimi le immagini” o “usa un hosting migliore”. Troverai i pattern che distinguono un sito davvero ottimizzato da uno che sembra ottimizzato.
Perché la velocità del sito è una questione di fatturato, non di tecnica
Partiamo da un dato che cambia prospettiva: migliorare la velocità di caricamento mobile di appena 0,1 secondi aumenta le conversioni retail dell’8,4% e il valore medio dell’ordine del 9,2%, secondo lo studio “Milliseconds Make Millions“ commissionato da Google a Deloitte Digital su 30 milioni di sessioni reali. Non è un numero astratto. Su un e-commerce con 100.000 visite mensili e un ticket medio di 50€, ogni frazione di secondo guadagnata si traduce direttamente in fatturato.
Ma c’è un secondo livello da considerare, quello organico. Da maggio 2021, Google ha integrato i Core Web Vitals come fattori di ranking ufficiali. Le tre metriche, LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint), vengono misurate su dati di campo reali degli utenti Chrome, non in laboratorio.
Questo significa che un sito con uno score PageSpeed ottimo può comunque perdere posizioni se i suoi utenti reali sperimentano performance mediocri.
Fattore #1: Perché il tuo sito è lento prima ancora che il browser faccia qualcosa
Il Time to First Byte (TTFB) è il tempo che passa tra la richiesta HTTP del browser e il primo byte di risposta ricevuto dal server. Se è sopra 800ms, il problema non è nel front-end. È nell’infrastruttura.
Un TTFB elevato significa una di queste cose:
- il server deve generare la pagina dinamicamente ad ogni richiesta (tipico di WordPress senza caching),
- l’hosting è geograficamente lontano dall’utente,
- manca un CDN che distribuisca i contenuti vicino ai visitatori. Il risultato è sempre lo stesso: il browser aspetta, l’utente aspetta, Google registra tutto.
Come diagnosticare un TTFB lento senza essere uno sviluppatore
Vai su WebPageTest.org e testa il tuo sito da una location europea (es. Frankfurt). Nel waterfall chart, la barra verde chiaro è il TTFB. Se occupa più del 30% del tempo totale di caricamento, hai un problema di server response.
Le soluzioni concrete per abbassare il tempo di risposta del server
- CDN con edge caching (Cloudflare è gratuito nella versione base): la pagina viene servita da un server fisicamente vicino all’utente, riducendo la latenza di rete.
- Full-page caching lato server: WordPress con WP Rocket o LiteSpeed Cache, Shopify già lo gestisce nativamente. L’obiettivo è servire HTML pre-generato, non costruire la pagina ad ogni richiesta.
- Upgrade a PHP 8.x: il passaggio da PHP 7.4 a 8.x porta guadagni di performance reali che variano dal 6% al 23% a seconda del framework e del tipo di carico. Non è una magia, ma è un miglioramento gratuito che molti siti ancora non hanno fatto.
Fattore #2: Il JavaScript che blocca tutto senza che tu lo sappia
Quando il browser incontra un tag <script> nel <head> della pagina senza attributi defer o async, si blocca. Smette di costruire il DOM, aspetta che lo script venga scaricato ed eseguito, poi riprende. Ogni millisecondo di questa pausa si aggiunge direttamente al Largest Contentful Paint, la metrica che Google usa come proxy per “quanto velocemente l’utente vede qualcosa di utile”.
Il nodo critico non è il tuo JavaScript. È quello del widget di chat live, del pixel di remarketing, del sistema di A/B testing caricato sincrono. Ognuno si è aggiunto nel corso di mesi, uno alla volta, senza ricalcolare mai il costo totale accumulato.
Come identificare quali script bloccano il rendering della tua pagina
Apri Chrome DevTools (F12) → tab Performance → registra un caricamento della pagina. Cerca le barre rosse nella sezione “Main Thread”: ogni picco lungo corrisponde a uno script che blocca il browser. In alternativa, usa PageSpeed Insights: nella sezione “Opportunità” trovi “Elimina le risorse che bloccano il rendering” con una lista ordinata per impatto.
La strategia per non rinunciare ai tuoi strumenti di marketing mantenendo la velocità
Non devi eliminare i tuoi strumenti. Devi cambiare il modo in cui li carichi:
- Aggiungi
defera tutti gli script non critici (quelli che non servono prima che la pagina sia visibile). - Usa Google Tag Manager come unico punto di ingresso per tutti i tag marketing: riduce i DNS lookup aggiuntivi.
- Per i casi più estremi, valuta Partytown, una libreria che sposta l’esecuzione degli script di terze parti in un Web Worker separato, liberando il thread principale.
Fattore #3: I pixel di tracciamento che stai pagando con le performance
Ogni strumento che installi introduce tre costi nascosti: un DNS lookup (la risoluzione del nome di dominio del servizio), un TCP handshake e spesso un TLS negotiation. Con 12-15 servizi terzi attivi (pixel Meta, Hotjar, Intercom, Trustpilot, LinkedIn Insight Tag, Google Analytics, heatmap tools) stai potenzialmente aggiungendo centinaia di millisecondi solo in overhead di connessione.
Secondo il Web Almanac 2024 di HTTP Archive, il 92% delle pagine web carica almeno una risorsa di terze parti. Non è solo una questione di peso: il vero danno è la dipendenza dalla disponibilità dei loro server. Se Hotjar ha un’interruzione o rallentamento quel giorno, il tuo sito ne risente, indipendentemente dall’eccellenza della tua infrastruttura.
Come fare un audit dei servizi terzi attivi sul tuo sito
Vai su webpagetest.org, inserisci il tuo URL e avvia un test. Nel report risultante, clicca sulla tab “Third-Party Summary”: troverai la lista completa di tutti i domini esterni caricati dalla pagina, con il numero di richieste, il peso in KB e il tempo di blocco sul main thread di ciascuno.
È spesso rivelatorio: trovi pixel di campagne terminate mesi fa, widget non più in uso, script duplicati.
Tre ottimizzazioni immediatamente implementabili per ridurre l'overhead di terze parti
- <link rel=”preconnect”>: inserisci nell’
<head>un tag preconnect per i domini critici (es. Google Fonts, GTM). Il browser avvierà la connessione in anticipo, prima che le risorse vengano richieste. - Audit trimestrale dei tag in GTM: rimuovi tutti i tag non usati nelle ultime campagne. Un pixel orfano continua a caricarsi a ogni pagina view.
- Self-hosting selettivo: alcuni script (es. Google Analytics GA4) possono essere serviti tramite server proxy sul tuo dominio, eliminando il DNS lookup esterno.
Fattore #4: Come i font web rubano secondi preziosi all'esperienza utente
I Google Font sono gratuiti, eleganti, facili da usare. Sono anche, senza la configurazione giusta, una delle cause più frequenti di testo invisibile durante il caricamento, tecnicamente noto come FOIT (Flash of Invisible Text).
Il problema funziona così: il browser scarica l’HTML, vede il testo, ma il font web non è ancora arrivato. Aspetta. Durante quell’attesa, il testo non esiste visivamente. Il Largest Contentful Paint non si attiva. Google lo registra come “pagina lenta” anche se strutturalmente è velocissima.
Perché caricare i font da Google invece che dal tuo server ti costa in ranking
Ogni font caricato da fonts.googleapis.com richiede una connessione a un dominio esterno. Quel dominio non è sul tuo CDN. Non è nella tua cache. È un DNS lookup aggiuntivo per ogni visita, su ogni browser che non ha già quella risorsa in cache locale.
La soluzione migliore in assoluto è il self-hosting dei font: scarichi i file .woff2 e li servi dal tuo server (o CDN). Elimini la dipendenza esterna, controlli la cache, guadagni in performance.
Come eliminare il testo invisibile con font-display: swap
Aggiungi font-display: swap alla dichiarazione @font-face. Questo dice al browser: “mostra il testo con un font di sistema mentre aspetti, poi sostituisci”, così l’utente vede sempre del testo. Abbinalo a <link rel="preload"> per i font above-the-fold e il tuo LCP migliorerà in modo misurabile.
Fattore #5: La trappola dei redirect a catena
Ogni redirect aggiunge latenza. Un redirect 301 ben fatto costa circa 200-300ms. Una catena di tre redirect (A → B → C → D) può costare quasi un secondo intero, prima ancora che il browser abbia iniziato a scaricare qualcosa.
Le catene di redirect si accumulano nel tempo: la migrazione da HTTP a HTTPS, il passaggio da www a non-www, il cambio di CMS, la ristrutturazione degli URL di categoria. Ognuno lascia tracce e nessuno le pulisce.
L'impatto dei redirect sul crawl budget e sul ranking organico
Google ha un crawl budget limitato per ogni sito: un numero di pagine che Googlebot è disposto a scansionare in un dato arco di tempo. Ogni redirect consuma parte di quel budget. Su siti grandi (e-commerce con migliaia di SKU, portali editoriali) le catene di redirect possono ridurre significativamente la frequenza con cui le nuove pagine vengono indicizzate.
Come mappare e "appiattire" i redirect del tuo sito in un pomeriggio
Usa Screaming Frog SEO Spider (gratuito fino a 500 URL) in modalità crawl e filtra per “Response Code → Redirect”. Identifica tutte le catene e imposta redirect diretti (A→D in un solo hop). Converti ogni 302 esistente da più di 6 mesi in 301 permanente.
Fattore #6: Perché le tue immagini "ottimizzate" continuano a pesare troppo
“Le abbiamo convertite in WebP e compresse con TinyPNG.” Bene. Ma questo risolve solo metà del problema.
L’altra metà si chiama responsive image sizing: servire un’immagine da 1.400px a un telefono con viewport di 390px significa scaricare circa 13 volte i pixel necessari. Il file WebP pesa 60KB invece di 200KB, ottimo, ma un file WebP da 60KB a dimensione piena, su mobile, potrebbe essere ottimizzato a 12KB con le dimensioni corrette.
Quella differenza si moltiplica per ogni immagine above-the-fold.
La differenza tra formato immagine e dimensione immagine (e perché contano entrambe)
| Formato | Supporto browser | Riduzione vs JPEG | Consigliato per |
|---|---|---|---|
| JPEG | Universale | Baseline | Fotografie complesse |
| WebP | 97%+ | –25/35% | Uso generale |
| AVIF | 91%+ | –50% vs JPEG | Immagini hero, prodotto |
| SVG | Universale | N/A (vettoriale) | Loghi, icone, illustrazioni |
Come implementare il lazy loading e il responsive sizing senza toccare il codice
L’attributo HTML loading="lazy" è supportato nativamente da tutti i browser moderni e posticipa il caricamento delle immagini fuori schermo. Per il responsive sizing, gli attributi srcset e sizes sono lo strumento corretto, ma se il CMS li genera male, la soluzione scalabile è un image CDN come Cloudinary o Imgix: ridimensionano, convertono e ottimizzano le immagini in tempo reale in base al dispositivo dell’utente, senza intervento manuale.
Fattore #7: La cache HTTP mal configurata che scarica le risorse da zero ad ogni visita
La cache del browser è il meccanismo più potente per la performance degli utenti di ritorno ed è sistematicamente mal configurata nel 70% dei siti. Quando funziona correttamente, un utente che torna sul sito carica CSS, JavaScript e immagini dalla memoria locale senza fare nemmeno una richiesta al server. Zero latenza. Caricamento istantaneo.
Il problema classico: header Cache-Control assenti (il browser decide da solo, spesso male), max-age troppo brevi che scadono in pochi minuti, oppure caching troppo aggressivo su file che cambiano frequentemente.
La strategia del content hashing che permette cache infinita senza rischi
La soluzione di riferimento si chiama cache busting tramite content hashing: i framework moderni (Next.js, Nuxt, Vite, Astro) rinominano automaticamente ogni file statico includendo un hash del suo contenuto nel nome (es. main.a3f92b.js). Questo permette di impostare Cache-Control: max-age=31536000, immutable, un anno intero, in totale sicurezza.
Quando aggiorni il file, il suo contenuto cambia, l’hash cambia, il nome del file cambia, il browser scarica la nuova versione. Se non usi un framework moderno, puoi ottenere lo stesso risultato configurando il tuo processo di build con Webpack o Gulp.
Fattore #8: Il layout che si sposta dopo il caricamento e distrugge l'esperienza mobile
Il Cumulative Layout Shift (CLS) misura quanto gli elementi della pagina si spostano dopo il caricamento iniziale. È la metrica Core Web Vitals più legata alla frustrazione dell’utente: stai per cliccare un link, la pagina si sposta, premi qualcosa di completamente diverso. Su mobile, dove lo spazio è limitato, ogni shift è amplificato.
Google considera un CLS sopra 0,1 come “da migliorare”, sopra 0,25 come “scarso” e le penalizzazioni di ranking per CLS elevato sono documentate e misurabili.
Le quattro cause di layout instabile che non vengono quasi mai corrette
- Immagini senza
widtheheightnell’HTML: il browser non riserva lo spazio prima che l’immagine arrivi, e il contenuto si sposta quando appare. La soluzione è aggiungere i due attributi nel markup. - Banner cookie e popup di benvenuto: appaiono dopo il caricamento e “spingono” il contenuto verso il basso. Usa posizionamento fisso (
fixed/sticky) per evitare di disturbare il layout. - Font web con fallback molto diversi: il passaggio dal font di sistema al font definitivo può cambiare l’altezza delle righe e spostare tutto il testo sottostante. Lo strumento Font Style Matcher aiuta a scegliere un fallback visivamente compatibile.
- Annunci display con dimensioni variabili: riserva sempre uno spazio fisso (
min-height) nei contenitori degli annunci, anche quando l’annuncio non è ancora caricato.
Fattore #9: Come il database nascosto nel back-end rovina le performance sotto carico
Questo è il fattore che più sorprende i marketer: un sito può comportarsi perfettamente durante i test, con velocità eccellenti su PageSpeed, e diventare progressivamente più lento man mano che aumentano gli utenti simultanei. Il colpevole è quasi sempre il database.
Una query SQL non ottimizzata su una tabella con centinaia di migliaia di righe può richiedere 2-3 secondi. Sotto carico normale non si vede. Con 50 utenti simultanei che la scatenano in parallelo, il server si inceppa, i TTFB salgono e le pagine si bloccano.
Il problema N+1 che rallenta ogni e-commerce con molti prodotti
Il problema N+1 è un pattern classico negli ORM (Eloquent, Django ORM, Active Record): per mostrare una lista di 20 prodotti con le rispettive categorie, il sistema esegue 1 query per i prodotti + 20 query individuali per le categorie (una per prodotto). In totale: 21 query invece di 2. Su pagine categoria con 100 prodotti, sono 101 query. È un errore frequente e raramente visibile in sviluppo.
Come diagnosticare problemi di performance lato database senza un DBA
In ambiente WordPress, il plugin gratuito Query Monitor visualizza in tempo reale tutte le query eseguite su ogni pagina, i loro tempi e le call stack che le hanno generate. In ambienti custom, lo stesso risultato si ottiene con APM tools come New Relic o Datadog. L’obiettivo è identificare le query più lente e valutare se mancano indici sulle colonne usate in WHERE e JOIN.
Fattore #10: Il CSS inutilizzato che gonfia ogni pagina in silenzio
Il CSS inutilizzato è uno dei problemi più diffusi e meno discussi dell’ottimizzazione avanzata delle performance web. La maggior parte dei siti carica un unico foglio di stile globale che contiene le regole CSS per tutte le pagine del sito (homepage, pagine prodotto, checkout, blog, 404). Un utente che visita solo la homepage, quindi, scarica un CSS scritto per il checkout che non vedrà mai.
Su siti con builder visivi (Elementor, Divi, Webflow) o framework CSS completi (Bootstrap, Tailwind con JIT disabilitato), il foglio di stile può pesare centinaia di kilobyte. Il 90% di quel contenuto è inutile per la pagina corrente.
Come misurare il CSS inutilizzato sulle tue pagine chiave
Apri Chrome DevTools → Cmd/Ctrl+Shift+P → digita “Coverage” → avvia la registrazione → ricarica la pagina. Il pannello mostrerà ogni file CSS con la percentuale di codice effettivamente usata. Percentuali sotto il 20% di utilizzo sono comuni su siti non ottimizzati.
La strategia del CSS critico inline che accelera il rendering iniziale
La tecnica del Critical CSS consiste nell’estrarre e incorporare direttamente nel <head> (inline) solo le regole CSS necessarie per rendere visibile il contenuto above-the-fold. Il resto del CSS viene caricato in modo asincrono. Il risultato: la pagina appare completa visivamente prima ancora che il CSS completo venga scaricato. Strumenti come Critical (npm) o il modulo integrato in Next.js automatizzano questo processo.
Come costruire un sistema di monitoraggio della performance che funziona davvero
Conoscere i problemi è il primo passo. Il secondo è evitare che si ripresentino.
Un sistema di monitoraggio della velocità del sito web efficace per i marketer non richiede un team di ingegneri. Richiede tre livelli:
- Livello 1 – Monitoraggio continuo (automazione): Imposta avvisi in Google Search Console per peggioramenti nei Core Web Vitals. Usa
SpeedCurveoCalibreper monitorare le performance nel tempo su un set di URL rappresentativi: homepage, pagina prodotto, pagina categoria, checkout. - Livello 2 – Audit periodici (mensile/trimestrale): Usa
Lighthouse CIintegrato nella pipeline di deploy per bloccare automaticamente i rilasci che peggiorano le performance oltre una soglia definita. Abbinalo a una scansione mensile con Screaming Frog per identificare nuove catene di redirect e risorse bloccanti. - Livello 3 – Test su scenari reali (prima di ogni campagna): Prima di ogni campagna paid o lancio di prodotto, esegui un test di carico con
k6oLoader.ioper simulare il traffico atteso e identificare i punti di rottura dell’infrastruttura prima che li trovino i tuoi utenti.
La velocità del sito è una leva competitiva, non un checkbox tecnico
I 10 fattori descritti in questo articolo hanno una cosa in comune: nessuno di essi appare come problema ovvio in un report standard. Si nascondono nei dettagli dell’infrastruttura, nelle integrazioni accumulate nel tempo, nelle configurazioni lasciate ai default.
Ma la loro somma è tutt’altro che invisibile. Si manifesta in un LCP di campo mediocre, in un bounce rate più alto del previsto, in un ranking organico che non decolla nonostante i contenuti di qualità.
Il passo successivo è concreto: apri PageSpeed Insights, analizza le 5 pagine con più traffico organico del tuo sito, e confronta i risultati con i dati di campo in Google Search Console. Quella distanza, tra laboratorio e campo, tra aspettative e realtà, è il tuo vero piano d’azione.
La performance web non è un progetto. È una disciplina continuativa che, quando diventa parte del modo in cui un team di marketing pensa al sito, produce ritorni composti nel tempo: più posizioni, più conversioni, più fiducia degli utenti.
Domande frequenti sui fattori che rallentano il sito web
1. Se ho già un buon punteggio su PageSpeed Insights, devo comunque preoccuparmi di questi fattori?
Sì, e questa è una delle incomprensioni più costose nel SEO tecnico. PageSpeed Insights misura le performance in laboratorio, su una connessione simulata e un dispositivo emulato. Ciò che Google usa per il ranking sono i dati di campo del report CrUX (Chrome User Experience Report), che riflettono le esperienze reali dei tuoi utenti su device e connessioni eterogenee.
Un sito con punteggio laboratorio di 85 può avere dati di campo “scarsi” se la sua audience è prevalentemente su mobile e reti 4G lente. Controlla sempre la sezione “Core Web Vitals” di Google Search Console per i dati reali.
2. Qual è l'ordine di priorità per affrontare questi 10 fattori su un sito con risorse limitate?
Inizia dai problemi con il più alto impatto sistemico: TTFB elevato (Fattore #1) e JavaScript bloccante (Fattore #2). Questi impattano ogni singola pagina del sito.
In seconda battuta, affronta il CLS (Fattore #8) perché è spesso risolvibile con poche righe di HTML. Lascia per ultimo CSS inutilizzato e ottimizzazione database, che richiedono più lavoro di implementazione e testing.
3. Gli script di terze parti come i pixel Meta o Google Ads influenzano davvero il ranking SEO?
Sì, indirettamente ma in modo misurabile. Non è il pixel in sé che penalizza, è l’effetto che ha sul Total Blocking Time (TBT) e sul LCP. Se il tuo pixel Meta viene caricato sincrono nel <head> e aggiunge 400ms al rendering, quei 400ms si riflettono nei tuoi Core Web Vitals di campo.
Google non sa che il colpevole è il pixel Meta: vede solo che la tua pagina è lenta per gli utenti reali. La soluzione è gestire tutti i pixel tramite Google Tag Manager con caricamento differito.
4. Il passaggio a HTTP/3 migliora davvero le performance in modo percepibile?
In scenari specifici, sì e in modo significativo. HTTP/3 usa il protocollo QUIC invece di TCP, eliminando il problema del head-of-line blocking: se un pacchetto va perso su una connessione instabile, HTTP/2 blocca tutti i flussi in attesa; HTTP/3 no.
Il vantaggio è particolarmente evidente su connessioni mobili con packet loss elevato (4G instabile, WiFi congestionato). Per i siti con audience prevalentemente mobile e internazionale, l’upgrade a HTTP/3, disponibile nativamente su Cloudflare e nei principali CDN, può produrre miglioramenti di 200-400ms sul LCP di campo.
Sembra magia?
Non ci credi, vero?! Provalo!
Prova la nostra soluzione, goditi i risultati e decidi per quanto tempo mantenere attivo il tuo abbonamento.
){kind=link}
Share