Vercel: Deploy Istantanei e Edge Network per Frontend
Il sito i3k.eu, le landing page di LetsAI e tutti i nostri frontend React girano su Vercel. Preview per ogni branch, HTTPS automatico, CDN globale e deploy in meno di 40 secondi. Ecco perché lo abbiamo scelto e come lo configuriamo.
Perché Vercel per i Frontend i3k
Quando abbiamo lanciato i3k.eu come SPA React con Vite, avevamo bisogno di una piattaforma che ci togliesse di mezzo tutta la complessità infrastrutturale del frontend. Non volevamo gestire un server Nginx per servire file statici, configurare CDN, o preoccuparci di certificati SSL. Vercel fa tutto questo automaticamente. Il nostro workflow è semplice: push su GitHub, Vercel rileva il commit, esegue il build Vite, e distribuisce gli asset sulla sua edge network globale. Il tempo medio dal push al sito live è 38 secondi. Per un team che lavora anche su backend complessi e deploy on-premise, questa velocità sul frontend è liberatoria. Abbiamo scelto Vercel dopo aver provato Netlify e GitHub Pages. Netlify andava bene ma i build erano più lenti (circa 90 secondi) e la configurazione dei redirect per SPA richiedeva un file _redirects che si perdeva facilmente. GitHub Pages non supportava routing lato client senza hack. Vercel ha funzionato al primo tentativo con un singolo vercel.json.
Preview Deployments e Configurazione vercel.json
La feature killer di Vercel per il nostro workflow è il preview deployment. Ogni pull request su GitHub genera automaticamente un URL univoco con la versione del sito aggiornata a quel branch. Quando un designer del team vuole vedere le modifiche alla pagina di LetsAI, apre il link di preview e lo valuta sul suo telefono. Niente staging server da mantenere, niente "fammi vedere sul tuo schermo". La configurazione del nostro vercel.json è stata affinata nel tempo. Per una SPA React il problema classico è il routing: se un utente naviga su /blog/articolo e ricarica la pagina, il server deve restituire index.html invece di un 404. Usiamo la sezione routes con un pattern { "handle": "filesystem" } seguito da un catch-all a /index.html. Abbiamo anche aggiunto header di sicurezza (X-Content-Type-Options, X-Frame-Options) come route con "continue": true. Per le performance, sfruttiamo gli header Cache-Control aggressivi sugli asset statici con hash nel nome. I file in /assets/ hanno max-age=31536000 perché il nome cambia ad ogni build. index.html invece ha no-cache per garantire che gli utenti vedano sempre la versione più recente. Questo pattern ci dà un Lighthouse performance score costante sopra 95.
Edge Network, Performance e Limiti per il Nostro Caso d'Uso
L'edge network di Vercel distribuisce i nostri asset su decine di data center nel mondo. Per i3k.eu il beneficio è misurabile: il Time to First Byte (TTFB) per un utente a Milano è di 15ms, per uno a New York 45ms, per uno a Tokyo 80ms. Prima, con un server singolo in Europa, Tokyo vedeva 280ms di TTFB. Per un sito che vuole attrarre clienti internazionali, questa differenza conta. Abbiamo considerato l'uso di Incremental Static Regeneration (ISR) per le pagine del blog, ma alla fine abbiamo optato per un approccio completamente statico. I nostri articoli sono definiti in TypeScript e compilati nel bundle — non servono chiamate API. Il build completo del sito impiega 12 secondi e produce asset totali sotto i 2 MB. ISR avrebbe aggiunto complessità senza benefici reali per il nostro caso d'uso. Il limite principale di Vercel per noi è che serve solo frontend. I backend di RAG Enterprise e CRM81 girano su server dedicati on-premise o su VPS per la versione cloud. Vercel funge da interfaccia: il frontend React su Vercel comunica con le API backend tramite CORS configurato esplicitamente. Questa separazione netta tra frontend e backend è in realtà un vantaggio architetturale: possiamo aggiornare il frontend in 38 secondi senza toccare il backend.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu