Considerations for Incremental Static Regeneration in Next.js | Hacker News Reader

Considerations for Incremental Static Regeneration in Next.js

csrhymes.com

30 pointsrhymesey17 comments

I've definitely felt like I've had to come up with clever ways of making sure my pages are the latest, especially after a user edits their page and expects to see it instantly updated. I've also had to remove thousands of pages from static generation, only to be generated on first load or else Vercel times out on the build and you'll be banging your head on the wall trying to figure out what is going wrong as their logs don't tell you. The number of pages you can get away with is way lower than you think it should be. I haven't tried the new on-demand revalidation yet.

Hey, Lee from Vercel. How many pages were you trying to build when you hit the 45 minute limit? We’ve recently revamped our build and deploy infrastructure, which should help builds complete faster with many static pages.

https://vercel.com/changelog/faster-builds-for-everyone

I have a website with over 13,000 pages generated at build time with no issues. It takes about 5-10 minutes. If you site is timing out at the 45 minute mark, I’d wager you’re doing something wrong.

I had about 8500 pages. I spent weeks on it, optimizing it, upgrading to v12 (which actually was slower), trying everything from every forum and support source I could find and going back and forth with what was the most embarrassing and frustrating support I've ever encountered. It made me seriously look for Vercel alternatives. I found out I needed to pay $1000/month for competent support (annual up front of course). I was running a business and I couldn't update my site for weeks because of these issues, so who knows how many customers I lost because I couldn't fix bugs or copy that really needed fixing (I did get a lot of emails about the issues to which I had no satisfying response). I was on the Pro plan and I had no option go to from $20 a month to something for actual non-enterprise business users. I was ready to drop $300-$500/month if it would help me actually get support and run my business, but they said "Nope, maybe in a year or two".

So looking back at my emails (this was in January) according to the Vercel build logs I could see on their page my actual build only took 11-13 minutes, but after that it wouldn't show any new logs for 16 minutes, at which point it would finally say "uploading build outputs", 5.5 minutes later it would say something about deploying and then I would hit the 45 minute timeout. So it was super frustrating because I could see my stuff building in an ok time, but it seemed like everything Vercel was doing was going slow or stalled and I had no control over what their system was doing and why it was going so slow. Support would give me no answers or even look at it.

Eventually I realized I could just change my static paths to not include any user content (which admittedly will hardly ever be checked again after creation), and I was able to build way faster and make it through the entire build and deploy in 10 minutes. Of course I'm only using <300 static pages now and those thousands of pages are the kind that once statically built, never need to be changed again, which was also a missing solution I fought with. Why am I rebuilding thousands of pages that don't need to be rebuilt every time I make a little tweak that doesn't affect them?

I haven't gone back since to try and figure it out again.

Interesting. I apologize for my accusation.

I’m assuming you’re using “catch all routes”? In which case, have you tried incremental static regeneration? As in, don’t actually generate the pages at build time, but only when they’re requested?

Just curious if there's any clear benefit to using ISR over setting up a CDN in front of your website, other than the page being regenerated in the background? Our website has Akamai in front, and we are pretty much all SSR/getServerSideProps. We've thought about diving into ISR a few times but so far it seems the marginal benefit might not be very high in our case. We currently have a practice of sending API calls to Akamai to invalidate cache entries when pages are updated.

If SSR + caching is already working well for you, you might not need ISR. And it likely also depends on the type of application you’re building. For example, if you need user auth on every request, generating static assets probably won’t work since they’re not personalized.

One difference with ISR is that it’s durable, where your cache is not. You can persist the statically built pages to disk, like S3, and be able to roll back to old versions.

I sometimes feel like I’m taking crazy pills when it comes to web development. This literally the functionality WordPress + a caching plugin has been providing for 15+ years.

Yes you’re right, but Next.js also provides many other modes of rendering content with a fairly consistent API.

Many people are still using Next.js with WordPress, but they’re using it “headless”. The difference here is that static assets can be served globally (versus a monolithic WP single region server) and cache purges can happen globally in about 300ms.

Very good points. I think most devs don't think in multiple servers. There should be built in considerations for most of these i hope Next themselves are considering this.

Until I read this post I didn't even know my Vercel apps ran in multiple servers. I have to go check some things out I guess.

By default, static pages and assets on Vercel are deployed to every region in our Edge Network. Happy to answer any other questions about Vercel!

How does this work with a cache when deployed to Vercel? Does it imply multiple servers?

Vercel has built-in regional caching. When you use on-demand ISR to programatically invalidate the cache, purges propagate globally in about 300ms.

https://on-demand-isr.vercel.app/

That's very cool! Can I have SSR pages be served from multiple regions as well? This would be very beneficial to my e-commerce as I have to SSR some hyper-customized product pages. I'm assuming that Vercel serves requests from the server that is closest to the user, is that correct? If one specific server starts receiving a lot of traffic, does Vercel forward requests that would otherwise go to that busy server to the next closest server?

You can customize which region you want your functions to run in that handle server-rendering. Currently running multi-region functions (lambdas) requires an enterprise plan, but using Edge Functions, they can be multi-region or global if you’d prefer. It depends on where your data is and if it’s replicated.

You are correct that Vercel serves requests from the region closest to the visitor. Our servers automatically scale (serverless) so it doesn’t need to balance across regions. However, in an instance of downtime, Vercel would route traffic to the next nearest region.

Reply on news.ycombinator.com