Edge Computing e CDN: Come Avvicinare il Tuo Sito Astro agli Utenti

Fino a qualche anno fa, il concetto di “hosting” per un sito web era molto semplice: noleggiavi uno spazio su un server situato in una specifica città (ad esempio, Milano o Francoforte) e ci caricavi i file del tuo sito.

Questo approccio ha un difetto fisico enorme: la distanza. Se il tuo server è a Milano e un utente si collega da New York, i dati devono fisicamente attraversare l’Oceano Atlantico. Questo viaggio richiede tempo, generando quella che chiamiamo latenza. Nel web moderno, dove l’attenzione si misura in millisecondi, un ritardo del genere costa conversioni e penalizzazioni SEO — lo stesso principio che ho descritto nel mio articolo su come la velocità del sito influenza vendite e ranking.

La soluzione a questo limite fisico si chiama Edge Computing. Vediamo cos’è, come abbassa drasticamente la metrica TTFB e come lo integro nativamente nei progetti costruiti con Astro.

Che cos’è una CDN e l’Edge Computing?

Iniziamo dalle basi. Una CDN (Content Delivery Network) è una rete globale di server. Quando usi una CDN, il tuo sito non risiede più su un singolo computer, ma viene copiato (in cache) su centinaia di server sparsi per il mondo (chiamati Punti di Presenza, o PoP). Se l’utente di New York visita il tuo sito, i file gli verranno inviati dal server di New York, non da quello di Milano.

L’Edge Computing è l’evoluzione di questo concetto. Non si limita a distribuire file statici (come immagini e HTML), ma permette di eseguire codice e logica di server direttamente su questi “nodi periferici” (l’Edge, appunto): autenticazione, personalizzazione dei contenuti, geolocalizzazione, A/B test, tutto calcolato a pochi millisecondi dall’utente invece che su un’unica origine centralizzata.

Il vero nemico: il TTFB (Time to First Byte)

Il TTFB è la metrica che misura il tempo che intercorre tra il momento in cui l’utente clicca su un link e il momento in cui il suo browser riceve il primo singolo byte di dati dal server.

Se il tuo sito ha un TTFB lento (sopra i 600 millisecondi), nessuna ottimizzazione delle immagini o minificazione del codice potrà salvarti: la pagina sembrerà bloccata prima ancora di iniziare a caricarsi. Il TTFB è anche la base temporale su cui si costruisce il Largest Contentful Paint (LCP), la metrica Core Web Vitals più pesante nel giudizio di Google — ne parlo nel dettaglio nella mia guida ai Core Web Vitals 2026. Distribuire il sito sull’Edge azzera le distanze fisiche, garantendo un TTFB inferiore ai 50 millisecondi a livello globale.

Astro e l’Edge: un matrimonio perfetto

Astro nasce con una propensione naturale per la velocità. Quando generi un sito statico (SSG), i file HTML puri sono perfetti per essere distribuiti su una CDN tradizionale, come ho raccontato nel mio articolo sulla Islands Architecture di Astro.

Ma il vero salto di qualità avviene quando hai bisogno di funzionalità dinamiche (come un e-commerce con carrello aggiornato in tempo reale, un sistema di login o una ricerca interna) utilizzando il Server-Side Rendering (SSR).

Invece di far girare un server Node.js tradizionale in un unico data center, Astro supporta nativamente gli Adapter per eseguire il rendering direttamente sull’Edge. Questo significa che la pagina dinamica viene creata sul nodo più vicino all’utente, non su un server a migliaia di chilometri di distanza.

I tre provider migliori (e che utilizzo spesso) per ospitare un progetto Astro sull’Edge sono:

