CDN per WordPress: come scegliere quello giusto

Per WordPress esistono due tipi di CDN: un CDN per gli asset, che un plugin collega riscrivendo gli URL di immagini, CSS e JavaScript, e un proxy per l'intero sito, che si mette davanti a tutto il dominio e può mettere in cache anche le pagine HTML. Quale dei due fa per te dipende da dove il tuo sito perde tempo, da chi sono i tuoi visitatori e da quanto sei disposto a toccare il DNS. Questa guida confronta i due tipi e ti dà una checklist per scegliere il fornitore.

Per le basi, leggi cos'è un CDN. Se non sai ancora perché il tuo sito è lento, trova prima la causa con la guida su perché WordPress è lento.

I due tipi di CDN per WordPress

CDN per gli asset (file statici tramite plugin)

Un CDN per gli asset serve solo file statici. Crei una pull zone presso il fornitore e ottieni un hostname come cdn.example.com. Un plugin di WordPress riscrive poi gli URL nel tuo HTML in modo che i file di wp-content e wp-includes vengano caricati da quell'hostname. Alla prima richiesta il CDN preleva ogni file dal tuo server e ne conserva una copia.

Dominio, DNS e HTML restano dove sono. Ogni visualizzazione di pagina passa ancora dal tuo hosting, che genera l'HTML come prima. Solo i file richiamati dalla pagina arrivano dal CDN.

Proxy per l'intero sito (tutto il dominio tramite nameserver o DNS)

Un proxy per l'intero sito prende in carico il traffico di tutto il dominio. A seconda del fornitore, gli deleghi i nameserver oppure punti il DNS del dominio verso di lui. Da quel momento ogni richiesta, HTML compreso, passa prima dai server edge del fornitore. L'edge serve ciò che può mettere in cache e inoltra il resto al tuo hosting.

Dato che tutto il traffico passa da lì, un proxy per l'intero sito può mettere in cache l'HTML delle pagine pubbliche, gestire l'HTTPS e filtrare gli attacchi prima che raggiungano il tuo server. È anche il cambiamento più grande, perché tutto il sito dipende dalla corretta configurazione del proxy.

Cosa mette in cache ciascun tipo

La differenza che conta di più è l'HTML. Su un tipico sito WordPress, la parte lenta di una visualizzazione è il server che costruisce la pagina con PHP e database. Un CDN per gli asset non tocca questo passaggio, quindi il tuo time to first byte resta invariato.

Un proxy per l'intero sito può servire quell'HTML dall'edge ai visitatori anonimi, senza coinvolgere PHP o il database. Per questo è il tipo che aiuta di più quando il TTFB è alto o il server fatica nei momenti di picco.

Gli asset vengono messi in cache da entrambi i tipi. Se le tue pagine vengono già generate in fretta (per esempio grazie a una buona cache di pagina sul server) e i visitatori aspettano soprattutto file pesanti, un CDN per gli asset può coprire buona parte di ciò che ti serve.

Pro e contro nella pratica

Quando basta un CDN per gli asset

• La risposta del server è già veloce e il collo di bottiglia sono immagini o script pesanti.
• Non puoi o non vuoi cambiare nameserver o DNS del dominio.
• Vuoi una modifica che puoi annullare disattivando un plugin.

Attenzione agli effetti collaterali tipici. I file scritti direttamente nel tema, nel CSS del page builder o negli stili inline spesso non vengono riscritti e continuano a caricarsi dal tuo server di origine. I web font caricati da un altro hostname richiedono un header Access-Control-Allow-Origin adeguato, altrimenti il browser si rifiuta di usarli. E WordPress aggiunge una query string ?ver= agli script e agli stili registrati: il CDN deve includere le query string nella chiave di cache, altrimenti dopo un aggiornamento i visitatori continuano a ricevere il file vecchio.

Quando conviene un proxy per l'intero sito

• Il TTFB delle pagine pubbliche è alto, oppure il server rallenta durante l'invio di una newsletter o una promozione.
• I tuoi visitatori sono distribuiti su più paesi o continenti.
• Vuoi che filtro DDoS e HTTPS vengano gestiti davanti al tuo hosting.

