Vercel: Instant Deployments and Edge Network for Our Frontends
The i3k.eu website, LetsAI landing pages, and all our React frontends run on Vercel. Preview for every branch, automatic HTTPS, global CDN, and deploy in under 40 seconds. Here's why we chose it and how we configure it.
Why Vercel for i3k Frontends
When we launched i3k.eu as a React SPA with Vite, we needed a platform that would remove all frontend infrastructure complexity. We didn't want to manage an Nginx server to serve static files, configure CDN, or worry about SSL certificates. Vercel does all of this automatically. Our workflow is simple: push to GitHub, Vercel detects the commit, runs the Vite build, and distributes assets on its global edge network. The average time from push to live site is 38 seconds. For a team that also works on complex backends and on-premise deployments, this frontend speed is liberating. We chose Vercel after trying Netlify and GitHub Pages. Netlify was fine but builds were slower (about 90 seconds) and SPA redirect configuration required a _redirects file that was easily lost. GitHub Pages didn't support client-side routing without hacks. Vercel worked on the first try with a single vercel.json.
Preview Deployments and vercel.json Configuration
The killer feature of Vercel for our workflow is preview deployments. Every pull request on GitHub automatically generates a unique URL with the site version updated to that branch. When a team designer wants to see changes to the LetsAI page, they open the preview link and evaluate it on their phone. No staging server to maintain, no "let me see your screen." Our vercel.json configuration has been refined over time. For a React SPA the classic problem is routing: if a user navigates to /blog/article and reloads the page, the server must return index.html instead of a 404. We use the routes section with a { "handle": "filesystem" } pattern followed by a catch-all to /index.html. We also added security headers (X-Content-Type-Options, X-Frame-Options) as routes with "continue": true. For performance, we leverage aggressive Cache-Control headers on static assets with hashed names. Files in /assets/ have max-age=31536000 because the name changes with every build. index.html instead has no-cache to ensure users always see the latest version. This pattern gives us a consistent Lighthouse performance score above 95.
Edge Network, Performance, and Limits for Our Use Case
Vercel's edge network distributes our assets across dozens of data centers worldwide. For i3k.eu the benefit is measurable: Time to First Byte (TTFB) for a user in Milan is 15ms, New York 45ms, Tokyo 80ms. Previously, with a single server in Europe, Tokyo saw 280ms TTFB. For a site that wants to attract international clients, this difference matters. We considered using Incremental Static Regeneration (ISR) for blog pages, but ultimately opted for a fully static approach. Our articles are defined in TypeScript and compiled into the bundle — no API calls needed. The full site build takes 12 seconds and produces total assets under 2 MB. ISR would have added complexity without real benefits for our use case. The main limitation of Vercel for us is that it only serves frontend. RAG Enterprise and CRM81 backends run on dedicated on-premise servers or VPS for the cloud version. Vercel acts as the interface: the React frontend on Vercel communicates with backend APIs via explicitly configured CORS. This clean separation between frontend and backend is actually an architectural advantage: we can update the frontend in 38 seconds without touching the backend.
Interested?
Contact us to receive a personalized quote.
Securvita S.r.l. — i3k.eu