Scaling React: What Actually Matters

So, hey everyone. I am Tathagath, and I'm a front-end engineering leader based out of India. And I've been scalable front-end teams and systems and have shipped them. Over the years, I've led UI engineering processes across products serving millions of users. So the focus has always been performance, architecture, and the best practices that let the teams move fast enough and without trading away the quality. And hence, the talk today is inspired from this. And it's called Scaling React, What Actually Matters? And probably, we'll spend the next 20-25 minutes to talk about something that I've watched based on a lot of engineering teams, time across a lot of teams. And it's almost like all the problems that you think React is creating, but it's not actually. It's wrong architecture calls and all those things. So, let's get started. And the topic is scaling React, What Actually Matters?

So, I will first broadly talk about the inspiration of this talk, right? What was the conversation that I had and that inspired me to spread this talk across? Let's start with a lot of you must have faced the problem of your app is slowing down. And you must have been a part of a boardroom where a meeting is concluded with a question like, Oh, should we migrate off the React and maybe try some other framework or library? Or maybe we should just rewrite the entire application in any trendy framework or maybe framework of the week and so on and so forth, right? A lot of you must have encountered this within a meeting. And yeah, me too. I mean, I also encountered the same thing. And what I've discovered is almost every single time it turned out that React is not the problem of the slowness of your application or React is not the bottleneck of your application. So, this talk is actually about breaking it down and why we keep blaming the wrong thing always. React being the wrong thing in this case, but in actuality it's not. So, React isn't slow, your architecture is.

And we'll briefly cover a bunch of problems that seems to be a React based problem, but it's not actually a React problem. It's a problem that your architecture core holds on. So, let's move on. Why this matters is, again, I kept on reiterating. So, I'll probably show you five things that looks like a React problem, but are not. And by the end, you'll probably have a checklist that you can run on your app on every Monday morning to check whether this checklist is fulfilled or not. Now, what do you see here is a performance pyramid. And when I say a performance pyramid, it's mostly everything your app comprises of, right? Before we get too technical, maybe, or get on the problems that we're going to talk about, let's build a mental model on the structure of the rest of the talk, right? So, whenever your apps, you know, feel slow, the problem lives somewhere on this pyramid that you're seeing on the screen. At the top, we have a network layer, what you fetch, when you fetch, and in what order you fetch, right? Then architecture, about how your state is organized, how do you manage your state, how your data flows, and then comes the rendering pyramid, right? Rending part of the pyramid, which mostly is taken care of by the React itself. But we will talk about it as well. And then at the bottom, you could see hoops and other micro optimization, right? And here's the uncomfortable truth. Like, most of the blogs out there, most of the tweets out there, most of the React performance content lives at the bottom of this pyramid.

So, for example, use of use memo, wrap things in memo, don't define functions within the render. All those things are lying at the bottom of the pyramid. And the biggest wins are at the top. And most teams never look there. They opt this over the bottom and ignore the top. Hence, the bottleneck comes, right? And the five problems or four problems that we're going to cover today, four of them live in the top half of this pyramid, which you see on the screen.

Over-rendering isn't React's fault. The tagline itself tells you a lot, but let's talk a bit about it. So, the first problem, the most common complaint I hear is my React application is rendering a lot. It is rendering too much. And that's a very, very common thing I hear. A re-render is not a performance problem. So, in my opinion, React was literally designed to just re-render and it's pretty good at it. The problem isn't that React re-renders. The problem is what do you ask it to re-render. So, it's a different thing, two different things, right? If you put your user object, let's take an example. I don't want to show a lot of code on the screen because it's a bit difficult to read. But I'll probably try to relate it and try to create some analogy with what we as a developer, as engineers face, right? So, if you put a big user object and your shopping cart in the same context at the top of your app, every cart update will re-trigger a re-render of everything that consumes that context. That is how context works, right? And that's not React being slow. That's an architectural decision you made probably without realizing it. So, over-re-rendering is not a React fault. Oh yeah, it makes your app slow, but it's not because of the React, right? So, that's the problem number one. Let's get deep into it.

