[Fizz] Error and deopt from rel=expect for large documents without boundaries #33454
+199
−64
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
React Core Team
sebmarkbage
commented
Jun 6, 2025
| @@ -5888,11 +5930,32 @@ function flushCompletedQueues( | |||
|
|
|||
| flushedByteSize = request.byteSize; // Start counting bytes | |||
| // TODO: Count the size of the preamble chunks too. | |||
There was a problem hiding this comment.
This TODO should probably be fixed since this can have meaningful impact on this metric.
sebmarkbage
force-pushed
the
relexpectlimit
branch
from
d8b3748 to
55dc536
Compare
sebmarkbage
commented
Jun 6, 2025
| (gate(flags => flags.enableFizzBlockingRender) | ||
| ? '<template id="_R_"></template>' | ||
| : ''), | ||
| ); |
There was a problem hiding this comment.
I disabled in the legacy API since these aren't part of the new "streaming" world. Unnecessary to break. They also won't have opt-ins to things like MPA ViewTransitions which this affects.
sebmarkbage
force-pushed
the
relexpectlimit
branch
from
55dc536 to
cef5c45
Compare
sebmarkbage
force-pushed
the
relexpectlimit
branch
from
cef5c45 to
be6c468
Compare
eps1lon
approved these changes
Jun 6, 2025
github-actions bot
pushed a commit
that referenced
this pull request
Jun 6, 2025
…undaries (#33454) We want to make sure that we can block the reveal of a well designed complete shell reliably. In the Suspense model, client transitions don't have any way to implicitly resolve. This means you need to use Suspense or SuspenseList to explicitly split the document. Relying on implicit would mean you can't add a Suspense boundary later where needed. So we highly encourage the use of them around large content. However, if you have constructed a too large shell (e.g. by not adding any Suspense boundaries at all) then that might take too long to render on the client. We shouldn't punish users (or overzealous metrics tracking tools like search engines) in that scenario. This opts out of render blocking if the shell ends up too large to be intentional and too slow to load. Instead it deopts to showing the content split up in arbitrary ways (browser default). It only does this for SSR, and not client navs so it's not reliable. In fact, we issue an error to `onError`. This error is recoverable in that the document is still produced. It's up to your framework to decide if this errors the build or just surface it for action later. What should be the limit though? There's a trade off here. If this limit is too low then you can't fit a reasonably well built UI within it without getting errors. If it's too high then things that accidentally fall below it might take too long to load. I came up with 512kB of uncompressed shell HTML. See the comment in code for the rationale for this number. TL;DR: Data and theory indicates that having this much content inside `rel="expect"` doesn't meaningfully change metrics. Research of above-the-fold content on various websites indicate that this can comfortable fit all of them which should be enough for any intentional initial paint. DiffTrain build for [d177272](d177272)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We want to make sure that we can block the reveal of a well designed complete shell reliably. In the Suspense model, client transitions don't have any way to implicitly resolve. This means you need to use Suspense or SuspenseList to explicitly split the document. Relying on implicit would mean you can't add a Suspense boundary later where needed. So we highly encourage the use of them around large content.
However, if you have constructed a too large shell (e.g. by not adding any Suspense boundaries at all) then that might take too long to render on the client. We shouldn't punish users (or overzealous metrics tracking tools like search engines) in that scenario.
This opts out of render blocking if the shell ends up too large to be intentional and too slow to load. Instead it deopts to showing the content split up in arbitrary ways (browser default). It only does this for SSR, and not client navs so it's not reliable.
In fact, we issue an error to
onError. This error is recoverable in that the document is still produced. It's up to your framework to decide if this errors the build or just surface it for action later.What should be the limit though? There's a trade off here. If this limit is too low then you can't fit a reasonably well built UI within it without getting errors. If it's too high then things that accidentally fall below it might take too long to load.
I came up with 512kB of uncompressed shell HTML. See the comment in code for the rationale for this number. TL;DR: Data and theory indicates that having this much content inside
rel="expect"doesn't meaningfully change metrics. Research of above-the-fold content on various websites indicate that this can comfortable fit all of them which should be enough for any intentional initial paint.