React internally already optimizes the performance quite a bit without having to explicitly optimize for performance. React.memo can help you to optimize the number of renders of your React components even further.
In this article I will explain to you how you can optimize React performance by using React.memo, some common pitfalls you could encounter and why you shouldn’t always use React.memo.
Throughout the process, we anchored our work around two technical mantras:
As little as possible, as early as possible. We should deliver only the resources we need, and we should strive to have them arrive right before we need them.
Engineering experience in service of user experience. The end goal of our development is all about the people using our website. As we think about the UX challenges on our site, we can adapt the experience to guide engineers to do the right thing by default.
🤔 A bit weird they named the CSS section “Rethinking CSS to unlock new capabilities” though, as they’re basically using CSS as it is meant to be used: use em for font-sizes so that users can zoom, use CSS Custom Properties for theming / dark mode, etc. #embracetheplatform
There is a sweet spot of React: in moderately interactive interfaces. Complex forms that require immediate feedback, UIs that need to move around and react instantly. That’s where it excels.
But there’s a lot on either side of that sweet spot.
The low performance parts don’t need to be React. Listing pages, static pages, blogs – these things are increasingly built in React, but the benefits they accrue are extremely narrow. A lot of the optimizations that are cropping up in these corners, things like bundle splitting, server-side rendering, and prerendering, are triangulating, essentially, what we had before the rise of React.
If you’re swinging the React hammer, everything looks like a <Nail />. A smart developer knows when to use it, and when not to use it.
But what if you didn’t have to choose? As Dan Abramov from the React team tweeted (be sure to read the whole thread):
Imagine a CRUD React app with routes — but with no client-side router. Imagine the JS code for most of your components is never shipped to the client — but you can sprinkle some interactivity where you want to. Imagine there was no “backend” because it would be your components.
/* "black star" and element content is read out */
/* "Highlighted item" and element content is read out */
content: "★" / "Highlighted item";
/* Generated content is ignored and only element content is read out */
content: "★" / "";
Doesn’t work in Safari nor Firefox at the time of writing though.