There's a very famous thing known as context broadcast pattern in React. So, if you search on the web, you'll get a lot of Reddit posts, a lot of people talk about context broadcast problem, right? It's like when you change the value passed to a context provider, every consumer of the context re-renders. It doesn't matter if the consumer only cares about one tiny part of their value. It doesn't matter because if that part changes, everyone re-renders. Simple. So, imagine you've got a big app context at the root, right? Holding the user, the theme of the app, the feature flags, the cart, the notification, and so on.

So, imagine you've got a big app context at the root, right? Holding the user, the theme of the app, the feature flags, the cart, the notification, and so on. So, every time a notification arrives, every component that touches that context re-renders. As simple as that. So, this again is not a React problem or React being slow. This is broadcast architecture being broadcast architecture, right? So, that again creates a bottleneck.

Moving on, let's talk about how can we fix this. And since I talked about this, a very common pattern that most of us must have seen or must have followed in our past or currently. So, what's the fix for this? So, let's talk about the wrong fix, which, you know, as I talked about, a lot of blog and a lot of people tell you to do. It's wrapping everything in react.memo and call it a day. Done. That's not the right fix. That's exactly, you know, creating a symptom instead of a disease.

Now, the right fix lies in the architectural call that you make. So, for example, split your context by how often they update. For example, theme of an app changes very rarely, but a card of an app changes more frequently or constantly. So, they should not be a part of the same provider. As simple as that. And for volatile states, for example, subscription based, you know, store, like Just Stand and etc., with those components subscribe to a slice of the state they want to update and they want to re-render on when they change, not the entire state. Right.

So my rule of thumb is very simple. If your reflex, when you see a performance issue is to reach for memo, stop there. Ask why the component is re-rendering. Usually the answer is usually the answer. When I say usually, most of the times the answer is in your state architecture, not in your end of function.

So moving ahead, this is a very short note on React compiler. And I was preparing the slides. I came across this. So I just wanted to maybe have a quick walkthrough on what I encountered. So, you know, this will come as a part of Q&A in the later series. So probably wanted to cover it in between. So when React compiler hit 1.0 stable last year, it ships with the next JS16. What it does, at build time, it automatically inserts memorization wherever it's needed. So in theory, you stop writing use memo and use callback by hand.

This is great. It removes a whole lot of category of busy work. But and I want to be really clear here, the compiler doesn't fix the problems we're talking about today in this entire talk. It doesn't fix context broadcast. It doesn't fix the network waterfalls. It doesn't fix the third-party script, bloating your app. It doesn't fix a bad SSL strategy and so on. It fixes the things that were already kind of solvable. The architecture problems still belong to us and you. Right.

So moving forward, let's go on to the problem. Number two. Problem number two is global state misuse. Now, this is the single most common architectural mistake I see. And it doesn't get talked about enough. For example, teams put server data. I mean, the data coming from an API into client state libraries, readups, test and mobile and whatever. And they spend hundreds of lines of code re-implementing things that probably the data fetching library solved years ago.

For example, loading state, error states, retry logic, cache invalidations, and all those de-duplication, pagination, all those things have already been solved with data fetching libraries years ago. So global state management is a very big problem. Now let's deep dive into server state versus what a client state looks like. Probably there are three kinds of state I would broadly categorize states of a React application into.

One is your server state. When I say server state, it's the data coming from API that needs caching, invalidation, refetching, de-duplication. Libraries like React Query, SWR, RTK Query exist for this purpose and are very good at it. Then comes the client state, which is the UI state, like a model that opens, a form being typed in, a dropdown selection, a radio selection. Local state is mostly fine in these cases. Finally, the global app state includes theming and authorization, which are globally shared and need infrequent updates but need to be shared across the application.

Now comes the client state. Second type of state I would categorize into. So client state is the UI state, like for example, a model that opens, a form that is being typed in, a dropdown selection, a radio selection. So these states lives very close to your component that uses them. So, for example, local state is mostly fine in these cases. And we would almost never need a library for this. And then comes a global app state. For example, theming in your application is something is a global stuff or authorization. The auth of the application is your global app stuff. So these are tiny things, infrequent updates happen here, but they need to be globally shared across our application. Right. And the mistake is contemplating these. The biggest mistake is putting server state in a client state library, because then you are re-implementing caching and validation, I think, by hand pretty badly. So there's no point of reinventing the wheel. Right.

