Sulla velocità sito web e SEO circola da quasi vent’anni la stessa promessa mal riposta: accelera le pagine e salirai in classifica. Non funziona così, e non ha mai funzionato così. Google non premia chi è veloce, penalizza chi è insopportabilmente lento. È una differenza che sembra sottile e invece cambia completamente le priorità di un intervento tecnico, il budget che ha senso destinargli e le aspettative che è onesto costruire attorno al risultato. Questo articolo, nato nel 2013 attorno a una risposta di Matt Cutts, viene aggiornato periodicamente perché la domanda continua a tornare identica mentre le metriche cambiano nome ogni tre o quattro anni. Qui trovi cosa dice davvero Google oggi, quali soglie contano, dove si perde tempo per davvero e quali cause di lentezza nessuno guarda perché non sono problemi di performance.
Che cosa dice davvero Google sulla velocità come fattore di posizionamento
La documentazione ufficiale è più prudente di qualsiasi articolo divulgativo. Google conferma che i Core Web Vitals sono usati dai suoi sistemi di ranking, e nella stessa pagina aggiunge che ottenere buoni risultati nel report di Search Console non garantisce affatto di posizionarsi in cima. Anzi, precisa che al di là dei Core Web Vitals gli altri aspetti della page experience non aiutano direttamente una pagina a salire. Sono due frasi che convivono nello stesso documento e vanno lette insieme, come spiegato nella guida ufficiale alla page experience di Google Search Central, aggiornata a dicembre 2025.
Tradotto in pratica: la velocità è un segnale di secondo livello. Interviene quando tutto il resto è comparabile, e interviene soprattutto in negativo. Se due pagine rispondono allo stesso intento con la stessa autorevolezza e la stessa qualità, quella che fa aspettare l’utente sette secondi parte svantaggiata. Se invece il contenuto è mediocre, nessun punteggio verde lo salverà. Chi promette scalate di posizioni in cambio di un’ottimizzazione tecnica sta vendendo la parte facile del lavoro come se fosse quella decisiva. Se vuoi capire come funzionano nel dettaglio le metriche in gioco, ne ho scritto in modo esteso nella guida ai Core web vitals: cosa sono, come misurarli e quanto pesano sulla SEO.
Diciassette anni di risposte quasi identiche
Questo è il punto che rende la questione interessante e che nessuno racconta, perché per raccontarlo serve un archivio. Seguo la domanda “la velocità conta per il posizionamento?” da quando è stata posta la prima volta, e ho pubblicato su questo sito le risposte man mano che arrivavano. Rileggerle in fila è istruttivo, perché la sostanza non si è mai spostata di molto mentre il vocabolario è cambiato tre volte.
2009 e 2010: il piccolo bonus
Nel 2009 la formulazione era già cauta: se hai un sito veloce ottieni un piccolo bonus, se hai un sito terribilmente lento forse agli utenti non piacerà molto. L’anno dopo la posizione si affinò: a parità di rilevanza e di backlink, viene probabilmente preferito quello più veloce. Sono le due tappe che avevo annotato allora e che restano online, in La velocità condizionerà il posizionamento? e in La velocità viene prima della pertinenza?. Nota il condizionale in entrambi i titoli. Non era prudenza retorica: all’epoca meno dell’uno per cento delle query risultava influenzato dal fattore site speed.
2013: la svalutazione dei siti eccessivamente lenti
Poi arrivò la risposta che ha dato origine a questo articolo. A parità di fattori, disse Matt Cutts, se il tuo sito è molto molto lento Google può considerare la velocità di caricamento ai fini del ranking. E aggiunse un metodo di valutazione che vale ancora oggi, forse più di allora: non ragionare in secondi assoluti, guarda i siti che compaiono nelle tue stesse SERP e chiediti se sei molto distante da tutti gli altri. Il benchmark non è una soglia universale, è il tuo vicinato competitivo. La sintesi di quel periodo la conservo così com’era: non c’è un vantaggio per i siti veloci, c’è solo una svalutazione dei siti eccessivamente lenti.
Dal 2021 a oggi: Page Experience, Core Web Vitals, INP
Nel 2021 Google ha formalizzato il Page Experience Update e ha dato nomi propri a tre metriche. Nel marzo 2024 una di queste è stata sostituita: Interaction to Next Paint ha preso il posto di First Input Delay come Core Web Vital stabile, con la soglia di 200 millisecondi per almeno il 75 per cento delle interazioni, come documentato nell’annuncio ufficiale di web.dev sul passaggio a INP. Cambio di metrica, stessa filosofia. Vale la pena rileggere anche il punto intermedio che avevo fatto qualche anno fa in Velocità e posizionamento: facciamo il punto: la traiettoria è coerente e prevedibile.
Diciassette anni, quattro nomenclature, una sola sostanza. Chi ti dice che “quest’anno è cambiato tutto” o non ha l’archivio o ha qualcosa da venderti.
Le tre metriche che contano oggi e le soglie reali
Oggi i Core Web Vitals sono tre e conviene conoscerli per nome, perché sono il linguaggio con cui Google, Search Console e qualunque consulente serio discutono di performance.
- LCP (Largest Contentful Paint): quanto tempo passa prima che compaia l’elemento visivo più grande della pagina. Soglia buona sotto i 2,5 secondi.
- INP (Interaction to Next Paint): quanto la pagina impiega a rispondere visivamente a un’interazione dell’utente. Soglia buona sotto i 200 millisecondi.
- CLS (Cumulative Layout Shift): quanto il layout si sposta mentre la pagina carica. Soglia buona sotto lo 0,1.
Il dato che riporta meglio di ogni discorso la reale competitività di questo terreno viene dall’analisi annuale su decine di milioni di siti pubblicata dall’HTTP Archive Web Almanac 2025, capitolo performance: nel 2025 solo il 48 per cento delle origini supera tutti e tre i Core Web Vitals su mobile, contro il 44 per cento dell’anno precedente. Su desktop si arriva al 56 per cento. Detto altrimenti: più di metà del web mobile non passa l’esame. Il che significa due cose opposte e ugualmente vere. La prima è che essere sopra soglia non è un vantaggio competitivo, perché quasi un sito su due lo è. La seconda è che essere sotto soglia ti mette nella metà che l’utente abbandona.
Lo stesso studio dice anche dove si rompe la catena. L’elemento LCP è un’immagine nell’85,3 per cento dei siti desktop e nel 76 per cento di quelli mobile, il formato JPG copre ancora il 57 per cento delle immagini LCP, e tra il 16 e il 17 per cento dei siti applica il lazy loading proprio all’immagine principale, ritardando l’unica cosa che l’utente sta aspettando. Non è un problema di infrastruttura. È un problema di scelte fatte senza guardare i dati.
Dove si perde davvero tempo su un sito italiano
Nella nostra pratica quotidiana, su siti di PMI italiane, l’ordine dei colpevoli è quasi sempre lo stesso e quasi mai coincide con quello che il cliente si aspetta. Chi arriva convinto di dover cambiare hosting nove volte su dieci ha un problema di immagini e di script di terze parti, non di server.
Le immagini restano il primo imputato: caricate a piena risoluzione, servite in formati datati, senza dimensioni dichiarate nel markup (che è poi la causa più banale di CLS). Subito dopo vengono i temi commerciali generalisti, quelli che portano venti funzionalità di cui ne userai due e caricano comunque i CSS e i JavaScript di tutte e venti. Terzo, l’accumulo di plugin: ogni plugin installato “per provare” e mai rimosso continua a mettere in coda le sue richieste. Quarto, e solo quarto, l’hosting condiviso sottodimensionato, che diventa determinante quando il TTFB supera stabilmente il secondo. Se vuoi capire quando l’infrastruttura è davvero il collo di bottiglia, ho chiarito le differenze di base in Hosting e dominio: differenze, caratteristiche e significati.
C’è poi una categoria che merita un discorso a parte, perché è la più sottovalutata di tutte e perché quasi nessuno la collega alla velocità.
Cookie banner, tag marketing e il costo di conformità che nessuno misura
Su un sito italiano medio la prima cosa che l’utente vede non è il contenuto. È la Consent Management Platform. E la CMP, per fare il suo mestiere correttamente, deve caricarsi prima di tutto il resto, bloccare gli script non tecnici finché non arriva il consenso, e poi sbloccarli. È un lavoro che pesa sulla parte più delicata del caricamento, esattamente dove si misura l’LCP.
Questo lavoro non è opzionale. Le Linee guida cookie e altri strumenti di tracciamento del Garante per la protezione dei dati personali, deliberazione n. 231 del 10 giugno 2021, stabiliscono che i cookie non tecnici restino disabilitati per impostazione predefinita, che lo scrolling da solo non costituisca consenso valido e che i cookie wall di tipo “prendere o lasciare” siano illeciti. Da consulente privacy certificato e membro Federprivacy dico una cosa impopolare tra chi si occupa solo di performance: non si ottimizza la velocità disattivando la conformità. Si ottimizza riducendo il numero di tag che devono essere gestiti.
Ed è qui che il discorso diventa concreto. La maggior parte dei siti che analizziamo ha attivi tag di marketing che nessuno usa più: un pixel di una campagna chiusa due anni fa, tre strumenti di analytics sovrapposti, un chatbot in prova mai disinstallato, un tool di heatmap che ha registrato dati per un mese nel 2023. Ognuno di questi è contemporaneamente un peso sul caricamento, una superficie di rischio privacy e una voce nell’informativa che probabilmente non è più aggiornata. Ripulire il tag manager è l’intervento con il miglior rapporto tra sforzo e risultato che conosca, e il fatto che sia anche un adempimento di compliance lo rende difficile da rimandare.
Quando la lentezza è un sintomo di sicurezza, non di performance
Questa parte non la leggi quasi mai in un articolo SEO, e a mio parere è la più importante. Un sito che rallenta improvvisamente, senza che nessuno abbia pubblicato nulla o installato nulla, molto spesso non ha un problema di velocità. Ha un problema di sicurezza che si manifesta come problema di velocità.
Da Certified Professional Ethical Hacker e da consulente tecnico d’ufficio ho visto ricorrere gli stessi tre pattern. Il primo: un plugin compromesso che inietta codice, di solito redirect condizionali o script di cryptomining, attivi solo per visitatori che arrivano dai motori di ricerca. Il proprietario, che entra dal bookmark, non vede nulla e non capisce perché “Google dice che il sito è lento”. Il secondo: traffico bot non filtrato che satura le risorse del server. Le metriche di campo peggiorano perché il server risponde male sotto carico, non perché il codice sia scritto male. Il terzo: una configurazione a valle mal gestita, tipicamente un WAF o un proxy inserito di fretta, che aggiunge latenza su ogni richiesta senza che nessuno ne misuri l’impatto.
La regola operativa che ne ricavo è semplice: quando il TTFB peggiora in modo brusco e non spiegabile, la prima diagnosi non è “ottimizziamo le immagini”. La prima diagnosi è capire chi sta usando quel server e per fare cosa. Sono situazioni in cui la SEO e la sicurezza informatica smettono di essere due discipline separate, e in cui trattarle separatamente porta a mesi di interventi inutili. È uno dei motivi per cui ho raccolto anni di casi di questo tipo nel libro Siti da incubo, disponibile gratuitamente.
Come si aggredisce ciascuna delle tre metriche
Qui serve essere operativi, perché “ottimizzare la velocità” non è un’attività: sono tre attività diverse che condividono solo il nome. Confonderle è il motivo per cui tanti interventi non spostano nulla. Chi ha un problema di INP e passa tre settimane a comprimere immagini otterrà un LCP migliore e un INP identico.
LCP: quasi sempre una questione di immagini e di primo byte
Il Largest Contentful Paint misura quando compare l’elemento più grande della finestra visibile. Nella stragrande maggioranza dei casi quell’elemento è un’immagine, e la catena di errori è sempre la stessa. L’immagine viene caricata a risoluzione piena anche quando verrà mostrata a un quarto delle dimensioni. Viene servita in un formato che pesa il doppio del necessario. Non ha le dimensioni dichiarate nel markup, quindi il browser non sa quanto spazio riservarle. E in una percentuale imbarazzante di siti le viene applicato il lazy loading, cioè le si dice esplicitamente di caricarsi dopo, quando è l’unica cosa che l’utente sta guardando.
Gli interventi in ordine di resa: dichiara sempre larghezza e altezza, converti in un formato moderno, genera più varianti dimensionali e lascia che sia il browser a scegliere, rimuovi il lazy loading dall’immagine principale e anzi segnalala come prioritaria. Se dopo tutto questo l’LCP resta sopra soglia, allora il problema si è spostato a monte, sul tempo che il server impiega a rispondere. Ed è a quel punto, non prima, che ha senso mettere in discussione l’hosting.
INP: quasi sempre una questione di JavaScript
L’Interaction to Next Paint misura la reattività. Quanto tempo passa tra il momento in cui l’utente tocca qualcosa e il momento in cui vede succedere qualcosa. Quando questa metrica è fuori soglia la causa è quasi sempre un thread principale occupato: troppo JavaScript da eseguire, eseguito tutto insieme, spesso proveniente da script che non hai scritto tu.
Gli interventi utili sono meno immediati che sull’LCP ma più duraturi. Rimuovere il codice inutilizzato che i temi generalisti caricano per funzionalità che non hai attivato. Rinviare tutto ciò che non serve al primo rendering. Spezzare le operazioni lunghe in blocchi più piccoli, così che il browser possa rispondere all’utente tra un blocco e l’altro. E soprattutto ridurre il numero di script di terze parti, che è il punto in cui si torna sempre, qualunque sia la metrica di partenza.
CLS: quasi sempre una questione di spazio non riservato
Il Cumulative Layout Shift misura quanto la pagina si muove sotto le dita dell’utente mentre carica. È la metrica più fastidiosa per chi naviga e la più semplice da risolvere per chi sviluppa, perché la causa è quasi sempre banale: elementi che si inseriscono nel flusso senza che qualcuno abbia riservato loro lo spazio. Immagini senza dimensioni, banner che compaiono in alto e spingono giù il contenuto, font personalizzati che sostituiscono quello di sistema cambiando l’ingombro del testo, contenuti caricati dopo che si incastrano in mezzo a quelli già visibili.
La regola è una sola e vale per tutti i casi: se un elemento arriverà, riservagli lo spazio da subito. Un contenitore delle dimensioni giuste, anche vuoto, risolve la quasi totalità dei problemi di CLS.
Un caso reale: il sito che era lento solo per Google
Un esempio dalla nostra pratica, anonimizzato ma reale nei dettagli tecnici. Un e-commerce di medie dimensioni ci contatta perché ha perso circa un terzo del traffico organico in sei settimane e Search Console segnala un peggioramento generalizzato dei Core Web Vitals. Il proprietario era già intervenuto: aveva cambiato piano di hosting, installato un plugin di cache e fatto ottimizzare le immagini da uno sviluppatore. Nessun miglioramento.
La prima cosa che abbiamo fatto non è stata un test di velocità. È stata la lettura dei log del server. Il pattern era chiaro: le richieste provenienti dai motori di ricerca ricevevano una risposta significativamente più lenta delle altre, e in una parte di quelle risposte veniva iniettato uno script aggiuntivo. Un plugin non aggiornato da due anni era stato compromesso, e il codice iniettato era condizionale, attivo solo per user agent e referrer specifici. Il proprietario, che entrava sempre dal proprio segnalibro e da un IP conosciuto, non aveva mai visto nulla di anomalo.
La bonifica ha richiesto meno tempo di tutti gli interventi di ottimizzazione fatti prima, e le metriche di campo sono rientrate nel giro di un mese. La lezione operativa non riguarda la velocità: riguarda l’ordine delle domande. Prima si chiede perché il sito si comporta così, poi si chiede come renderlo più rapido. Invertire questi due passaggi è il modo più comune di spendere budget senza risolvere niente.
Velocità, crawl budget e motori di risposta basati su AI
C’è un capitolo che fino a pochi anni fa non esisteva e che oggi va messo in conto. Il traffico automatizzato verso i siti è cresciuto in modo consistente, perché ai crawler tradizionali dei motori di ricerca si sono aggiunti quelli che alimentano i sistemi di risposta generativa e quelli che recuperano contenuti in tempo reale quando un utente pone una domanda a un assistente. Sono visitatori che non generano una sessione, non convertono e consumano risorse.
Per un sito su infrastruttura sottodimensionata questo cambia l’equazione. Il tempo di risposta del server non peggiora perché il sito è mal costruito, peggiora perché sta servendo un volume di richieste che non aveva previsto. E dato che le metriche di campo si basano sull’esperienza degli utenti reali durante quelle stesse ore, l’effetto si riversa sulle misurazioni che contano per il posizionamento.
Ci sono due implicazioni pratiche. La prima è che vale la pena sapere chi sta bussando: distinguere il traffico umano da quello automatizzato nei log è oggi un’attività di diagnosi delle performance, non solo di sicurezza. La seconda è che le decisioni su quali bot ammettere, quali limitare e quali bloccare sono diventate decisioni con un impatto misurabile sulla velocità percepita dagli utenti veri. Sono scelte che vanno prese consapevolmente, non lasciate all’impostazione predefinita di un plugin.
Aggiungo una nota controcorrente, perché la sento chiedere spesso. Non esiste ad oggi alcuna evidenza che i sistemi di risposta generativa privilegino i siti veloci nella selezione delle fonti da citare. Quello che è evidente è che un sito che risponde male o va in timeout quando viene interrogato semplicemente non viene letto. Anche qui, la lentezza è una tassa, la velocità non è un bonus.
Come si imposta un intervento che non sia teatro dei punteggi
Detto questo, resta la domanda pratica: da dove si comincia. La risposta parte da una distinzione che quasi tutti gli articoli sull’argomento ignorano, e che è la fonte di gran parte dei malintesi tra consulenti e clienti.
Esistono due tipi di dati sulla velocità. I dati di laboratorio, prodotti da uno strumento che simula un caricamento in condizioni standardizzate, e i dati di campo, raccolti dai browser degli utenti reali su una finestra mobile di 28 giorni. Google usa i secondi per il ranking, non i primi. Questo significa che il punteggio da 0 a 100 che tutti amano condividere è una diagnostica, non un obiettivo. Puoi arrivare a 100 in laboratorio e avere metriche di campo pessime, se i tuoi utenti reali navigano da mobile su rete lenta con un dispositivo di quattro anni fa. E puoi avere un punteggio mediocre in laboratorio e metriche di campo eccellenti.
Da qui discende un metodo che funziona e che si può riassumere in cinque mosse. Primo, guarda i dati di campo e solo quelli per decidere se hai un problema. Secondo, se ce l’hai, individua quale delle tre metriche è fuori soglia, perché le cause sono completamente diverse: LCP è quasi sempre immagini e risposta del server, INP è quasi sempre JavaScript, CLS è quasi sempre dimensioni non dichiarate e contenuti che si inseriscono dopo. Terzo, misura prima di toccare, così avrai un termine di paragone. Quarto, intervieni su una cosa alla volta, altrimenti non saprai mai che cosa ha funzionato. Quinto, aspetta. I dati di campo si muovono su 28 giorni, e chi ti mostra un miglioramento il giorno dopo l’intervento ti sta mostrando il laboratorio.
Vale la pena ricordare anche perché tutto questo ha senso al di là del posizionamento. L’effetto più affidabile della velocità non è sul ranking, è sul comportamento: meno abbandoni, più pagine viste, più conversioni. Ne avevo scritto in Aumentare la velocità di un sito, aumenta le conversioni, e resta il motivo migliore per investirci, molto più solido della speranza di guadagnare posizioni. La velocità è una parte dell’esperienza complessiva, non un capitolo a sé: un sito veloce ma confuso resta un sito che non converte, come ho argomentato in L’usabilità migliora le performance del tuo sito.
Che cosa mettere in agenda questa settimana
Se vuoi tradurre tutto in attività concrete, l’ordine che consiglio è questo. Apri Search Console e guarda il report Core Web Vitals su mobile: se sei nel verde su tutti e tre gli indicatori, la velocità non è il tuo problema di posizionamento e le energie vanno spostate altrove. Se sei nel rosso, identifica quale metrica e attacca quella. Nel frattempo fai due cose che costano poco e rendono sempre: converti le immagini principali in un formato moderno con dimensioni dichiarate nel markup, e apri il tag manager per cancellare tutto ciò che non stai usando davvero. Infine, se il rallentamento è comparso all’improvviso, prima di ottimizzare fai un controllo di sicurezza.
Un ultimo avvertimento, perché di errori che sembrano tecnici e sono strategici ne vedo tanti: perdere sei mesi sulla velocità mentre il contenuto non risponde all’intento di ricerca è uno dei modi più efficienti di sprecare un budget SEO. Ne ho raccolti altri in 9 errori SEO che impattano sul posizionamento del tuo sito.
Riepilogo dei punti chiave
La velocità di un sito web non è un fattore che fa salire nella SERP: è un fattore che, se manca, può far scendere. Google conferma che i Core Web Vitals rientrano nei suoi sistemi di ranking e nello stesso documento avverte che superarli non garantisce alcuna posizione. La sostanza è la stessa dal 2009: nessun bonus per i veloci, una svalutazione per i troppo lenti. Le metriche attuali sono tre, LCP sotto 2,5 secondi, INP sotto 200 millisecondi (metrica che ha sostituito FID nel marzo 2024) e CLS sotto 0,1, e nel 2025 solo il 48 per cento delle origini le supera tutte su mobile. Le cause reali di lentezza, in ordine di frequenza sui siti delle PMI italiane, sono immagini non ottimizzate, temi sovraccarichi, plugin accumulati, tag di marketing dimenticati e Consent Management Platform mal configurate, mentre l’hosting è responsabile molto più di rado di quanto si creda. Un caso specifico va trattato a parte: un rallentamento improvviso è spesso il sintomo di una compromissione di sicurezza, non di un problema di performance. Il metodo corretto usa i dati di campo su 28 giorni, non i punteggi di laboratorio, interviene su una metrica alla volta e misura prima di toccare.
Domande frequenti sulla velocità sito web e la SEO
La velocità è davvero un fattore di posizionamento su Google?
Sì, ma in modo asimmetrico. Google conferma che i Core Web Vitals sono usati dai suoi sistemi di ranking, e nello stesso documento precisa che superarli non garantisce di posizionarsi in alto. In pratica la velocità agisce come discriminante a parità di rilevanza e autorevolezza, e agisce soprattutto in negativo: un sito eccessivamente lento viene svalutato, un sito veloce non riceve un premio proporzionale. Chi promette scalate di posizioni in cambio della sola ottimizzazione tecnica sta sopravvalutando il peso di questo segnale.
Come misurare la velocità di un sito web?
Serve distinguere due tipi di misurazione. I dati di laboratorio provengono da uno strumento che simula un caricamento in condizioni standard e servono per diagnosticare le cause. I dati di campo provengono dai browser degli utenti reali su una finestra mobile di 28 giorni e sono quelli che Google usa per il ranking. Il punto di partenza corretto è il report Core Web Vitals di Search Console, che mostra i dati di campo del tuo sito divisi per mobile e desktop. Gli strumenti di laboratorio vanno usati dopo, per capire perché una metrica è fuori soglia.
Qual è lo speed test più affidabile?
Nessuno strumento è affidabile in assoluto, perché ognuno misura cose diverse in condizioni diverse. La domanda giusta è quale dato conta per il tuo obiettivo. Se l’obiettivo è capire come Google valuta il tuo sito, l’unica fonte che conta sono i dati di campo del Chrome User Experience Report, quelli che vedi in Search Console. Se l’obiettivo è capire dove intervenire, un test di laboratorio è più utile perché ti mostra la cascata delle richieste. Diffida dei punteggi sintetici da 0 a 100 usati come obiettivo: sono una diagnostica, non un traguardo.
Perché un sito è lento?
Nella pratica su siti di PMI italiane l’ordine delle cause è quasi sempre questo: immagini troppo pesanti o in formati datati, temi commerciali che caricano risorse per funzionalità mai usate, accumulo di plugin installati e mai rimossi, script di terze parti come pixel pubblicitari e strumenti di analytics sovrapposti, gestione del consenso mal configurata. L’hosting sottodimensionato è una causa reale ma meno frequente di quanto si creda, e diventa determinante quando il tempo di risposta del server supera stabilmente il secondo. Un caso a parte è il rallentamento comparso all’improvviso senza modifiche al sito, che spesso indica una compromissione di sicurezza.
Quanto deve essere veloce un sito per Google?
Le soglie ufficiali dei Core Web Vitals sono LCP sotto 2,5 secondi, INP sotto 200 millisecondi e CLS sotto 0,1, e vanno rispettate per almeno il 75 per cento delle visite. Esiste però un secondo criterio, suggerito da Google stesso e spesso dimenticato: non ragionare in secondi assoluti, guarda i siti che compaiono nelle tue stesse pagine di risultati e chiediti se sei molto distante da tutti gli altri. Il benchmark utile è il tuo vicinato competitivo, non una soglia universale.
Se miglioro la velocità salgo subito di posizione?
No, e nessun consulente serio dovrebbe promettertelo. I dati di campo che Google utilizza si calcolano su una finestra mobile di 28 giorni, quindi qualsiasi miglioramento visibile il giorno dopo l’intervento riguarda il laboratorio, non il campo. Al di là dei tempi, il guadagno più affidabile di un intervento sulla velocità non è sul ranking ma sul comportamento degli utenti: meno abbandoni, più pagine viste e un tasso di conversione più alto. È un ritorno più solido e più misurabile della speranza di guadagnare qualche posizione.
I cookie banner rallentano davvero il sito?
Sì, e in modo strutturale. Una Consent Management Platform deve caricarsi prima degli altri script per poter bloccare i cookie non tecnici finché non arriva il consenso, come richiesto dalle linee guida del Garante privacy. Questo la colloca esattamente nella fase più delicata del caricamento, dove si misura l’LCP. La soluzione non è disattivare la conformità, che è un obbligo, ma ridurre il numero di tag che la piattaforma deve gestire: ogni pixel dimenticato e ogni strumento in prova mai rimosso è contemporaneamente un peso sulle prestazioni e una voce da giustificare nell’informativa.
Il punto, dopo diciassette anni
La velocità sito web resta esattamente quello che era nel 2009: una condizione igienica, non una leva di crescita. Serve non essere lenti, non serve essere i più veloci. Quello che è cambiato è il contesto attorno: le metriche hanno nomi propri, i dati di campo sono pubblici, e le cause di lentezza si sono spostate dal server verso il codice di terze parti che accumuliamo senza accorgercene. Chi ha un sito nel verde su tutti e tre gli indicatori e continua a non posizionarsi ha un problema di contenuto, di intento o di autorevolezza, e insistere sulla parte tecnica non lo risolverà.
Se non sai a quale delle due categorie appartieni, il modo più rapido per scoprirlo è guardare i dati di campo del tuo sito insieme a qualcuno che sappia leggerli e che ti dica anche quando il problema non è la velocità.
Richiedi una consulenza gratuita: se vuoi capire dove sta davvero il collo di bottiglia del tuo sito, scrivimi e ne parliamo senza impegno. E se preferisci partire da solo, puoi scaricare gratis il libro Siti da Incubo, dove trovi raccolti anni di casi reali di siti lenti, compromessi e mal progettati.
