Prefetch + Revalidate or Fallback: true + "non-serverless" DB = overloaded server

[tomgreeEn]

I'm using a headless wordpress set up with NextJS and having issues with prefetching links on pages with large numbers of links (e.g. index pages).

If I use either revalidate: X or fallback:true for target pages, scrolling down an index of say 20 pages after the revalidation period has passed (or if they are fallback pages) causes 20 prefetch requests which in turn causes 20 near-simultaneous requests to my wordpress server. As the requests are not inexpensive, this usually overloads the server, causing GetStaticProps to time out for most prefetches and preventing me from accessing the single fallback page I actually click on.

Am I right in thinking that with this kind of server-based back end, where I have a large number of internal links on a page I, can use prefetch OR revalidate/fallback, but should not in combination? Or is there another approach I can take to get the best of both worlds?

[barberdt]

@tomgreeEn So happy to have found this post. I just posted in the Discord server about the same issue.

Did you ever get an answer on this and if not, what has been your workaround?

[tomgreeEn]

Hi there.

I didn't find a silver bullet but have taken steps that make this less of a showstopper for me. In response to your Discord post, as far as I could understand this the revalidation on prefetch is expected behaviour.

1. Move hosts. Having tried a few managed hosts and researched a lot more, Kinsta, thanks to its awesome autoscaling, blew the rest out of the water when it came to handling a large number of simultaneous expensive requests. Even on the basic $30 plan it doesn't really flinch. This solved my problems in two ways:
   a) I can now pre-build 2000+ pages during the 45 minute window you get with Vercel - so I don't have to have a large number of fallback pages which would be triggered on prefetch.
   b) If the server does get hit with a lot of pages attempting to revalidate or fallback at the same time, it's much more able to service these requests

2. Randomise revalidate time. Depending on the level of traffic to your pages and how long you need your revalidate window to be, you may be able to reduce the simultaneuous load on the server by setting a revalidate time that falls within say 25% +- the revalidate window. This means that rather than all pages expiring at exactly the same time, and then all being requested the next time a page that links to them is loaded, they will go one by one, spreading the load on the server more evenly.
   This is more of a theoretical solution than one I've properly tested as my app isn't yet live, and may not work in your real world, but may reduce the pressure on the server.

3. Use prefetch=false. As nextJs still prefetches on mouse hover even with this setting, you're still getting a fair bit of the benefit of prefetching, just not every single page on page load. If you have a lot of internal links, this is arguably a better option anyway. As with the above, it doesn't make the problem go away (if you scroll down the middle of the index you can 'hover' over 30 links in a couple of secs) but may help reduce it incrementally.

Hope that's of some use...be interested if you find a more definitive solution

Tom

[barberdt]

Hey Tom. Thanks for the insights! I think of all the options, a combination of adjusting revalidate timing and using prefetch=false for large lists of links is likely going to be my first approach.

It certainly is a bummer that there isn't a differentiation between prefetch and actual navigation with regards to revalidating the static builds. Looking through source code at the moment to see if that's even possible. Will update here if I find anything valuable.

[nag]

I had the same problem and ended up using prefetch={false} on all next/links. Most of my client's traffic comes from mobile, so hover becomes less of a problem.

Good advice about randomizing the revalidate time. Besides, in addition to the revalidate time, we are returning some data inside the props object. This data often has some timestamp that can be used to decide when to revalidate.

For example, we can make a scale from zero to one month and, depending on how long ago something was published, set a different revalidation based on that scale. Then, after each rebuild, the revalidation time will increase (which is okay, because that something is becoming less relevant) until it reaches the maximum value (say, 1 hour). The final value can be randomized a little 🤔

[ijjk]

Hi, this has been updated in v12.1.7-canary.23 of Next.js so that prefetching no longer triggers revalidations, please update and give it a try!