Let's cover a classic anti-pattern that would probably relate to every one of us and would explain the states that I, category of the states that I talked about. So let's say. Reduce or reduce slice with 300 lines of code managing the user data, loading, reducer, error reducer, success, reducer, fetched chunk, retry logic and all those things. The same behavior in react query or SWR is maybe 10 lines of declarative configuration. That's it. Same functionality, far less code and critically fewer bugs around the state, stale data, race conditions and double fetches. Right. So this isn't again, a react problem. It's choosing the wrong tool for the job and then blaming the framework when the job is hard. Probably right. So it's a classic anti-pattern that we follow on very frequent basis, or at least I have seen people following.

Moving on to the problem number three that we'll talk about today. And it's called network waterfalls. A lot of us must have encountered this, but I would double click on it and probably cover it in quick, quick span. So this is, I think, probably the most under discussed performance issue in our industry.

And it's one of the, you know, most often when I get pulled into react is slow investigations. So most of what the teams call react is or react being slow is actually a network waterfall in disguise. So the app isn't slow because react is slow or whatever, but it's slow because you're making a user wait through three sequential round trips that should have been one. One round trip, probably three sequential API calls that would have been one. So that's that's what gives your app a slow thing and probably is called a network waterfall. Right.

So let's talk about fetch on render trap. So it's I'll explain what for fetch on render trap is. So how our network waterfall happens. So it's mostly it's the most natural thing to write. Let's say a component a mounts, it fires its own fetch in the use effect. The data comes back, component A renders, which causes the component B to mount. Then component A fire its own fetch. Data comes back to B. B renders. C mounts. C fetches. So three sequential round trips happening, code looks very beautiful, tidy. Each component managing its own data. Very clean, very co-located. Right. But the user waits for four seconds because each fetch can only start after the previous one data is back. So it's sequential fetching, making the user wait for decent amount of time that could have been, you know, made less. So this is the fetch on rendered trap mostly. I'm giving the prize to network waterfall. This is a very quick code example of very. This is the version of bug that everyone has shipped at some point of, you know, time in their career. And so if you see the example on the left, it's three awaits in a row. Each one, let's say waits for, you know, the previous one to finish. And then if each call takes 200 milliseconds, the overall time is somewhere around 600 milliseconds.

So the bottleneck is the third of it. And you can see the bottleneck is not third of it. Sorry. The bottleneck is the slowest of it that, you know, takes your time. So on the right hand side, if you see, there's a promise to all that requests all three request fire at once. So the total time is whichever is the slowest one is probably in all in these three cases, let's say 200 milliseconds is the time each one takes. Probably 200 millisecond is the time your total user waits on the screen. So same data, but the time's faster. And this is the trivial version of the problem. The hard versioning is when the waterfall is hidden across multiple components and you can't see it without opening your network tab.

And hence, all of us here would agree with the fact that when we are developing something, the network tab is something that is always open on the, you know, as a part of our inspect element sort of thing. So this is what and it's very easy to get wrong here because the code seems very tidy at the first go.

Now, I would want to talk about how would you, you know, fix the waterfalls at the very architectural level? And it's not that you fix waterfalls component by component, you fix them at the architectural level. When I say, for example, move data, move the data fetching logic to the route level, loaders in for example, Tankstack router or maybe React router, server components in Next.js, the idea is the same. Kick off fetches before the component that needs the data even mounts. This is called a render as you fetch. Right. You start the fetch first, then render. Suspense, for example, lets you read from the in-flight promises. So the component can declare its data dependency without even initiating the fetch itself. So and in short, before you blame React for a slow page, open the network tab. If you see a staircase, then that's the waterfall. And that's not all a framework problem. It's again a problem of the way we architected the application.

Right. So let's and then I usually like to, you know, put out the references of the sources, which I gather the information from at the bottom of the slides, wherever the source are there. You can always go there and, you know, cross check my claims or maybe read more about what I'm trying to tell you. Right.

So let's let's move on to the problem number four. And it's a third party scripts. So this is the sleeper hit of the talk. And we don't realize it till we see. I even if I talk about myself, I do not realize that party scripts can be culprit. Till the point I actually saw those things being becoming a bottleneck. And I probably agree on the fact that everyone in this room is suffering from it.

