CDN per WordPress nel 2026: Cloudflare, QUIC.cloud e cosa migliora davvero

Questo articolo è stato pubblicato per la prima volta nel 2012 e completamente riscritto a ottobre 2026: i commenti più vecchi si riferiscono alla versione originale.

Nel 2012 avevo scoperto Cloudflare grazie al classico consiglio di un amico e, per usarlo su questo blog, avevo fatto una cosa che oggi sembra un rito d’altri tempi: comprato un dominio apposta per i file statici, spostato i suoi DNS su Cloudflare, configurato Apache e scritto perfino un piccolo plugin, pubblicato sul repository, che riscriveva gli indirizzi di immagini, CSS e JavaScript per farli passare dalla CDN. Il risparmio di banda c’era, anche se su un blog personale era più una soddisfazione da nerd che una necessità.

Nel 2026 una CDN per WordPress non si limita più a servire le immagini da un sottodominio: si mette davanti all’intero sito, termina HTTPS, filtra il traffico malevolo, ottimizza le immagini e, con le configurazioni giuste, può servire anche l’HTML delle pagine. In questo articolo vediamo come funziona oggi, cosa offrono Cloudflare e QUIC.cloud, cosa migliora davvero sulle metriche di velocità e quale errore di configurazione può farti sparire, senza accorgertene, dai motori di ricerca e dalle risposte dei motori AI.

Cos’è una CDN e come funziona oggi

Una CDN, Content Delivery Network, è una rete di server distribuiti nel mondo che conservano copie dei contenuti di un sito e li consegnano dal nodo più vicino al visitatore, riducendo la distanza fisica, il carico sul server di origine e il tempo di risposta. Oggi quasi tutte le CDN lavorano come reverse proxy: il dominio punta alla CDN, che riceve ogni richiesta, risponde dalla sua cache quando può e contatta il tuo server solo quando non ha una copia valida.

La conseguenza pratica, rispetto al 2012, è che non serve più riscrivere gli URL dei file statici con un plugin né comprare domini dedicati: basta spostare i DNS o, nel caso di QUIC.cloud, collegare il servizio dal plugin di cache, e la CDN intercetta tutto il traffico del dominio. Il mio vecchio plugin di sostituzione degli URL, insomma, è andato in pensione con tutti gli onori.

Il rovescio della medaglia è che la CDN diventa il primo punto di contatto tra il tuo sito e il resto di internet, compresi i crawler dei motori di ricerca: tutto quello che decide, dalla cache al blocco dei bot, ha effetti diretti su velocità e visibilità.

Cloudflare per WordPress: cosa offre davvero

Cloudflare resta la scelta più diffusa per WordPress perché il piano gratuito copre già le esigenze di molti siti: secondo la documentazione ufficiale include la CDN, la protezione DDoS, i certificati SSL, il Cloudflare Free Managed Ruleset del firewall applicativo, una regola di rate limiting con conteggio per IP e il Bot Fight Mode. I piani a pagamento aggiungono regole WAF più ricche, più regole di rate limiting e il Super Bot Fight Mode configurabile; per prezzi e condizioni aggiornate il riferimento è sempre la pagina dei piani sul sito di Cloudflare, che cambia più spesso di quanto si pensi.

L’HTML non è in cache per impostazione predefinita

Il dettaglio che sorprende quasi tutti è che Cloudflare, per impostazione predefinita, non mette in cache l’HTML ma solo i file statici, riconosciuti dall’estensione: immagini, CSS, JavaScript, font e documenti. Le pagine di WordPress continuano quindi a essere generate dal tuo server a ogni richiesta, a meno di creare delle Cache Rules dedicate, facendo molta attenzione a escludere amministrazione, utenti autenticati e carrelli, oppure di usare APO (Automatic Platform Optimization), la soluzione di Cloudflare pensata per servire l’intero sito WordPress dalla sua rete, che richiede il plugin ufficiale Cloudflare per WordPress.

Per la parte di sicurezza, la regola di rate limiting del piano gratuito è perfetta per proteggere wp-login.php e xmlrpc.php, come racconto nell’articolo su come proteggere il login di WordPress dal brute force.

QUIC.cloud e LiteSpeed Cache

QUIC.cloud è la CDN sviluppata dal team di LiteSpeed e integrata nel plugin LiteSpeed Cache, ed è l’alternativa più naturale per chi usa già quel plugin, come questo sito. Il suo punto di forza è che parla la stessa lingua della page cache del server: può mettere in cache anche le pagine dinamiche di WordPress, con supporto per la cache privata, per gli ESI e per WooCommerce, e si appoggia allo stesso sistema di etichette che svuota solo le pagine collegate quando pubblichi o modifichi un contenuto.

Dal sito ufficiale e dalla scheda del plugin risultano anche alcune funzioni accessorie che vale la pena conoscere:

• Ottimizzazione delle immagini con generazione dei formati WebP e AVIF.
• Critical CSS e Unique CSS, per anticipare lo stile della parte visibile e togliere quello inutilizzato.
• Sicurezza con regole WAF specifiche per WordPress, protezione DDoS di livello 7 e mitigazione dei brute force.
• HTTP/3 tra visitatore e CDN.

