RFC: Crawler-Aware ISR Fallback #28180
Replies: 3 comments 4 replies
-
Super excited for this. Would it work for iMessage and Twitter previews too? A key part of blocking the fallback for me is ensuring that URL previews work when people share them. But when users are on the app, I want to show the skeleton. |
Beta Was this translation helpful? Give feedback.
-
Update: This feature has been implemented and is now available on |
Beta Was this translation helpful? Give feedback.
-
Is it possible to extend the user agents. We want for example semrush also to load server side. But this is not included in the regex. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Update: This has shipped! https://nextjs.org/blog/next-12#bot-aware-isr-fallback
Goals
fallback: true
, while still serving the previous behavior of the fallback state to non-crawler User-Agents.Background
Currently, ISR with
fallback: true
renders a fallback state before rendering the page contents. To block the page from loading (server-rendering), you need to usefallback: 'blocking'
.A current tradeoff of using
fallback: true
is SEO-dependent pages render a skeleton loader for both users and web crawlers. As a result, users have to resort to usingfallback: 'blocking'
, which might not be ideal since it's always server-rendered.Proposal
Distinguish between a user and web crawler request for
fallback: true
:Client-Side Transitions
A related issue to this RFC is client-side transitions. For example, if a page uses
fallback: true
and is linked internally withnext/link
, the transition still behaves likefallback: "blocking"
. We should allow users to customize this behavior.Beta Was this translation helpful? Give feedback.
All reactions