So your app code is probably not bloated enough. But let me let me show you some numbers. Right. Before you even be. So these numbers are I have again mentioned the sources, but these numbers are from HTTP archive, which measures the real web. Right. And the average web page loads more than thirty five third party scripts and thirty five. That's pretty huge number. Right. And a single third party script can block your page from rendering. Not slow it down, but block it entirely from rendering.

So that's the massive of a third party script loading without you knowing it. And the average blocking time for Drop and most popular third party scripts is somewhere around one point four seconds. And again, that's one point four second blocking time is pretty huge. And again, that's not, you know, your react code problem. That's not your bundler. But that's a tag your marketing team asked you to add 18 months ago. And now you see that in action, creating real bottlenecks across our applications.

So I would say, you know, death by a thousand tags. So let's sort of try to visualize a production app where we've got an analytics SDK, a session replay tool like, you know, full story or hot jar and a chat widget, a feature flag SDK, maybe a A, B testing tool, a tag manager that loads more tags dynamically. Each one of these, you know, on a date was added, look small. It's just a tag. It's lazy loaded. It's async. But just stack them up and they outweigh your application code. Hence again, becoming a bottleneck. You can't blame your application code entirely. It's third party scripts you were asked to put in without even, you know, previewing them.

Now comes. Let's let's talk about a very painful part. OK. It's OK if we create these mistakes. But what is the cost of creating these mistakes? Right. So and it's the pattern that we'll discuss here. It's mostly a consistent pattern and it's so consistent that it's almost funny. So let's take an example of the engineering team spends a full quarter optimizing the bundle. They do core splitting. They do lazy loading, replacing the moment with data finesse and removing barrel imports. And they get the bundle down by a couple of hundred kilobytes and they celebrate. That's a great achievement, in my opinion. Right.

But two weeks later, marketing ads, ads on a new tag in the afternoon. And the performance gains evaporate. Nobody connects the two events. Engineering gets blamed for the app being slow again. So probably this is a, you know, a governance problem dressed up as a performance problem, in my opinion. Right.

And. What should you do, actually, you know, probably what should be the the the way or the the strategy to avoid these. So probably five things and these are not optional, in my opinion, if you really care about the user performance. The number one being engineering was the third party budget. It's not marketing's call alone. If a new tag is added is going in, engineering needs to review it. And number two, lazy load, noncritical scripts. Anything that doesn't need to fire on the first pane should wait, should not block anything.

Number three, quarterly audits. Every tag has to justify its weight. Most of most of them can't because they load up a lot of unnecessary things into it and load it. But you have to. And that's where the real engineering comes in. Like, you should know what is running in your browser. You should know what is running inside your application. Right. Number four. Maybe pushing back on the request of just adding this tag request with data. So what it costs in load time, numbers, when these arguments and I say numbers in this argument, I personally, you know, have fought or have pushed back on these things. And if I have a data point to justify myself, it's absolutely OK. And number five, include the third party impacts in your performance dashboards, which most of us usually don't do. But if you only measure your own code, you're missing the biggest cost. Like a lot of things happen behind the scenes on these third party scripts. Right.

And let's move on to the problem. Number five. And I call it as SSR, SSR misapplied. And this is a trendy mistake of the last few years. Right. Teams adopt next years or remakes expecting some magic out of the box. They flip the switch on SSR and sometimes sometimes they ship a slower app than they had before. So this isn't a magic. But trust me, SSR isn't a magic. It's a tool with the cost and applying it without understanding the cost is probably, you know, how you make things slower while feeling more sophisticated. Right.

And let's let's just dive on the common SSR mistakes that we usually do. And I probably have seen four patterns constantly. The first one is. So rendering pages that should have been static, if the content doesn't change on each request, I don't see a need of an SSR, it's probably an SSG or an ISR case, but we are over utilizing or killing the SSR rendering things. Right. There's no need of it. The number two is client fetching on top of server and data. For example, you fetch on the server, render it and send the client. Then fetch the same data again in the use effect. That's probably double fetch twice the work. Again, a pitfall, again, a common mistake.

