Quante volte hai aperto un sito che ci mette 6 secondi a caricare? Esatto, nemmeno io. Lo chiudo subito. E lo stesso fa il 53% degli utenti mobile dopo 3 secondi, secondo i dati di Google. La velocità del sito non è un dettaglio tecnico per smanettoni: è una delle cose che decide se arrivi in prima pagina o resti sepolto a pagina 4.
In questo pezzo ti spiego come ottimizzare un sito per la velocità, partendo da quello che davvero sposta il ranking, senza perderci dietro a micro-ottimizzazioni che fanno guadagnare 0,2 secondi e basta.
📌 Key Takeaways
| Cosa devi sapere | In sintesi |
|---|---|
| Tempo di caricamento ideale | Sotto i 2,5 secondi su mobile |
| Metrica più importante | LCP (Largest Contentful Paint) |
| Primo intervento da fare | Comprimere immagini in WebP |
| Strumento gratuito #1 | Google PageSpeed Insights |
| Impatto SEO stimato | Fino al +30% di traffico organico dopo ottimizzazione |
| Errore più comune | Hosting condiviso troppo lento |
| Quanto pesa la mobile | 70%+ delle ricerche viene da smartphone |
1. Perché la velocità del sito pesa davvero sul ranking di Google
Te lo dico subito: Google non ti penalizza solo perché il sito è lento. Ti penalizza perché un sito lento crea utenti scontenti, e Google odia mandare i suoi utenti su pagine scontente. È più una questione di esperienza che di “punizione algoritmica”.
Dal 2021 con l’introduzione di Page Experience, e poi con l’aggiornamento dei Core Web Vitals, la velocità è diventata un fattore di ranking confermato. Non il più importante — il contenuto resta re — ma sicuramente uno di quelli che fa la differenza tra te e il competitor che ha un articolo simile al tuo. Se siete pari sui contenuti, vince chi carica prima. Punto.
Quanto pesa la velocità rispetto ad altri fattori? Diciamo intorno al 5-10% del peso totale dell’algoritmo, ma il problema è che agisce su due livelli:
- Diretto: Google misura le prestazioni della pagina e le usa nel ranking
- Indiretto: gli utenti che escono subito dal tuo sito mandano segnali negativi (bounce rate alto, dwell time basso)
Il secondo punto è quello che fa più danni nel lungo periodo. Ho visto siti perdere il 40% di traffico organico in 6 mesi solo perché il TTFB era schizzato sopra i 1500ms dopo un cambio di hosting. Nessun aggiornamento di contenuto avrebbe potuto salvarli senza prima sistemare il server.
C’è anche un altro motivo per cui ti conviene farti questi calcoli: la velocità influenza il budget di crawl di Google. Se il bot deve aspettare 5 secondi per ogni pagina, ne scansiona di meno nello stesso intervallo di tempo. Risultato? Le tue pagine nuove vengono indicizzate più lentamente, gli aggiornamenti tardano a essere visti, e tutto il lavoro SEO ne risente.
Una cosa che molti non considerano: la velocità influisce anche sul tasso di conversione. Amazon ha calcolato che ogni 100ms di ritardo le costa l’1% di vendite. Se gestisci un e-commerce, ogni secondo guadagnato si traduce direttamente in soldi. Non è teoria, sono dati.
Domanda che mi fanno spesso: “Ma se il mio sito carica in 4 secondi, posso lasciare perdere?”. Risposta: dipende. Se sei in una nicchia con poca concorrenza forse te la cavi, ma in qualsiasi mercato un po’ competitivo (e-commerce, finanza, salute, marketing) sotto i 3 secondi non è più negoziabile.
2. Core Web Vitals: LCP, INP e CLS spiegati senza giri di parole
I Core Web Vitals sono tre metriche che Google ha scelto come standard per misurare l’esperienza utente. Tre numeri, niente di più. Te li spiego come li spiegherei a un cliente davanti a un caffè.
LCP (Largest Contentful Paint) misura quanto ci mette a comparire l’elemento più grande della pagina visibile a schermo. Tipicamente è l’immagine hero o un blocco di testo grosso. Deve stare sotto i 2,5 secondi. Se il tuo LCP è a 4 secondi, c’è qualcosa che non va: di solito è un’immagine non ottimizzata o un server lento.
INP (Interaction to Next Paint) ha sostituito FID nel marzo 2024. Misura quanto velocemente il sito risponde quando l’utente clicca o tocca qualcosa. Soglia: sotto i 200ms. Se clicchi un menu e ci mette mezzo secondo a aprirsi, INP è in difficoltà. Quasi sempre la colpa è di JavaScript pesante che blocca il main thread.
CLS (Cumulative Layout Shift) misura quanto la pagina “balla” mentre carica. Hai presente quando stai per cliccare un bottone e all’ultimo secondo si sposta perché si è caricato un banner? Quello è CLS. Soglia: sotto 0,1. Si risolve mettendo dimensioni esplicite a immagini, video e iframe.
| Metrica | Cosa misura | Buono | Da migliorare | Cattivo |
|---|---|---|---|---|
| LCP | Velocità di caricamento contenuto principale | ≤ 2,5s | 2,5s – 4s | > 4s |
| INP | Reattività della pagina | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | Stabilità visiva | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Una cosa importante: Google usa i dati reali raccolti tramite il CrUX Report (Chrome User Experience Report), non i test sintetici. Vuol dire che PageSpeed Insights ti mostra due colonne, una con i dati di laboratorio e una con i dati di campo. I dati di campo sono quelli che contano per il ranking. Quelli di laboratorio servono per fare debug.
Ho lavorato su un sito di e-commerce moda dove l’LCP era a 6,8s. Abbiamo capito che il problema era un’immagine hero da 4MB caricata senza preload. L’abbiamo compressa in WebP (450KB) e aggiunto fetchpriority="high". LCP sceso a 1,9s in due settimane. Le pagine prodotto hanno guadagnato in media 4 posizioni in SERP nei mesi successivi. Non c’è stato altro intervento, solo quello.
Per vedere i tuoi Core Web Vitals reali apri Search Console → Esperienza → Segnali web essenziali. Lì hai il quadro vero, non le simulazioni.
3. Ottimizzare le immagini: WebP, AVIF e lazy loading
Le immagini sono il primo posto dove guardare quando un sito è lento. Su un sito web normale rappresentano il 50-70% del peso totale della pagina. Se hai 8MB di immagini, non c’è hosting sul pianeta che possa farti caricare in 2 secondi. Si parte da qui.
Compressione e formati moderni sono la base. Smetti di usare JPG e PNG dove non serve. WebP riduce il peso del 25-35% rispetto a JPG mantenendo la stessa qualità visiva. AVIF va anche oltre, fino al 50%, anche se il supporto è leggermente meno universale (ma ormai ci siamo). Usa un fallback con <picture>:
<picture>
<source srcset="immagine.avif" type="image/avif">
<source srcset="immagine.webp" type="image/webp">
<img src="immagine.jpg" alt="descrizione" width="800" height="600">
</picture>
Nota i width e height espliciti — quelli aiutano a tenere CLS basso.
Lazy loading rinvia il caricamento delle immagini sotto la piega finché l’utente non scorre. Da Chrome 76 in poi basta aggiungere loading="lazy" al tag <img> e sei a posto. Niente plugin, niente JavaScript custom. Importante però: l’immagine hero, quella che è subito visibile, deve essere loading="eager" o senza attributo. Se metti lazy lì peggiori l’LCP.
Ecco una checklist pratica delle cose da fare sulle immagini:
- Converti tutto in WebP (per i CMS WordPress vanno bene plugin come ShortPixel, EWWW o Imagify)
- Servi immagini di dimensioni diverse a dispositivi diversi con
srcset - Aggiungi sempre
widtheheightper evitare layout shift - Comprimi prima di caricare: 80-85% di qualità è invisibile all’occhio ma dimezza il peso
- Usa
loading="lazy"su tutto quello che sta sotto la piega - Su immagine hero metti
fetchpriority="high"per dirgli “questa è prioritaria”
Un errore che vedo spessissimo: gente che carica foto da iPhone direttamente sul sito, 4032×3024 pixel, 5MB l’una. Poi le mostra in un riquadro 800×600. Stai facendo scaricare al browser 25 volte i dati che gli servono. Ridimensiona prima di caricare, o usa un servizio che lo fa al volo.
Per i loghi e le icone semplici, considera SVG. Pesano poche centinaia di byte, sono vettoriali (scalano perfettamente), e non hanno bisogno di compressione. Per icone complesse, font-icon come Lucide o un sprite SVG inline sono soluzioni perfette.
Ah, una cosa che molti dimenticano: rimuovi i metadati EXIF dalle foto prima di pubblicarle. Sono dati inutili (data di scatto, modello fotocamera, GPS) che pesano qualche KB per immagine. Su un sito con 200 immagini sono mezzo MB risparmiato gratis.
4. Caching del browser e caching lato server
Il caching è il trucco più potente per la velocità che esista. L’idea è semplice: invece di rigenerare ogni volta la stessa pagina, te la salvi già pronta e la servi così com’è. Costo: zero. Beneficio: enorme.
Esistono due tipi principali di caching che ti servono entrambi.
Caching del browser (client-side) dice al browser dell’utente: “Questo file CSS non cambia mai, salvatelo e non richiedermelo per i prossimi 30 giorni”. La seconda volta che l’utente visita una tua pagina, il caricamento è quasi istantaneo perché tutti gli asset statici (immagini, CSS, JavaScript, font) sono già nel suo browser. Si configura con header HTTP tipo Cache-Control: max-age=2592000 (30 giorni) o tramite il file .htaccess su Apache.
Caching lato server serve a evitare che il server rigeneri ogni volta la pagina interrogando il database. Con un sito WordPress senza cache, ogni visita fa partire decine di query MySQL. Con la cache attiva, la pagina HTML completa viene salvata su disco la prima volta, e le visite successive ricevono direttamente quel file. Differenza? Da 2-3 secondi di TTFB a 100-200ms.
| Tipo di caching | Cosa fa | Strumenti consigliati |
|---|---|---|
| Browser cache | Salva file statici nel browser dell’utente | .htaccess, Cache-Control |
| Page cache | Salva HTML pre-generato sul server | WP Rocket, LiteSpeed Cache, W3 Total Cache |
| Object cache | Salva risultati query database in memoria | Redis, Memcached |
| Opcode cache | Salva codice PHP compilato | OPcache (di solito attivo di default) |
| CDN cache | Salva contenuti in nodi vicini all’utente | Cloudflare, BunnyCDN, KeyCDN |
Su WordPress, se usi un hosting decente come SiteGround, Kinsta o WP Engine, il page cache è già attivo lato server. Aggiungi WP Rocket o LiteSpeed Cache per gestire le configurazioni avanzate (preload, mobile cache, exclusions). Se invece sei su un hosting condiviso economico, installare un plugin di cache è la prima cosa da fare prima di pensare a qualsiasi altra ottimizzazione.
Un dettaglio che spesso si trascura: quando aggiorni un contenuto la cache va svuotata, sennò gli utenti vedono ancora la versione vecchia. La maggior parte dei plugin lo fa in automatico ma a volte fallisce. Se modifichi qualcosa e non lo vedi aggiornato in incognito, svuota la cache manualmente prima di impazzire.
Per chi gestisce siti più complessi, l’object cache con Redis è il salto successivo. Mette le query del database in memoria RAM, e velocizza tantissimo le aree dinamiche del sito (carrello, area utenti, filtri). Su un e-commerce con 50.000 prodotti la differenza si sente eccome.
C’è un caso in cui ho lavorato dove il TTFB stava a 1800ms. Abbiamo attivato Redis + WP Rocket + Cloudflare APO. Il TTFB è sceso a 230ms. Il sito è passato da PageSpeed score 41 a 89 senza toccare nulla del tema o del codice. Pura infrastruttura.
5. CDN e hosting: dove vivono i tuoi file conta
Te lo metto in modo chiaro: se hai un hosting condiviso da 4€ al mese e ti chiedi perché il sito è lento, smetti di chiedertelo. Hai trovato la risposta.
L’hosting è la fondamenta. Tutto il resto — cache, ottimizzazioni, plugin di velocità — sta sopra. Se le fondamenta sono di sabbia, il palazzo cade. Un buon hosting per un sito business in Italia parte da circa 25-30€ al mese (SiteGround GoGeek, Register Cloud Pro, Aruba Premium con SSD). Per progetti seri da 5.000+ visite al giorno, conviene salire su VPS gestiti o managed hosting tipo Kinsta o WP Engine, dove parli di 35-100€ al mese ma hai prestazioni serie.
Cosa guardare quando scegli un hosting:
- Disco SSD/NVMe (mai più HDD)
- PHP 8.2 o superiore
- HTTP/2 o HTTP/3 abilitato
- TTFB sotto i 300ms in test reali
- Server in Europa se il tuo pubblico è italiano (no server USA per traffico ITA)
- Risorse dedicate invece di shared hosting affollato
Sul fronte CDN (Content Delivery Network), il discorso è diverso ma complementare. Un CDN copia i tuoi file statici su una rete di server sparsi in tutto il mondo. Quando un utente da Tokyo visita il tuo sito italiano, riceve immagini e CSS dal server più vicino a lui invece che dall’Italia. Risparmi centinaia di millisecondi per richiesta.
Cloudflare ha un piano gratuito che copre l’80% delle esigenze. Ti dà CDN, DDoS protection, ottimizzazioni automatiche di immagini (con il piano Pro), e cache globale. Per chi vuole spingere ancora di più, Cloudflare APO per WordPress costa 5€/mese e cachea l’HTML completo sui suoi 300+ data center mondiali. Il TTFB scende sotto i 50ms ovunque nel mondo.
Alternative che funzionano bene: BunnyCDN (economico e veloce, parte da 0,01€/GB), KeyCDN, Fastly (per progetti enterprise). Per chi gestisce e-commerce internazionali con clienti in più continenti, un CDN non è un optional.
Una domanda che mi fanno: “Devo prendere CDN anche se vendo solo in Italia?” Risposta: sì, ma con una sfumatura. Anche se i tuoi clienti sono tutti italiani, un CDN ti dà comunque vantaggi in termini di sicurezza, ottimizzazioni automatiche, resistenza ai picchi di traffico. E se mai ricevi un attacco DDoS, ti salva il culo. Il costo è basso, il beneficio largo.
Per casi più complessi tipo siti enterprise o piattaforme con esigenze custom, i casi studio del nostro team mostrano che il salto di hosting fa la differenza più grande in assoluto sulle performance, prima ancora di tutte le micro-ottimizzazioni di codice.
6. Minificare CSS, JavaScript e HTML senza rompere il sito
Il codice del tuo sito contiene un sacco di roba inutile per il browser: spazi, commenti, righe vuote, variabili con nomi lunghi. Tutto questo serve a te (o al tuo sviluppatore) per leggere il codice, ma per il browser è zavorra. La minificazione rimuove tutta questa roba.
Un file CSS di 100KB, dopo minificazione, può scendere a 70-75KB. Un file JavaScript di 500KB può arrivare a 320KB. Sembra poco ma sommato a tutti gli script di un sito moderno (di solito 30-50 file) la differenza è netta.
Oltre alla minificazione, ci sono altre tecniche da affiancare:
- Combinare i file: invece di 12 file CSS separati, ne servi uno solo. Meno richieste HTTP = caricamento più veloce
- Compressione Gzip o Brotli: il server invia i file compressi, il browser li decomprime. Riduce il peso del 70-80% sul testo
- Defer e async sui JavaScript: gli script che non sono critici si caricano dopo il rendering della pagina
- Critical CSS: il CSS necessario per il primo schermo viene messo inline, il resto si carica dopo
Sul defer/async c’è confusione. Te lo spiego in due parole. Senza nessun attributo, lo script blocca il rendering della pagina mentre carica. Con async, scarica in parallelo e si esegue appena pronto (può ancora bloccare). Con defer, scarica in parallelo ma si esegue solo dopo che l’HTML è completo. Per il 90% degli script non critici, defer è la scelta giusta.
Un altro punto importante: rimuovere il JavaScript inutilizzato. Spesso WordPress carica jQuery, qualche plugin di slider che non usi su quella pagina, librerie di animazioni… tutto su tutte le pagine. Strumenti come Asset CleanUp o Perfmatters ti permettono di disattivare script specifici su pagine specifiche. Su un sito che ho lavorato siamo passati da 1,8MB di JS totale a 600KB facendo solo questo.
Per l’HTML c’è meno da grattare ma comunque vale la pena: WP Rocket e simili minificano l’HTML in automatico. Pochi KB risparmiati, ma sempre KB.
Una cosa che noto spesso: tanti siti caricano Google Fonts in maniera sbagliata. Il modo giusto è:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap">
Quel display=swap è cruciale: dice al browser “mostra subito un font di sistema, poi sostituiscilo con Inter quando arriva”. Senza quel parametro hai una FOIT (Flash of Invisible Text) di 3 secondi che ammazza l’esperienza.
E l’errore più comune di tutti: caricare 8 stili di font (light, regular, medium, semibold, bold, extrabold, italic ecc.) quando ne usi solo 2. Ogni stile è un file di 50-100KB.
7. Velocità mobile: il primo banco di prova di Google
Google indicizza il tuo sito partendo dalla versione mobile. Si chiama Mobile-First Indexing, è attivo da anni, e significa una cosa sola: se il tuo sito è veloce su desktop ma lento su smartphone, per Google è lento e basta. Le metriche che vede sono quelle mobile.
E il problema è che ottimizzare per mobile è più difficile. Hai connessioni 4G/5G non sempre stabili, hardware meno potente, schermi piccoli con tanti elementi da caricare. Quello che gira fluido sul tuo MacBook a 1Gbps può essere un disastro su uno smartphone Android di fascia media con segnale a tre tacche.
Ecco le cose specifiche da curare per la velocità mobile:
- Responsive immagini con srcset: servi un’immagine da 400px al mobile, non quella da 1920px
- Touch target adeguati: bottoni grandi almeno 48×48 pixel, distanziati. Aiuta INP
- Riduci richieste di terze parti: ogni pixel di tracking, ogni chat widget, ogni plugin social aggiunge JS. Mobile soffre di più
- Test reale su dispositivi medi: non testare solo su iPhone 15 Pro. Prendi uno smartphone Android da 200€ e prova lì
- AMP? No grazie (più o meno): Google ha deprezzato AMP nel ranking. Non serve più. Concentrati su Core Web Vitals nativi
Per Google Ads e tutto il traffico a pagamento mobile vale lo stesso discorso, anzi peggiora: una landing page lenta significa Quality Score basso, CPC più alto, e budget bruciato peggio. Un sito che converte da desktop ma non da mobile sta letteralmente buttando soldi.
Strumenti specifici per testare il mobile:
| Strumento | Cosa fa | Gratis |
|---|---|---|
| PageSpeed Insights | Test mobile e desktop con dati reali | Sì |
| WebPageTest | Test su dispositivi mobili reali in tutto il mondo | Sì (limitato) |
| Lighthouse Mobile | Audit completo simulando 3G/4G | Sì |
| Chrome DevTools (Network throttling) | Simula connessione lenta | Sì |
| BrowserStack | Test su dispositivi reali in cloud | A pagamento |
Una cosa che molti non sanno: PageSpeed Insights testa di default su un dispositivo Moto G4 con connessione 4G simulata a 1.6Mbps. Sembra cattivo, ma è una buona approssimazione di un utente medio. Se passi quel test, sei a posto per il 90% dei tuoi visitatori.
L’errore mobile più frequente? Pop-up invasivi. Google penalizza esplicitamente gli interstitial pop-up che coprono il contenuto principale al primo accesso da mobile. Niente pop-up email su mobile al primo scroll, mai. Aspettano almeno 30 secondi o l’exit intent.
C’è anche il discorso dei Web Push e delle notifiche di consenso cookie: vanno fatti in modo non-bloccante. Una banner cookie posizionata in basso e di dimensioni ragionevoli non danneggia CLS. Una che copre mezzo schermo all’apertura sì.
8. Strumenti gratis per misurare e monitorare la velocità del sito
Senza misurare non sai dove sei, e se non sai dove sei non puoi sapere dove andare. Te lo dico chiaro: non comprare strumenti a pagamento finché non hai sfruttato a fondo quelli gratuiti, che spesso bastano e avanzano.
Google PageSpeed Insights (pagespeed.web.dev) è il punto di partenza obbligato. Ti dà sia i dati di laboratorio (Lighthouse) sia i dati reali dal CrUX Report. Quelli reali sono i più importanti perché sono quelli che vede Google. Lo score 0-100 è una semplificazione, guarda i numeri sotto: LCP, INP, CLS in millisecondi.
Google Search Console → Esperienza → Segnali web essenziali è dove vedi il vero stato di salute del tuo sito agli occhi di Google. Mostra quante URL sono “Buone”, “Da migliorare” o “Scarse” sia su mobile che desktop, basato sui dati reali degli ultimi 28 giorni. Se qui hai pagine rosse, lì c’è il problema.
GTmetrix (gtmetrix.com) offre un’analisi diversa con waterfall dettagliata di tutte le richieste. Vedi esattamente quale file impiega quanto tempo. Ottimo per fare debug quando PageSpeed dice “il sito è lento” ma non sai dove. Il piano gratuito fa test da Vancouver di default — se hai pubblico EU, registrati per scegliere server europei.
WebPageTest (webpagetest.org) è il più tecnico ma anche il più potente. Filmstrip dei caricamenti, test multipli (first view vs repeat view), simulazioni di connessioni diverse. Se vuoi capire davvero come si comporta il tuo sito, è qui.
Strumenti aggiuntivi che uso quotidianamente:
- Chrome DevTools (F12 → Network e Performance): per debug live durante lo sviluppo
- Lighthouse CLI: per integrare i test nelle pipeline CI/CD
- CrUX Dashboard (crux.run): andamento storico dei Core Web Vitals reali
- TreoSH o SpeedVitals: monitoraggio continuo gratuito con alert
Per impostare un monitoraggio serio, ti consiglio:
- Connetti il sito a Google Search Console e controlla i Core Web Vitals una volta a settimana
- Configura un test PageSpeed mensile per le 5-10 pagine più importanti
- Setta alert su SpeedVitals o simili per essere avvisato se LCP supera 2,5s
- Tieni un log dei cambiamenti del sito (nuovo plugin, nuovo tema, nuova immagine hero) così sai cosa cercare se le metriche peggiorano improvvisamente
Una cosa che non si dice abbastanza: i tuoi competitor vanno monitorati anche loro. Se il tuo LCP è a 2,3s ti sembra ottimo, ma se i primi 5 risultati in SERP stanno tutti sotto 1,5s, sei comunque indietro. Confronta sempre.
Se ti senti perso e hai bisogno di un audit professionale, possiamo darti una mano: dai un’occhiata a /contatti/ o leggi i nostri approfondimenti sul blog. Spesso bastano 2-3 ore di analisi per identificare gli interventi che valgono il 90% del miglioramento.
❓ Domande Frequenti (FAQ)
Quanto deve essere veloce un sito per essere considerato buono da Google?
Per Google, un sito è “buono” quando supera tutti e tre i Core Web Vitals: LCP sotto 2,5 secondi, INP sotto 200 millisecondi, CLS sotto 0,1. Se sbagli anche solo uno di questi, sei nella categoria “Da migliorare”. Il tempo di caricamento totale ideale sta sotto i 3 secondi su mobile.
Plugin di cache: WP Rocket vale i 60€/anno o basta uno gratuito?
Dipende dal sito. Per un blog semplice, W3 Total Cache o LiteSpeed Cache (gratuiti) bastano. Per e-commerce, siti complessi, o se non vuoi smanettare con configurazioni manuali, WP Rocket li vale. Setting “out of the box” decenti, supporto reattivo, e ti fa risparmiare ore di lavoro. Chi ha tempo limitato e siti che fatturano? WP Rocket conviene.
Conviene cambiare hosting se il sito è lento o basta ottimizzare?
Prima ottimizza tutto quello che puoi (immagini, cache, plugin inutili), poi guarda il TTFB. Se dopo le ottimizzazioni il TTFB resta sopra i 600ms, il problema è il server. Cambia hosting. Se invece il TTFB è già sotto i 300ms, l’hosting va bene e il problema è altrove.
Cloudflare gratuito è sufficiente o serve quello a pagamento?
Per il 90% dei siti italiani, il piano gratuito di Cloudflare basta. Ti dà CDN globale, protezione DDoS, certificato SSL gratuito, e ottimizzazioni base. Il piano Pro (20$/mese) ha senso se vuoi Polish (compressione automatica immagini), Mirage (ottimizzazione mobile), e WAF avanzato. Cloudflare APO (5$/mese) è il vero gioiello per WordPress: cachea l’HTML su tutta la rete globale.
Le immagini AVIF sono già usabili o meglio aspettare?
Si possono usare adesso, sono supportate da Chrome, Firefox, Safari e Edge (oltre il 95% del traffico mondiale). Però usa sempre il fallback con <picture> per servire WebP a chi ha browser più vecchi. Risparmi ulteriore peso senza rischi. Se il tuo CMS o plugin di ottimizzazione le genera in automatico, attivale subito.
Quanto tempo ci vuole per vedere risultati SEO dopo aver migliorato la velocità?
Google riesegue la scansione e aggiorna i Core Web Vitals nel CrUX Report ogni 28 giorni circa. Quindi i primi cambiamenti nel ranking li vedi dopo 4-8 settimane. Per impatti pieni sul traffico organico, considera 3-6 mesi. Però l’effetto sul tasso di conversione e bounce rate è immediato — quello lo vedi nelle prime due settimane in Google Analytics.
