Una CDN tiene copie dei tuoi file in molti luoghi e serve ogni visitatore da quello più vicino. Così elimina la distanza, e la distanza è reale: una richiesta dal Cairo a un server in Germania costa circa 60 ms prima ancora che qualcosa venga calcolato, e questo su ogni singolo file.

Che cosa risolve davvero

  • La latenza sui file statici — immagini, CSS, JavaScript, font — per i visitatori lontani dal tuo server.
  • I picchi di banda, perché l'origine serve ogni file una volta sola invece che una volta per visitatore.
  • Uno scudo grezzo ma efficace contro le ondate di traffico.
  • La negoziazione TLS, che avviene vicino al visitatore anziché dall'altra parte di un oceano.

Che cosa non risolve

  • Una query lenta. L'HTML continua ad arrivare dal tuo server, e continua a essere lento.
  • Una pagina che non si può mettere in cache perché è personale di chi la guarda.
  • Una prima visita a un nodo freddo, che il viaggio intero lo paga comunque.

Che cosa nasconde

È questa la parte che costa tempo alle persone. Con una CDN davanti, le tue prove risultano veloci perché colpisci sempre una copia in cache, mentre un cliente autenticato su una pagina non memorizzabile riceve la risposta vera, quella lenta. Quando cerchi un collo di bottiglia, misura direttamente l'origine.

curl -sS -o /dev/null -w 'origin ttfb %{time_starttransfer}\
' \
     --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com/

Due cose da sistemare fin dal primo giorno

  • L'IP reale del visitatore. Finché non lo configuri, ogni log e ogni limite di frequenza vede la CDN — vedi Cloudflare e l'IP reale del visitatore.
  • Lo svuotamento della cache. Impara a ripulire un singolo file e a ripulire tutto, prima che serva a un rilascio.
Non mettere una CDN davanti a un pannello di amministrazione o a un'API che si autentica tramite header. Lì la cache è una fuga di dati, non un guadagno di velocità.