[siquick]

I had been using Vercel for a Next.js SSR deployment up until this week when I moved it to a basic AWS Lightsail box with no real NGINX optimisations.

I have Lightsail server in Frankfurt and I am in Sydney and the Lightsail box gets a higher Pagespeed score than the Vercel deployment and from my own anecdotal usage, the page load is noticeably faster. I had Vercel region set to Paris (no Frankfurt region yet).

I loved the simplicity of Vercel, especially the per-branch-deployments (which Im still using on the free tier) but it was surprising that for all the serverless boasts, its not actually any faster than a basic server.

[carmen_sandiego]

It's a little more complex than that. Naturally an 'always running' server is faster when you're not getting a cache hit or you're running into a Lambda cold start. But for stuff served from CDN cache it won't make any difference. Vercel/nextjs are geared towards encouraging you to make everything static so that it does get served that way.

If you need to generate every part of your page to be user-specific then I would say that's a different use case and nextjs isn't necessarily the right tool.

That said, you can actually do some pretty dynamic pages with it. You should try out what they call 'Incremental Static Generation'. It's basically the SWR pattern, but for server-side rendering.

[chmod775]

> Vercel/nextjs are geared towards encouraging you to make everything static so that it does get served that way.

That would mean they have no reason to exist. If they're slower than a regular server for dynamic content and only as fast as a regular CDN for static pages, they're beaten by the old server + CDN combination.

The niche for rendering on the edge is really incredibly narrow. Take one step further and you have client-side rendering, take one step back and you're already on a server. I'm not surprised people have trouble finding use-cases, and when they do it often turns out they would've been better served by one of the two other solutions.

[carmen_sandiego]

I'll have to disagree.

I use Next because it offers SSR plus the hydration step for a fully-fledged React app on client, and the ease with which you can pass stuff between the two. SSR for paint speed and SEO/bots/meta/whatever, and the rich client side app functionality that people expect these days. A traditional server-side-render-only approach doesn't make that as easy, IMO.

I use Vercel for the DX, mostly. I can copy an old project repo and have a fully functioning new project site up in literally 20 mins. Same reason people use Netlify.

Also, they're not necessarily slower for dynamic content. Only noticeably if you hit a cold start really. But that's just the normal serverless/Lambda caveat: in exchange for interventionless scaling, one request in n is a little slower during scale-up events. You can always put your next app on EC2/EB/etc if it worries you. I'm more pro-nextjs than pro-Vercel.

[siquick]

Yes I'm sure it's down to the cold start issue of Lambda. Are there any tips on how to keep it warm?

I didn't go down the static route as I have tens of thousands of product pages. Will check out the Incremental Static Generation - thanks.

[carmen_sandiego]

So yeah in that case I would do Incremental Static Regeneration but don’t pass all your product paths at build time. Instead you can use the fallback mechanism to render individual product pages on request, but then serve the result statically thereafter. That way you don’t build tons of pages at build time that people may not view anyway, but the pages that do get views will stay fresh and fast.

If you were using your own Lambda you could set a minimum reserved concurrency to avoid cold starts, but I don’t think Vercel gives you that level of control. The main thing to do is try to serve as much statically as possible so that it reads straight from the CDN cache or static file store and that way it never hits your Lambda on requests.

With ISR the Lambda updates the rendered file in the background, rather than in response to a request (generally), and the user is just served the last generated render. So in that scenario the Lambda latency is taken out of the equation.

If you know which products are most important you could also render a subset of them at build time and let the fallback handle the long tail ones.

[siquick]

Great, thank you!