DEV Community

Cover image for React is Slow, What to do now?

React is Slow, What to do now?

Nik L. on December 30, 2023

Check out more articles: Building a Scalable Notification System with gRPC and Microservices Adding a Notification Feed in React Websites A Compl...
Collapse
 
dannydev06 profile image
Danny akinola

I suggest Code Splitting:

Use code splitting to divide your application into smaller chunks, and load only the necessary parts when they are needed. This can be achieved using tools like Webpack.

Collapse
 
merri profile image
Vesa Piittinen

Although with React you will never get rid of the initial bundle size upon page load, and you'll suffer that penalty each time loading the HTML page as React itself is unsplittable. With Node.js it gets even worse since then you also have it's code included as well so that you get client side routing and all the related issues that go alongside with that.

Unless React dramatically changes how it's been designed there is no way for it to get rid of that code. They must do things like abandon their own event system.

Collapse
 
Sloan, the sloth mascot
Comment deleted
 
merri profile image
Vesa Piittinen

It isn't entirely about the speed of the connection, although that take is still a bit ignorant considering web speed is not always perfect depending on conditions and location.

The parsed JS is often the heaviest bytes on a website. So each time a HTML page boots that code will execute. Not a problem on your high end Apple Mac M(insert latest number here), but vast majority of devices are less performant. And at least I think most sites should work snappily regardless of the device capabilities.

Basically every take where you say "not a problem for me" is you not being aware that what is true for you does not apply to everyone else. Bundle size is both performance and accessibility concern. The bigger your bundle becomes and the heavier it becomes to execute, the more people are effected negatively.

Also in March Google starts to rank sites low if they score low on INP. That metric is awful on about every React site in existance, and that metric is related to initial JS bootstrap time.

So: bundle size does matter, a lot.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

The power of microprocessors grow year after year, and yet you see constant performance enhancements in many projects, including .Net (to mention a very large one). What I'm trying to say is: People that say "we won't care about our memory consumption because RAM is cheap", or "bundle size doesn't matter becase Internet speeds are faster year after year", are people unwilling or unable to do the right thing.

Apologies if it feels like it goes your way. It is my honest opinion.

Thread Thread
 
turtleflyer profile image
Andrei Kovalev

Do you know the size of the core React library bundle? It is less than 3 kB minified an gzipped. It is less than 100 ms of loading size even on 3G. Do you really think it is a bottleneck?

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Interesting. Can you point me to a React project in GitHub or elsewhere where once compile will produce a less than 42kb bundle? Because this is the size it is always seen. If you have an example of a React project than bundles around 3kb, I'd love to see it because that's the SolidJS and Svelte bundle sizes, never React sizes.

Thread Thread
 
turtleflyer profile image
Andrei Kovalev
Thread Thread
 
turtleflyer profile image
Andrei Kovalev
Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Thanks. It is an interesting metric, but by all means an incorrect one. The cost of React is 40kb as a minimum. I wonder why bundlephobia reports such a low number? Anyway, thanks for the link. Interesting thing, this bundlephobia. However, it is completely off base when it comes to React at the very least.

Thread Thread
 
turtleflyer profile image
Andrei Kovalev

Because it is true. Why do you think overthise?

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Because I have done the exercise many times:

  1. npm create vite@latest. Select React + Typescript + SWC.
  2. Move to project directory, then npm i.
  3. npm run build.

I just did it. Here's the screenshot: Out of the box, the sample Vite project is over 143KB, 46kb gzipped.

React Bundle

Would you like to see a Svelte test?

Thread Thread
 
merri profile image
Vesa Piittinen • Edited

Just FYI, about every React site requires React DOM:

bundlephobia.com/package/react-dom...

So it's 10 + 130 = 140 kilobytes just to parse React code.

