Adopting the compiler at Wakelet.com in production.

[NickBlow]

As we have a quite large codebase at wakelet.com, it took a while to roll the compiler out as we kept hitting edge cases and odd issues with our components (usually us doing weird things).

However, to the team's credit, all of those have since been resolved or had trivial workarounds. We finally rolled out the compiler to 100% of users in November, and I just wanted to share some of the stats.

We've not had any major issues reported, and of those that were reported, all of them were just existing bugs that were surfaced by the compiler, which is another advantage of the model - excessive re-rendering can hide a lot of data races.

We've now had enough time to collect data about the performance improvement. We saw big improvements in INP, and modest improvements in LCP. The metrics we collect are quite coarse grained, but they paint a nice story.

Overall, our LCP improved by 10% (2.6s -> 2.4s), and our INP improved by about 15% (275ms -> 240ms).

Doing more granular testing, we saw the biggest gains in elements that were pure React (such as Radix dropdowns), where the INP speedup was closer to 30%. However, built in UI elements still saw an INP speedup.

It's not a panacea - we still have a lot of work to improve these numbers ourselves, so it didn't magically solve all our performance problems. However, this was as close to a 'free lunch' as possible, it didn't take a huge amount of effort to implement and has had concrete improvements to our UX and lighthouse metrics.

[rtrembecky]

hello @NickBlow 👋
I'd like to ask whether you also checked the bundle size difference and considered it reasonable. I'm working on a fairly large codebase as well and while there don't seem to be any functional issues with the React Compiler enabled, the JS bundles for our Next.js pages increase by 8-100 kB (e.g. we already have some huge pages building to 686 kB and with the Compiler it becomes 761 kB), which isn't really acceptable 🤔.

[NickBlow]

Hmm, that’s not something we looked at in detail I’m afraid though we did test on lower end devices. The speed up in load time was there even on throttled network and CPU so I guess it outweighs the bundle size increase.

We tend to have fairly deep sessions so initial load & payload size, while important, aren’t the #1 things we are concerned about.

[ShanonJackson]

Really want to question these numbers a bit @NickBlow ; When I go to https://playground.react.dev and paste components in this is what I see

1. Byte-size - 0-50% larger than it otherwise would be on "Right" side.
2. Memory - Alot more memory stored on heap instead of stack (because $[] persists memory AFTER the function (the component) returns.
3. Instructions - More if statements and memory allocations can never speed up mount; When you look at the "Hello world" example; It now has to go through an if statement, equality check, AND heap allocation to return "hello world" rather than just returning it. Because react-compiler only ever adds instructions; It can only ever make mount performance worse.

---

With 1-3 in mind; How can LCP improve? Does anyone have a component input/output from React-Compiler example where the instruction set on the "output" side has made first render faster? Everything 1-3 is a LCP de-optimization.

Re-renders are another story, I believe it makes re-renders faster (reading output) but specifically mount is something I'm interested in.

[NickBlow]

Hey, I don’t work at Wakelet any more but from what I remember it was because our LCP was after mount - we had some images loading on the page. So going from first paint to largest contentful paint was quicker since the re-rendering of the page after all the stuff was done loading was faster.

That is to say - our FCP may well have gotten slower, I didn’t actually measure it at the time.

[ShanonJackson]

Hey, I don’t work at Wakelet any more but from what I remember it was because our LCP was after mount - we had some images loading on the page. So going from first paint to largest contentful paint was quicker since the re-rendering of the page after all the stuff was done loading was faster.

That is to say - our FCP may well have gotten slower, I didn’t actually measure it at the time.

---

Thanks for getting back to me, Do you remember if your old company had a convention to use useMemo / useCallback everywhere? This is relevant because I'm trying to build up a case for the types of applications that will see perf improvements, and what those perf improvements will be, and which metrics will get worse.

[NickBlow]

We didn’t use useMemo or useCallback a lot. We only reached for it when there were noticeable performance issues with that component. We did use React.memo a lot and tried to enforce that to varying success.

We definitely suffered from death by a thousand cuts with minor perf issues across hundreds/thousands of components.