-
Notifications
You must be signed in to change notification settings - Fork 48.8k
[Fizz] Batch Suspense Boundary Reveal with Throttle #33076
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
One thing that needs to be resolved is how to deal with #31620 because it assumes that these are synchronously evaluated before the content loads. I think that solution has an existing problem though because a stylesheet can also block reveal, which will allow client rendering. That commit is likely itself blocked on the same stylesheet loading though. Once it commits it'll replace the SSR content that has also already streamed in which it really shouldn't ideally and may have consequences for View Transitions. Follow up here #33087. |
@@ -5217,10 +5217,19 @@ function flushCompletedQueues( | |||
); | |||
flushSegment(request, destination, completedRootSegment, null); | |||
request.completedRootSegment = null; | |||
const isComplete = | |||
request.allPendingTasks === 0 && | |||
request.pingedTasks.length === 0 && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove here and in finally of flushCompletedQueues
This is implied by the allPendingTasks check
Stacked on #33076. This fixes a bug where we used the "complete" status but the DOMContentLoaded event. This checks for not "loading" instead. We also add a new status where the boundary has been marked as complete by the server but has not yet flushed either due to being throttled, suspended on CSS or animating.
Stacked on #33073. React semantics is that Suspense boundaries reveal with a throttle (300ms). That helps avoid flashing reveals when a stream reveals many individual steps back to back. It can also improve overall performance by batching the layout and paint work that has to happen at each step. Unfortunately we never implemented this for SSR streaming - only for client navigations. This is highly noticeable on very dynamic sites with lots of Suspense boundaries. It can look good with a client nav but feel glitchy when you reload the page or initial load. This fixes the Fizz runtime to be throttled and reveals batched into a single paint at a time. We do this by first tracking the last paint after the complete (this will be the first paint if `rel="expect"` is respected). Then in the `completeBoundary` operation we queue the operation and then flush it all into a throttled batch. Another motivation is that View Transitions need to operate as a batch and individual steps get queued in a sequence so it's extra important to include as much content as possible in each animated step. This will be done in a follow up for SSR View Transitions. DiffTrain build for [ee7fee8](ee7fee8)
Stacked on #33076. This fixes a bug where we used the "complete" status but the DOMContentLoaded event. This checks for not "loading" instead. We also add a new status where the boundary has been marked as complete by the server but has not yet flushed either due to being throttled, suspended on CSS or animating. DiffTrain build for [0ed6ceb](0ed6ceb)
Stacked on #33076. This fixes a bug where we used the "complete" status but the DOMContentLoaded event. This checks for not "loading" instead. We also add a new status where the boundary has been marked as complete by the server but has not yet flushed either due to being throttled, suspended on CSS or animating. DiffTrain build for [0ed6ceb](0ed6ceb)
Stacked on #33073.
React semantics is that Suspense boundaries reveal with a throttle (300ms). That helps avoid flashing reveals when a stream reveals many individual steps back to back. It can also improve overall performance by batching the layout and paint work that has to happen at each step.
Unfortunately we never implemented this for SSR streaming - only for client navigations. This is highly noticeable on very dynamic sites with lots of Suspense boundaries. It can look good with a client nav but feel glitchy when you reload the page or initial load.
This fixes the Fizz runtime to be throttled and reveals batched into a single paint at a time. We do this by first tracking the last paint after the complete (this will be the first paint if
rel="expect"
is respected). Then in thecompleteBoundary
operation we queue the operation and then flush it all into a throttled batch.Another motivation is that View Transitions need to operate as a batch and individual steps get queued in a sequence so it's extra important to include as much content as possible in each animated step. This will be done in a follow up for SSR View Transitions.