[untitled]
5 comments
Wow had no idea you could narrow down React performance issues with just DevTools. Will need to do this soon as the app I'm working on is already lagging in certain places. How many of your performance issues would have just been avoided by using another framework e.g. SolidJS?
(Co)author here - happy to answer any questions :)
- This was a v fun (and challenging, due to Causal's scale!) project to do
- Most optimizations we’ve implemented were (very effective) one-off fixes. But we were also glad to find some rules of thumb that help to keep the app faster by default [1]
- My most interesting discovery was how ineffective Web Workers are. Causal, sometimes, has to do some expensive client-side data parsing. We tried to move data parsing to a web worker (= a separate thread) – but ended up reverting the optimization because it made the app slower. In JS, you can’t just pass a pointer to a data structure between threads; the browser has to clone the data structure [2] (with limited exceptions [3]). In our case, cloning the data between threads ended up being several times slower than parsing it in the main thread.
[1] https://www.causal.app/blog/react-perf#span-class=inline-cod...
[2] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
[3] https://developer.mozilla.org/en-US/docs/Glossary/Transferab...
- This was a v fun (and challenging, due to Causal's scale!) project to do
- Most optimizations we’ve implemented were (very effective) one-off fixes. But we were also glad to find some rules of thumb that help to keep the app faster by default [1]
- My most interesting discovery was how ineffective Web Workers are. Causal, sometimes, has to do some expensive client-side data parsing. We tried to move data parsing to a web worker (= a separate thread) – but ended up reverting the optimization because it made the app slower. In JS, you can’t just pass a pointer to a data structure between threads; the browser has to clone the data structure [2] (with limited exceptions [3]). In our case, cloning the data between threads ended up being several times slower than parsing it in the main thread.
[1] https://www.causal.app/blog/react-perf#span-class=inline-cod...
[2] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
[3] https://developer.mozilla.org/en-US/docs/Glossary/Transferab...
Great stuff! How do you measure frontend performance? Do you have any production metrics?
We're measuring Google's new INP metric + we log long event handlers and long task. It's really noisy though and hard to see regressions in the aggregate metrics.
We'll probably share another post about this stuff soon. If anyone has found something that works please let me know! ([email protected])
How do you manage these patch files? Is that a recommended approach?
Modern Yarn supports `yarn patch`: https://yarnpkg.com/cli/patch. For Yarn 1.x and npm, I’ve used https://www.npmjs.com/package/patch-package which also works well.
It's more of a short term solution. We're working closely with the AG Grid team to get these changes merged :)
Also, shout out to 3perf.com - Ivan has been extremely helpful with getting this over the line :)