Anche i compromessi sono concreti. Devi impostare bene le regole di bypass, così nessuna pagina personale finisce mai in cache per tutti. Dopo aver pubblicato o modificato un articolo, l'HTML in cache va aggiornato. Il tuo server ora vede il proxy come client, quindi i plugin di sicurezza o di statistica devono leggere il vero IP del visitatore dall'header che il fornitore inoltra. E chi conosce l'indirizzo IP del tuo server può comunque aggirare l'edge, a meno che il tuo hosting non accetti traffico solo dal proxy.

La checklist per la scelta

Usa queste domande quando confronti i fornitori. Valgono per qualsiasi CDN, a prescindere dal nome.

Cache dell'HTML e regole di bypass

Può mettere in cache l'HTML, e come decide cosa saltare? Per WordPress, questi elementi devono sempre arrivare al tuo server senza passare dalla cache:

• /wp-admin/, wp-login.php e admin-ajax.php
• i visitatori con un cookie wordpress_logged_in_ (il riferimento sui cookie di WordPress, in inglese, elenca tutti i cookie impostati dal core)
• chi ha commentato e ha un cookie comment_author_, così vede il proprio commento in attesa di moderazione
• gli articoli protetti da password, che usano un cookie wp-postpass_
• le anteprime degli articoli e tutto ciò che è personalizzato, come carrello e pagine account in un negozio

WordPress qui ti dà una mano: per utenti loggati, articoli protetti da password e pagine 404 invia Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private. Un proxy che rispetta gli header Cache-Control salta quindi queste risposte. Il rischio sono i plugin che personalizzano le pagine senza inviare header di questo tipo, quindi testali.

Svuotare la cache dopo la pubblicazione

Quando aggiorni un articolo non cambia solo l'articolo, ma anche homepage, archivi di categorie e tag e il feed. Chiedi come si svuota la cache: per singolo URL, per tutto il dominio, dalla dashboard, tramite API? Lo svuotamento automatico alla pubblicazione dipende dal fornitore e dalla tua configurazione. Se manca, ti serve una durata di cache abbastanza breve oppure l'abitudine di svuotare la cache dopo le modifiche.

Ottimizzazione delle immagini

Il CDN converte le immagini in WebP o AVIF, e continua a servire l'originale ai browser che non supportano il nuovo formato? Questo può farti risparmiare un plugin per le immagini che fa il lavoro sul tuo server.

SSL tra visitatore, edge e server

Con un CDN per gli asset, l'hostname del CDN ha bisogno di un proprio certificato. Con un proxy per l'intero sito, è l'edge a detenere il certificato del tuo dominio. Assicurati che anche la connessione dall'edge al tuo server usi HTTPS. Se il proxy parla in HTTP semplice con un sito WordPress che forza l'HTTPS, puoi finire in un loop di redirect infinito, come spiega la documentazione di WordPress sull'HTTPS (in inglese).

Sicurezza e protezione DDoS

Un CDN per gli asset protegge solo i file che serve. Gli attacchi alle pagine, al login o a XML-RPC colpiscono comunque direttamente il tuo server. Un proxy per l'intero sito può filtrare i flood, bloccare paesi o intervalli di IP e limitare la frequenza delle richieste dei client abusivi già sull'edge. Controlla cosa è incluso nel piano che stai valutando e cosa costa in più.

Nodi edge vicini al tuo pubblico

Un CDN aiuta con la distanza solo se ha server edge vicini ai tuoi visitatori. Verifica da dove arrivano davvero i tuoi visitatori, poi quali regioni copre il fornitore con il tuo piano.

Impegno di configurazione e cosa succede a DNS ed email

Per un CDN per gli asset inserisci un hostname in un plugin e magari aggiungi un record CNAME. Per un proxy per l'intero sito, di solito il DNS passa al fornitore. Significa che ogni record deve essere presente lì prima del cambio, compresi i record MX per la posta e i record TXT per SPF, DKIM e verifica del dominio. La checklist per cambiare i nameserver senza downtime ti guida passo per passo.

Visibilità