1. Cloudflare Pages & Workers: una delle reti Edge più estese al mondo, con runtime basato su V8 Isolates (avvio quasi istantaneo, nessun cold start “pesante”). Ottima per scalabilità globale e protezione anti-DDoS integrata.
2. Vercel: nato per Next.js, ma offre un supporto eccellente e zero-config per Astro grazie alla sua Edge Network e all’integrazione diretta con il flusso di deploy da Git.
3. Netlify: un pioniere dell’architettura Jamstack, con funzioni Edge basate sul runtime Deno, facilissime da integrare e ben documentate per progetti Astro.

Un esempio pratico: l’adapter Cloudflare

Per trasformare un sito Astro locale in un’applicazione distribuita sulla rete globale di Cloudflare, basta un semplice comando nel terminale per installare l’adapter:

npx astro add cloudflare

E Astro configurerà automaticamente il file astro.config.mjs:

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server',
  adapter: cloudflare({
    mode: "directory"
  }),
});

Con sole tre righe di configurazione, il tuo codice è pronto per essere eseguito su centinaia di data center in tutto il mondo contemporaneamente.

Attenzione ai limiti del runtime Edge

C’è un dettaglio che manda in crisi molti sviluppatori alla prima migrazione: il runtime Edge non è Node.js. Gira su ambienti alleggeriti (V8 Isolates o Deno Deploy) che non hanno accesso ad alcune API tradizionali, come il filesystem (fs) o certi moduli nativi di Node. Se il tuo progetto usa librerie che dipendono da fs per leggere file a runtime, o pacchetti npm pensati esclusivamente per Node, quel codice va spostato in una build step, oppure il progetto va distribuito con un adapter Node classico invece che sull’Edge.

Un altro punto da verificare è la gestione degli header di sicurezza: se già usi un Middleware Astro per iniettare una Content Security Policy, come descritto nella mia guida alla CSP su Astro, quel Middleware gira perfettamente anche sull’Edge — è proprio lì che rende meglio, perché applica le regole di sicurezza il più vicino possibile all’utente, prima ancora che la richiesta raggiunga la tua origine.

Edge Middleware: personalizzazione senza sacrificare il TTFB

Uno dei casi d’uso più interessanti dell’Edge non è solo “servire più velocemente” un contenuto statico, ma decidere cosa servire in base al contesto della richiesta, senza pagare il costo di un round-trip verso un’origine lontana. Un Middleware Astro che gira sull’Edge può, ad esempio, leggere l’header Accept-Language o la geolocalizzazione IP per reindirizzare automaticamente un utente verso la lingua corretta:

import { defineMiddleware } from "astro:middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const country = context.request.headers.get("cf-ipcountry"); // header geo di Cloudflare
  const { pathname } = context.url;

  if (country === "IT" && !pathname.startsWith("/it") && !pathname.startsWith("/en")) {
    return context.redirect(`/it${pathname}`, 302);
  }

  return next();
});

Questo tipo di logica, se eseguita su un server centralizzato lontano dall’utente, aggiungerebbe centinaia di millisecondi prima ancora di iniziare a caricare la pagina. Eseguita sull’Edge, il costo è quasi impercettibile — la stessa logica di “fare meno lavoro, più vicino all’utente” che guida anche le scelte di lazy loading avanzato lato client.

Conclusione

Affidarsi a un hosting condiviso tradizionale da 50 euro l’anno per un business digitale ambizioso è come comprare una Ferrari e metterci le ruote di una bicicletta.

Sfruttare l’Edge Computing significa offrire un’esperienza istantanea a ogni cliente che ha davvero bisogno di funzionalità dinamiche, indipendentemente dalla sua posizione geografica. Non è però una scelta obbligata per ogni progetto: se un sito, come questo stesso portfolio, non richiede SSR, una build statica distribuita su CDN resta la soluzione più semplice, veloce ed economica. Il criterio giusto non è “Edge sempre e comunque”, ma scegliere l’architettura più adatta alle reali esigenze del progetto. Se stai valutando una migrazione verso un’architettura più performante, il primo passo è spesso proprio ripensare a come è strutturato il rendering del sito — un percorso che ho affrontato in prima persona anche nella migrazione di un progetto da React ad Astro.