Introduction
Material-UI is a popular components library (a competitor of Reactstrap that unifies React and Material Design, the design system built by Google.
As a React developer I've used Material-UI in countless projets and I must say that it's a great library that comes with its grid system, lots of components, and helps build consistent UIs quite fast.
I was pretty happy with it until I used it for my personnal open-source project Ammo.
Quick parenthesis about Ammo: it's an open source projects which aims at capturing http requests and turn them into stress test engines scripts (such as Gatling). Not the focus of this article though, I won't dive into more details.
Context
Before exposing my unhappiness with Material-UI, let's get a look at my struggle.
In Ammo, I have a list of items that looks like the following :
Each item in the list can be collapsed / uncollapsed :
As you can see here, when uncollapsed an item reveals a few things, but nothing too fancy nor complicated. On the left, we can oberve basic HTML divs with text, and on the right we have code snippets (formatted / prettified thanks to React syntax highlighter).
Yet, I would very quickly notice that the overall performance of the application is absolutely terrible.
What?
A first set of measures
After developping the code-snippets-highlighting feature, just for the sake of being 100% happy with the feature, I tried to throw a couple items in my list and confirm that the syntax highlighting library did not tear down the performance of the app.
The idea proved to be relevant as the performance turned out to be horrible.
Just to illustrate how bad it was, here is a gif of what happend when adding 50 items to the interface (using a setInterval, adding 1 item every 300ms) :
As you can see, the application is lagging like hell and a real pain to use. With just 50 items !
Coming from a gaming background, where one has to display images, animations, sound effects & musics, multiple layers of background etc. at 60FPS, seeing such a lag just for rendering HTML divs was too much to bear. So I dove into profiling.
Witch hunt: React edition
My first intuition was that there was something wrong with React. After all, I had seen (and done, let's be honest) in the past lots of apps with unnecessary renders and performance-wise poor practices. So the first thing I made was to make sure that the list was optimized, doing 2 things :
- Giving non-index, unique keys to each item in the list
- Memoize the already-rendered items so that they would not re-render when adding a new one. I used
memobutuseMemois just as valid.
After that I profiled the app :
We can notice :
- First of all, the memoization seems to be working very fine. We can see that the items already rendered are greyed out, meaning that they did not re-render
- We can see that the newly introduced item is indeed taking some render time
But what got me worried is the graph in the upper-right corner. As you can see, renders are getting slower over time. The rendering of the new item starts off taking around 100ms, but when the list gets longer, it takes up to 500ms.
What ?
First of all, why is the number of items in the list having any influence at all on the rendering time of the new item? And then, 500ms to render some basic divs! Horse crap!
Let's zoom in on the profiling of the rendering of one item :
On the image I highlighted 2 things :
- On the right, we can see that the react-syntax-highlighter, my first source of worry, is not at all responsible for the poor performance. It renders decently fast
- What seems to be taking quite some time are the "headers" (on the left).
Just to be clear, this is a "header" :
It's really nothing, just two inlined-texts! How come it be that slow??? Just to prove my point even further, here is the code of the <Header> component:
<Box className={classes.values}>
<Typography variant="subtitle2">
<span>{key}</span> :
<span className={classes.headerValue}>
"{value}"
</span>
</Typography>
</Box>
There is litteraly nothing fancy here. No hidden performance caveheat, it's just a few basic divs!
It all comes down to Material-UI
Quite desperate, I tried lots of things, went through lots of forums, still trying to figure out how React could mess things this badly. And then, out of ideas, I naively tried to replace <Box> components with <div>:
<div className={classes.values}>
<Typography variant="subtitle2">
<span>{key}</span> :
<span className={classes.headerValue}>
"{value}"
</span>
</Typography>
</div>
Stunningly, I saw some improvement in the performance! I went a bit further and tried to get rid of as much Material-UI components as possible (mostly <Box> and <Typography>) and I ended up with this :
If your read that right you'd see that :
- This test is done with 500 items (~1000 renders). And it's fluid!
- The highest rendering peak is at ~110ms (instead of 500ms for 50 items)
- The items rendering times are consistent and do not increase with the number of items in the list
So that's a big win! Now the app is decently fluid with 10 times more items! And its performance is consistent!
Conclusion
Material-UI is a great library and has had my back in the past years, yet now I would strongly advise against using it if your application might present performance challenges. A simple form or a standard web page shouldn't be a problem, but still, keep that in mind.
Of course I'm not the first one to find out about those problems, there are several issues open on Github (this one for example).
Also, after all this optimization, you could still argue that a 110ms rendering time for one item is still huge, and I'd agree, but I'll leave things here for the time being. Any further optimization shall be a good topic for a new article!
Top comments (28)
It would be very interesting to dive in the "Why". What is the cause of this performance loss ? Is it due to
<Box>only ? Can you avoid it somehow ? etcI agree 100%! But I wanted to keep this article short (and didn't quite succeed did I?). Material for another article I guess ?
It's quite short and precise. I love it.
Great post @gaelferrand ! I wish I read this earlier so that I wouldn't feel like banging my head on the wall. Thanks to React MUI, I surprised myself finding out my to-be-upgraded portfolio site performance score (lighthouse) were 46% and 6% on desktop and mobile respectively.
Frankly, I just have no idea where to start fixing after spending lots of time with MUI. Maybe I should be seriously thinking about rewriting all those styles using good old SCSS(?!)🤔
Brother use tailwind css you will be amazed by performance
But what about reinventing the wheel again and again for each project? Do not wanna spend too much time on this things that does not make too much difference when thinking about them in terms of business value and delivering something to the end user. It is just taking too much time to write, test, and let's not forget to maintain.
The way to use is such that whenever you need a component specific to a thing which is used very frequently such that a Accordion or something like that then only use that component from mui otherwise use only tailwind css. Thats it.
I'm disappointed that your investigation stops as soon as you remove the MUI components, and that without any further investigation, you decide that MUI is just a bad library and should be avoided by everyone.
Did you put any effort into figuring out why the component was killing rendering performance? I'm guessing you had some variable that was affecting the JSS object, which in turn was causing the dynamic stylesheets to be updated on every scroll event. Just a guess.
What I do is nowadays i dont use mui at every component. Using every component of mui would make application too slow its 100% right so instead i try to avoid to use mui as much as i can instead i use tailwind css as much as i can and only use mui special stylish components like textbox or sidebar or buttons which has ripple effect instead I dont use mui. I prefer tailwind css more.
everybody know mui has
Thanks for the kind words, and of course, there's a bit of click-baiting here, you're a 100% right, Material-UI is by no means a dead-end. That said, I think it's important to keep in mind that behind its very practical and polished components-library, it has performances issues. Some teams might consider it too big of an issue to go with it!
It is a dead-end for me, in the same way, Angular is a dead-end for me.. I made the conscious decision to ignore anything that says "material-UI" or "Angular" and focus my time wisely on other things; Using MUI is like learning a new language of "tags". I am happy with plain Html / jsx and CSS. (or another simpler framework like plain bootstrap)
Hmm, I am onboard with bootstrap but do not think we can leverage Bootstrap to develop and ship features and business values as fast as MUI with a fairly good enough acceptable UI/UX. Can we? Just looking for an answer about what others do if they do not use MUI.
I had a similar problem with Box etc, mostly based on the fact that the way MUI uses JSS causes vast numbers of things to be added as styles, constantly... In fact in my app "insertBefore" for a style was taking 60% of the rendering time, and goodness knows how much the rest was doing. I found a reasonably easy fix by replacing box with my own version and changing makeStyles from MUI to my own version that caches better. Performance is massively improved.
Material UI does have a github site and they promise to watch all issue submissions. Please create an issue.
Performance issues have been submitted before (I put the link of a PR in the article). They're working on it and hopefully sometime soon the lib will be solid
I'll start considering other options for future projects. More than 42 simple items in a list and you'll start noticing the performance issues.
If you are thinking about using infinite scroll with MUI forget about that, it's going to be horrible performance and supper laggy.
I've even tried to use some virtualization options, but they are laggy per se if the items have a little bit of more than 2 nodes in the inner layout.
Really unhappy with this 😪
What I do is nowadays i dont use mui at every component. Using every component of mui would make application too slow its 100% right so instead i try to avoid to use mui as much as i can instead i use tailwind css as much as i can and only use mui special stylish components like textbox or sidebar or buttons which has ripple effect instead I dont use mui. I prefer tailwind css more.