Of course on a NextJS project you also need to add client router etc so it can work like a SPA, to make Link components work. That code needs to technically imitate actual page transition to ensure focus is in the right place, screen reader announces the right things and all the other stuff that is provided by native HTML page loading for no extra code.

And we got there because React DOM is so big that it does slow down app bootstrap time.

Thread Thread
 
monoprosito profile image
Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

That was nice, @monoprosito. Definitely quite informative. One more star for Svelte, I suppose. 👌

Collapse
 
buchslava profile image
Vyacheslav Chub

or Qwik ;)

Collapse
 
miketalbot profile image
Mike Talbot ⭐

Nice write-up!

I think the key thing is understanding what you are asking of a framework, if you render thousands of components then it's going to be slow, it's just easy to not think of that when working with the basic principles in React and not accounting for how things will scale.

Collapse
 
efpage profile image
Eckehard

Your car is slow? May it help to put more fuel in? Likely not.

Just buy a new one...

Collapse
 
devdufutur profile image
Rudy Nappée • Edited

First, define slow

Collapse
 
efpage profile image
Eckehard

Ok, wait a minute. I´ll tell you when this damn web site has been rendered....

Thread Thread
 
devdufutur profile image
Rudy Nappée

React isn't as slow

Thread Thread
 
efpage profile image
Eckehard

No, but obviously there are a number of stumbling blocks that should be avoided. If it turns out you're spending more time finding the stumbling blocks, then maybe it's time to find a new platform.

Thread Thread
 
devdufutur profile image
Rudy Nappée • Edited

AngularJS guys told 10 years ago that below 100ms of latency your users won't notice. Even in a complex app you have to do really crappy job to cross that limit.

If you look at complex & fucked up apps (look at jira for instance), latency is implied by a shitload of unnecessary XHR (graphql is our friend) not so much by the front-end library.

Thread Thread
 
artxe2 profile image
Yeom suyun

React is not slow enough to lose popularity.
Starbucks and McDonald's were able to expand globally because they were not tasteless...

Collapse
 
borfast profile image
Raúl Pedro Fernandes Santos

React is a great piece of software in terms of engineering but it is a terrible choice for the vast majority of projects because it was never meant to be used in the kind of projects most people work on. React's biggest problem isn't React itself; it's the fact that too many people pick their tools because they are shiny, and not because they solve the specific problem they are working on. I wrote about this here (or here, if you want the original).

Collapse
 
laurentpayot profile image
Laurent Payot

You can switch to Preact, a fast 3kB alternative to React with the same modern API.

Collapse
 
nikl profile image
Nik L.

Never heard, any resource?

Collapse
 
laurentpayot profile image
Laurent Payot

The resource was on the link ;) Once again: preactjs.com/

Collapse
 
opensourcee profile image
OpenSource

Interesting reading. Thanks for sharing!
I wonder how would Promise.all work in practice. Won’t it take longer to wait for all promises?

Collapse
 
merri profile image
Vesa Piittinen • Edited

It is faster in the case where you'll be doing all the requests anyway. It beats the waterfall case of request + wait + complete + request next + wait + complete + request another + wait + complete.

But in the overall picture it isn't a silver bullet, and you probably want to consider techniques that make things appear to be faster instead of being actually faster.

Collapse
 
opensourcee profile image
OpenSource

I see. Makes sense

Collapse
 
srbhr profile image
Saurabh Rai

React is slow. 🐌
Tries Angular.
React is Fast. 💨

~ 🤡

Collapse
 
fridaycandours profile image
Friday candour

I have solved all the problems mentioned in this article in my web development framework. We use it endlessly at uiedbook.

github.com/Uiedbook/cradova

Collapse
 
cod3ddy profile image
Cod3ddy

i don't but i just saw a post somewhere, they say next js makes it fast or something

Collapse
 
monty_65 profile image
Monty

Nice Article 👍

Collapse
 
friendz_me_12 profile image
friendz

Awsome Article ✨

Some comments have been hidden by the post's author - find out more