Function getBlockingRenderMaxSize

packages/react-server/src/ReactFizzServer.js:422–455

(request: Request)

const DEFAULT_PROGRESSIVE_CHUNK_SIZE = 12800;

function getBlockingRenderMaxSize(request: Request): number {
  // We want to make sure that we can block the reveal of a well designed complete
  // shell but if you have constructed a too large shell (e.g. by not adding any
  // Suspense boundaries) then that might take too long to render. We shouldn't
  // punish users (or overzealous metrics tracking) in that scenario.
  // 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.
  // Web Vitals target 1.8 seconds for first paint and our goal to have the limit
  // be fast enough to hit that. For this argument we assume that most external
  // resources are already cached because it's a return visit, or inline styles.
  // If it's not, then it's highly unlikely that any render blocking instructions
  // we add has any impact what so ever on the paint.
  // Assuming a first byte of about 600ms which is kind of bad but common with a
  // decent static host. If it's longer e.g. due to dynamic rendering, then you
  // are going to bound by dynamic production of the content and you're better off
  // with Suspense boundaries anyway. This number doesn't matter much. Then you
  // have about 1.2 seconds left for bandwidth. On 3G that gives you about 112.5kb
  // worth of data. That's worth about 10x in terms of uncompressed bytes. Then we
  // half that just to account for longer latency, slower bandwidth and CPU processing.
  // Now we're down to about 500kb. In fact, looking at metrics we've collected with
  // rel="expect" examples and other documents, the impact on documents smaller than
  // that is within the noise. That's because there's enough happening within that
  // start up to not make HTML streaming not significantly better.
  // Content above the fold tends to be about 100-200kb tops. Therefore 500kb should
  // be enough head room for a good loading state. After that you should use
  // Suspense or SuspenseList to improve it.
  // Since this is highly related to the reason you would adjust the
  // progressiveChunkSize option, and always has to be higher, we define this limit
  // in terms of it. So if you want to increase the limit because you have high
  // bandwidth users, then you can adjust it up. If you are concerned about even
  // slower bandwidth then you can adjust it down.
  return request.progressiveChunkSize * 40; // 512kb by default.
}

function isEligibleForOutlining(
  request: Request,