[Fizz] Shorten throttle to hit a specific target metric (#33463)

Adding throttling or delaying on images, can obviously impact metrics.
However, it's all in the name of better actual user experience overall.
(Note that it's not strictly worse even for metric. Often it's actually
strictly better due to less work being done overall thanks to batching.)

Metrics can impact things like search ranking but I believe this is on a
curve. If you're already pretty good, then a slight delay won't suddenly
make you rank in a completely different category. Similarly, if you're
already pretty bad then a slight delay won't make it suddenly way worse.
It's still in the same realm. It's just one weight of many. I don't
think this will make a meaningful practical impact and if it does,
that's probably a bug in the weights that will get fixed.

However, because there's a race to try to "make everything green" in
terms of web vitals, if you go from green to yellow only because of some
throttling or suspensey images, it can feel bad. Therefore this
implements a heuristic where if the only reason we'd miss a specific
target is because of throttling or suspensey images, then we shorten the
timeout to hit the metric. This is a worse user experience because it
can lead to extra flashing but feeling good about "green" matters too.

If you then have another reveal that happens to be the largest
contentful paint after that, then that's throttled again so that it
doesn't become flashy after that. If you've already missed the deadline
then you're not going to hit your metric target anyway. It can affect
average but not median.

This is mainly about LCP. It doesn't affect FCP since that doesn't have
a throttle. If your LCP is the same as your FCP then it also doesn't
matter.

We assume that `performance.now()`'s zero point starts at the "start of
the navigation" which makes this simple. Even if we used the
`PerformanceNavigationTiming` API it would just tell us the same thing.

This only implements for Fizz since these metrics tend to currently only
by tracked for initial loads, but with soft navs tracking we could
consider implementing the same for Fiber throttles.

Author: sebmarkbage

packages/react-dom-bindings/src/server/fizz-instruction-set/ReactDOMFizzInstructionSetInlineCodeStrings.js

@@ -13,8 +13,16 @@ const SUSPENSE_PENDING_START_DATA = '$?';
 const SUSPENSE_QUEUED_START_DATA = '$~';
 const SUSPENSE_FALLBACK_START_DATA = '$!';
 
+const FALLBACK_THROTTLE_MS = 300;
+
 const SUSPENSEY_FONT_AND_IMAGE_TIMEOUT = 500;
 
+// If you have a target goal in mind for a metric to hit, you don't want the
+// only reason you miss it by a little bit to be throttling heuristics.
+// This tries to avoid throttling if avoiding it would let you hit this metric.
+// This is derived from trying to hit an LCP of 2.5 seconds with some head room.
+const TARGET_VANITY_METRIC = 2300;
+
 // TODO: Symbols that are referenced outside this module use dynamic accessor
 // notation instead of dot notation to prevent Closure's advanced compilation
 // mode from renaming. We could use extern files instead, but I couldn't get it
@@ -290,9 +298,18 @@ export function revealCompletedBoundariesWithViewTransitions(
           }
           return Promise.race([
             Promise.all(blockingPromises),
-            new Promise(resolve =>
-              setTimeout(resolve, SUSPENSEY_FONT_AND_IMAGE_TIMEOUT),
-            ),
+            new Promise(resolve => {
+              const currentTime = performance.now();
+              const msUntilTimeout =
+                // If the throttle would make us miss the target metric, then shorten the throttle.
+                // performance.now()'s zero value is assumed to be the start time of the metric.
+                currentTime < TARGET_VANITY_METRIC &&
+                currentTime > TARGET_VANITY_METRIC - FALLBACK_THROTTLE_MS
+                  ? TARGET_VANITY_METRIC - currentTime
+                  : // Otherwise it's throttled starting from last commit time.
+                    SUSPENSEY_FONT_AND_IMAGE_TIMEOUT;
+              setTimeout(resolve, msUntilTimeout);
+            }),
           ]);
         },
         types: [], // TODO: Add a hard coded type for Suspense reveals.
@@ -360,8 +377,6 @@ export function clientRenderBoundary(
   }
 }
 
-const FALLBACK_THROTTLE_MS = 300;
-
 export function completeBoundary(suspenseBoundaryID, contentID) {
   const contentNodeOuter = document.getElementById(contentID);
   if (!contentNodeOuter) {
@@ -395,8 +410,15 @@ export function completeBoundary(suspenseBoundaryID, contentID) {
     // to flush the batch. This is delayed by the throttle heuristic.
     const globalMostRecentFallbackTime =
       typeof window['$RT'] !== 'number' ? 0 : window['$RT'];
+    const currentTime = performance.now();
     const msUntilTimeout =
-      globalMostRecentFallbackTime + FALLBACK_THROTTLE_MS - performance.now();
+      // If the throttle would make us miss the target metric, then shorten the throttle.
+      // performance.now()'s zero value is assumed to be the start time of the metric.
+      currentTime < TARGET_VANITY_METRIC &&
+      currentTime > TARGET_VANITY_METRIC - FALLBACK_THROTTLE_MS
+        ? TARGET_VANITY_METRIC - currentTime
+        : // Otherwise it's throttled starting from last commit time.
+          globalMostRecentFallbackTime + FALLBACK_THROTTLE_MS - currentTime;
     // We always schedule the flush in a timer even if it's very low or negative to allow
     // for multiple completeBoundary calls that are already queued to have a chance to
     // make the batch.