Introduce a new `fallback: 'blocking'` ISG mode

Feature request

Next.js should allow pages leveraging Incremental Static Generation (fallback: true in getStaticPaths) to opt-into a server-side rendering mode when an unknown path is encountered.

Currently, we serve a static HTML fallback that then loads the data client-side (via a fetch to the server).

While the static HTML fallback is generally considered to be better end-user UX and does not negatively affect SEO, it is incompatible with certain apps that rely on Facebook, Twitter, or other og:* crawlers that don’t support JavaScript.

Like fallback: true, after the unknown route successfully renders for the first time, it’s served as static HTML going forward and no longer will be a on-demand (blocking) render (SSR).

Describe the solution you’d like

Allow users to return fallback: 'blocking' from getStaticPaths, opting-out of the static HTML fallback.

[Timer]

If the app is being hosted on Vercel too, does the combination of revalidate: 1 and fallback: ‘blocking’ provide any advantage over using setting a cache control header with max-age: 1 and a really long stale-while-revalidate?

As far as I can tell, setting cache-control this way would let me get the same behavior with getInitialProps?

One advantage is what @timneutkens mentioned above: This feature it provider-agnostic and built-into Next.js, meaning it does not require a CDN to work.

The second difference is that you can prerender critical paths by returning them from paths: [...], this is not possible with getInitialProps. This feature is very important as it prevents new deployments from 500ing due to your database going down, etc.

[timneutkens]

If the app is being hosted on Vercel too, does the combination of revalidate: 1 and fallback: ‘blocking’ provide any advantage over using setting a cache control header with max-age: 1 and a really long stale-while-revalidate?

Yeah it’s a similar behavior, main difference is that it’s integrated with Next.js and you don’t have to know the exact cache-control header to set (which often goes wrong, e.g. forgetting to add stale-while-revalidate and such)