Number three, marking everything as a client component in a server components application. Just slapping a used client on every everything gives you the cost of SSR without any benefits. Yes. You're anyway shipping a, you know, a JavaScript. That's it. So blindly writing use client on the top of your file doesn't make any sense. It's just a killing killing thing for your application. Number four.

The most common mistake observed is ignoring the hydration cost in React applications. Hydration is a crucial process that enhances interactivity but comes with a price, particularly impacting performance on lower-end devices. Categorizing common mistakes, hydration stands out as a significant factor affecting app performance.

Referencing a blog by the VIX engineering team, the concept of hydration being a taxing process resonates strongly. With hundreds of millions of pages, they emphasize the impact of hydration on app speed and efficiency, highlighting the importance of understanding server-client boundaries for optimal performance.

Reflecting on the overarching patterns of mistakes, the realization dawns that the bottlenecks in React applications often stem from decisions made by developers. Understanding the intricacies of rendering, state management, network optimization, and proper utilization of SSR are crucial in achieving high-performance applications.

Let's double click on it. So I was reading a blog by VIX engineering team and would like to pick a very nice phrase that I caught upon. So they probably shipped a blog about this in last year, November, October. I don't remember the time, but they're under hundreds of millions of page pages. They love SSR and they're saying out loud that hydration became in their words, a tax they couldn't ignore. And this is from VIX own engineering team. And I feel that's a bulletproof, you know, a solid validation of the claim that we've been talking about in the last SSR mistakes.

So several components change this calculation. They don't ship implementation code to the client at all. Less code to hydrate. But you only get that benefit if you understand the server client boundary and use it intentionally. Right. And so sophisticated tools don't make slow apps fast. Understanding them does. And. Moving on.

So the pattern across all five is probably less just maybe take a step back, let's pull back and see what what we discovered until now. So over rendering, number one problem, global state misuse, network waterfalls, third party bloat SSR misapplied. And if you carefully see none of them or none of these are real problems, all of these are decisions, decisions that we that me and you made are the real bottlenecks. So React is exactly doing what you told it to do. The framework of the library is rendering what you asked it to render. Then you asked it to render. The slowness isn't coming from React. It's coming from the architecture me and you built on top of it. So probably the plan is we should start a start to think like an architect.

So if there is one mindset shift that I want you to take away from this talk, it's stop asking if is react fast enough. That's the wrong question. The React is absolutely fast enough. Start asking the architect questions. For example, what am I fetching and when who owns the state and why is it global? What's re-rendering and what actually subscribes to it? What's in my bundle that I did not write? Probably typical third party scripts. What am I rendering on the server and why? I think these questions, these are the questions that move performance and not should I use memo here? Right. As I promised to handle a Monday checklist, Monday morning checklist to everyone, I would give this as a checklist. And this is something concrete that, for example, network tab. So open the network tab, look at your most important page load. Is it a staircase or a parallel burst? If it's a staircase, you have a waterfall. Number two, open your react app tools profiler, click through that, click through your app. What re-renders on each interaction are these components re-rendering that have no reason to? If yes, check it out. Number three, run a bundle analyzer. Look at the third party section. Who owns those scripts? Can you justify each one of them? If yes, good to go. If not, probably you need to review it. Number four, list everything in your global state. How much of it is actually server state pretending to be client state? That's a very, very important check we need to, you know, look upon. And last but not the least, find your largest context. Right. And how often does its value change? How big is the sub tree underneath it? So and probably from my experience, you will definitely find something embarrassing within the first hour of this, you know, going through the checklist. I guarantee it. So that's that's Monday morning checklist for you. And before we close, the honest conclusion. If you do all of that and really do all of that and react to still your bottleneck, then I think congratulations. You've earned the right to consider a migration. But in my experience, almost nobody gets that. Almost every team that thought React was the problem found something else when they looked very carefully into it and react is in the bottleneck. The decisions around it are probably think like an architect, not a framework user, a library user. And the next time someone is in a meeting, say as we should migrate, probably ask them what's in their network tab. So thank you. And I hope this made a lot of sense to the audience out there. And these are the handles that you can, you know, maybe catch up on, catch up with me on Twitter and LinkedIn for any anything that you want to chime on. Thank you.