Cerca un header di risposta che indichi hit, miss o bypass per ogni richiesta, e statistiche su cache hit ratio, traffico servito dall'edge rispetto all'origine e tassi di errore. Senza questi dati non puoi capire se il CDN sta facendo qualcosa di utile.

Misura prima e dopo

Non giudicare un CDN a sensazione. Prima del cambio, registra un punto di partenza:

1. Analizza homepage, un articolo e una pagina d'archivio su corewebvitals.page. Annota i dati degli utenti reali (se il sito ha abbastanza traffico) e i risultati di Lighthouse per mobile e desktop.
2. Misura dalla tua macchina la risposta del server per l'HTML:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. Dopo il cambio, richiedi la stessa pagina due volte e guarda gli header. La seconda richiesta dovrebbe mostrare un cache hit.

curl -sI https://example.com/ | grep -i -E "cache|age"

4. Accedi e verifica che wp-admin e il front end mostrino un bypass, non un hit.
5. Confronta di nuovo i dati degli utenti reali quando si sono aggiornati, dato che coprono gli ultimi 28 giorni.

La guida su come misurare la velocità di un sito spiega come mantenere corretto un confronto di questo tipo.

Come ti aiuta fast.site

fast.site è un proxy per l'intero sito. Si mette davanti al tuo hosting WordPress attuale, quindi tieni il tuo hosting e il tuo sito. Aggiungi il dominio nella dashboard, punti i nameserver a fast.site e fai la verifica. Da quel momento fast.site gestisce il tuo DNS, quindi tutti i record esistenti, compresi i record MX per la posta, devono essere presenti nella zona DNS di fast.site.

Fast Edge Cache™ serve pagine pubbliche e asset da server edge nelle regioni disponibili con il tuo piano. fast.site rispetta gli header Cache-Control inviati dal tuo sito WordPress, e l'header di risposta fs-cache indica HIT, MISS o BYPASS, così puoi controllare tu stesso wp-admin e le sessioni degli utenti loggati. Dopo una pubblicazione puoi svuotare la cache di singoli URL o di tutto il dominio dalla dashboard, con un registro degli svuotamenti, oppure tramite API dai tuoi script.

Le immagini JPEG e PNG vengono convertite al volo in WebP per i browser che lo supportano, con AVIF a seconda del piano. Ogni dominio riceve il rilevamento automatico degli attacchi DDoS di livello 7 e certificati SSL gratuiti rinnovati in automatico. Trovi i dettagli nella pagina WordPress e nella documentazione sulla cache.

Misura il sito prima e dopo con le stesse pagine e gli stessi strumenti. Puoi testarlo con una prova gratuita di 7 giorni.

Domande frequenti

Mi serve un plugin CDN per WordPress?

Solo per un CDN per gli asset, perché è il plugin a riscrivere gli URL dei file verso l'hostname del CDN. Un proxy per l'intero sito lavora a livello DNS e non ha bisogno di riscrivere gli URL, dato che il dominio resta lo stesso. Alcuni fornitori offrono comunque un plugin per attività come lo svuotamento della cache.

Un CDN sostituisce il mio plugin di cache?

Non necessariamente. Una cache di pagina sul server accelera ogni richiesta che non trova la pagina nel CDN e tutto il traffico degli utenti loggati, come descrive la documentazione di WordPress sulla cache (in inglese). Con un proxy per l'intero sito conta meno per i visitatori anonimi, ma tenerla raramente fa danni.

Un CDN può rompere wp-admin o il login?

Non dovrebbe, a patto che wp-admin, la pagina di login e i visitatori loggati saltino la cache. WordPress invia header no-cache per gli utenti loggati. Verificalo dopo la configurazione: accedi, modifica un articolo e controlla l'header di cache sulle pagine di amministrazione.

Perché dopo aver aggiornato un articolo non vedo le modifiche?

Il CDN sta ancora servendo la copia in cache. Svuota la cache dell'URL dell'articolo e delle pagine che lo elencano, come homepage e archivi di categoria. Per CSS e JavaScript, controlla che il CDN mantenga la query string ?ver= nella chiave di cache.