La scheda del plugin indica la CDN di QUIC.cloud tra le funzioni gratuite e precisa che il servizio permette anche ai siti su Apache o nginx di usare la cache di LiteSpeed; limiti e quote dei piani cambiano nel tempo, quindi prima di decidere controlla le condizioni sul sito di QUIC.cloud. Se il tuo hosting è già LiteSpeed, come capita con molti hosting condivisi, è la scelta con meno parti in movimento; se invece hai bisogno di regole di sicurezza molto granulari, Cloudflare offre più leve.

Cosa migliora davvero: TTFB e Core Web Vitals

Una CDN migliora soprattutto il TTFB, il tempo che passa tra la richiesta e il primo byte della risposta, e di riflesso il Largest Contentful Paint, perché l’elemento più grande della pagina arriva prima; i vantaggi crescono quanto più i visitatori sono lontani dal server. Il TTFB, va ricordato, non è uno dei Core Web Vitals, che oggi sono LCP, INP e CLS, ma è il punto di partenza da cui dipende tutto il resto.

Se la CDN serve solo i file statici e l’HTML resta generato dal server, il TTFB della pagina non cambia: per vederlo scendere serve una cache dell’HTML, sul server con la page cache o al bordo con Cache Rules, APO o QUIC.cloud. Per lo stesso motivo una CDN non può nulla contro un INP alto, che dipende dal JavaScript che blocca il browser, né contro un CLS dovuto a immagini senza dimensioni o banner che spingono il contenuto; i livelli di cache e il loro ordine li ho raccontati nell’articolo sulla cache in WordPress.

Una CDN accorcia la strada, ma se la pagina è lenta da costruire arriva prima soltanto l’attesa.

Il modo onesto di misurare l’effetto è confrontare i dati reali del rapporto Core Web Vitals di Search Console prima e dopo l’attivazione, tenendo conto che servono settimane per accumulare dati sufficienti, e non fidarsi di un singolo test di laboratorio fatto dal proprio ufficio, magari a due passi dal server.

Attenzione a non bloccare Googlebot e i crawler AI

Il rischio più sottovalutato di una CDN è bloccare i crawler buoni insieme a quelli cattivi: un challenge JavaScript o un captcha ferma un bot di scraping, ma ferma allo stesso modo Googlebot, Bingbot o il crawler di ricerca di un motore AI, che non risolvono sfide interattive e semplicemente smettono di vedere le pagine. Il risultato è un sito velocissimo per gli utenti e invisibile per chi dovrebbe portarli.

Bot Fight Mode, bot verificati e AI bot

Con Cloudflare i punti da controllare sono tre. Il Bot Fight Mode del piano gratuito, secondo la documentazione, non si può personalizzare né aggirare con regole WAF o Page Rules, quindi se crea problemi l’unica soluzione è spegnerlo; il Super Bot Fight Mode dei piani a pagamento permette invece di decidere separatamente cosa fare con il traffico automatizzato e con i bot verificati, tra cui Cloudflare distingue i crawler dei motori di ricerca, i crawler di ricerca AI come OAI-SearchBot e quelli di addestramento AI.

Il terzo punto sono le policy per gli AI bot, che classificano i bot in ricerca, addestramento e agenti: dal 15 settembre 2026, per i nuovi domini, Cloudflare blocca per impostazione predefinita i bot di addestramento e gli agenti sulle pagine che mostrano pubblicità e lascia passare quelli di ricerca. È una scelta ragionevole, ma va fatta consapevolmente e allineata al tuo robots.txt, come spiego nell’articolo dedicato a hotlinking, bot aggressivi e crawler AI.

Dopo ogni modifica ricontrolla le statistiche di scansione di Search Console, il rapporto di Bing Webmaster Tools e le analisi di sicurezza della CDN: se le richieste di Googlebot crollano o compaiono errori, quasi sempre la causa è una regola troppo zelante.

Tirando le somme

Nel 2026 una CDN per WordPress è una scelta quasi scontata per sicurezza e banda, ma i benefici sulla velocità arrivano davvero solo se anche l’HTML viene messo in cache, al bordo o sul server. Cloudflare è la scelta più flessibile, con un piano gratuito già ricco e regole avanzate nei piani superiori; QUIC.cloud è la scelta più semplice per chi usa LiteSpeed Cache, perché si integra con la page cache e con il suo sistema di invalidazione. In entrambi i casi la configurazione dei bot va trattata con la stessa cura della cache, perché un challenge sbagliato può costare più visibilità di quanta velocità faccia guadagnare.

Per approfondire parti dalla documentazione di Cloudflare sul comportamento predefinito della cache e sul Bot Fight Mode, e dalla pagina dei servizi di QUIC.cloud. Raccontami nei commenti quale CDN usi e quali sorprese ti ha riservato, e se conosci qualcuno che ha attivato tutte le protezioni al massimo e poi si chiede perché Google non passa più, giragli questo articolo.

E se preferisci non fare tutto da solo, puoi dare un’occhiata ai miei servizi di consulenza WordPress, prenotare una call conoscitiva gratuita oppure scrivermi passando dalla pagina dei contatti: ne parliamo con calma, partendo dal tuo sito e non da una checklist generica.