Thread by @dan_abramov

I’m thankful to Evan for pointing out perf bugs on beta.reactjs.org. I planned to look later but got nerdsniped. My screenshots are ~averages from ten runs I just did for both sites. (Prone to some variance, of course!) I want to share what I fixed.

https://twitter.com/youyuxi/status/1528599024814522368

The main mistake from the bundle size perspective was that we had an “utils” file, it got a heavy dependency (CodeMirror linter logic for sandboxes), but it was imported from the main entry point. The fix for that was to split the utils file into several. github.com/reactjs/reactj…

While doing this, I noticed we load the CodeMirror linter logic eagerly on the pages that *do* have sandboxes, but that’s also a bit too early. I wanted to defer that a bit compared to loading other code. Doesn’t affect the homepage but is a nice fix too. github.com/reactjs/reactj…

While doing *that*, I noticed that our ESLint sandbox integration bundles all built-in ESLint rules. But actually, we only want to bundle the React ESLint rules which our sandboxes will run automatically. So I fixed that too (also doesn’t affect homepage). github.com/reactjs/reactj…

Then I noticed that Next.js has not yet switched to bundling for modern browsers by default. Not a huge deal, but it bloats the generated code a bit. Until this is the default behavior, I flipped an experimental flag to enable it. github.com/reactjs/reactj…

Running that version on webpagetest (webpagetest.org/video/compare.…) shows there is a layout shift due to the custom font loading too late. Very bad! The font was hosted from another domain, and connecting to it took too much time. Serving from same domain fixed the shift in most cases.

Finally, you might have noticed the Total Blocking Time has gone down quite a bit. Actually, I didn’t do much. In React 18, wrapping some UI in <Suspense> makes its hydration non-blocking. I added a couple <Suspense> tags, and React 18 did the rest. github.com/reactjs/reactj…

React 18 hydrates synchronously down to the closest <Suspense> boundaries. Remaining hydration is non-blocking and happens in chunks. This is automatic: I added some <Suspense> boundaries, and hydrating them became non-blocking! That’s why TBT went down.

Now, of course you could say... But why run this code on the client in the first place? Isn’t hydrating something that’s mostly static kinda useless? Things are usually not 100% static, but a mix. One hybrid solution is Astro-like “islands”: splitting your code in two paradigms.

We don’t find solutions that split by paradigm very satisfying. So the approach we are working on is Server Components (which can run during the build, btw). Server Components let you stay within a single paradigm, but make some code server-only. Hydrating those parts is instant.

Instead of solving performance in the order of [ship less code] -> [optimize remaining client code], we are solving it in the order [optimize client code assuming there’s a lot] -> [ship less code]. Same eventual result but there is a higher bar to make client optimizations good.

In the end, the code that isn’t needed on the client shouldn’t be shipped to the client. Hydrating should be instant for static parts and only take a bit of time for interactive parts. But if a slowdown does happen, your <Suspense> boundaries will keep it non-blocking. 😍

As <Suspense> becomes widely adopted (after data fetching integrations), this perf improvement will come from simply adding a loading state somewhere in your code. It’s essentially a better default for hydration behavior. For more about React 18, check out

There’ll be more to optimize. Especially on sandbox-heavy pages. Like Evan pointed out, the INP metric (web.dev/inp/) looks sad. I doubt it’s because React is slow. :) I have one guess for a possible cause. If you want to help, here’s an idea: github.com/reactjs/reactj…

anyway,,, goodnight

*typo in the first tweet — should say “from nine runs”. the calculations were correct though

btw i think this is a fair point :)

https://twitter.com/youyuxi/status/1528744566324461569

One last thing. The benefits of non-blocking hydration in React 18 are much more obvious on a page with a *lot* of content. It doesn’t matter how much content there is! The browser becomes (and remains) responsive after the outer shell hydrates. Concurrent rendering is nice.

Of course, it would be even better if this only included the interactive components and skipped the static parts... But we already talked about this. We want mechanisms to do both so that you don’t have to choose.

https://twitter.com/dan_abramov/status/1529695089345318912