Not Reactjs, not a framework or the servers, or API , nor the internet is the reason behind it.
The story begins way back exactly one year ago. When I was covering stories on react and react native apps optimisation.
I have covered more than 15 ways in a single story on how to improve react app performance.
This is the beauty of software development it’s never stagnant or monotonous. Because today even after one year, I read a new story that tells the impact of bundle size on application performance and a mind-boggling story to understand why websites can be slow.
For one year I have covered so many stories on react application optimisation but today I have got a new perspective on seeing react applications.
Bird EYE perspective — Find the root cause of problems
See it’s not rocket science but let me explain with the story -
- We first create an application in Reactjs
- Then we use Framework and packages and add code
If our senior developer requests us to improve our React app performance, we always proceed in the so-called universal direction as explained
- Check the image size
- Check the internet
- Check the API
- Check the code structure architecture or size of the repository
But what if I told you to follow Bottom to Top approach instead?
Let's start with the question —
- The server sends the app bundle or response such as HTML to the browser
- Followed by loading of CSS
- Lastly, images are loaded or being lazy loaded
Cool, so, what really can be the reason for the entire website being slow?
Ofcourse, the things which will take time, isn't it?
Understand that images and large-size files are not the culprits every time.
Understand the core reason how parsing, compiling and execution of the bundle can be improved significantly. That will cover up almost most of the reasons why applications are slow.
If not then it’s time to move up in the root causes list. Checking the image optimisation, re-rendering, sharding and API response things in order.
Imagine if I send the browser 100Kb of app bundle whereas I send 25kb of app bundle, what do you think which one will take time?
Out of curiosity, the above npm package will help you to analyze bundle size by showing the image locally as shown below.
The smaller the bundle size the less load will be on the browser CPU, and memory and the faster it will run the website. Simple, not rocket science.
When I understand this I got one more question.
Why can’t we move back to writing HTML and CSS in the front?
The answer I got is NO, it’s not correct and useful every time in every case to use mostly HTML and CSS in frontend.
We got a new concept called the island model. Astro is the new Multi-page application framework that deals with serving HTML files only to the browser.
But Astro can’t be used in every product it really depends on the product type and if you want to know the reason below is the story for it.
Astro can’t be used for applications where heavy states are to be managed, animations, e-commerce and dynamic websites.
Not a switch, I recommend.
Improving bundle size
Let’s move back to bundle size impact.
- Look for code splitting, only load the required one and try to reuse
- Minify the bundle size using loaders or webpack plugins
- Remove the unused dependencies
- Lazy load the dependencies, load only when asked
- Caching the output
Still improving bundle size will not be an easy task.
You can check the next.js bundle size using the below command.
yarn run build
It will give bundle size output and you can try making the changes and measure the bundle size improvements.
The most efficient way is to check the entire app bundle in the browser inspect tab in the performance section. You can google the way it’s not too hard to understand so not covering it much in this story.
Try introducing changes such as
- Code splitting
- Caching using React Query or Service Worker
- Minify the final output size using loaders
- You can keep measuring the bundle size locally
- Followed by checking the final performance in the inspect tab.
The performance measured by the google lighthouse will also give a percentage output of the performance.
Understand this also, sometimes apps are fast even though the bundle size is OKAY. In that case -
- Either the CPU of the browser is really slow, it usually happens in the old devices
- Or the network connectivity is low
Nothing more than that nothing less than that.
- Which phone app is tested, if the phone is slow then check the app on the new phone.
- Make sure internet connectivity is good
- Even if the app is slow in all the phones with good internet connectivity then proceed with bundle size.
- If bundle size is not an issue check the image size, and other tantrums such as re-rendering, HTML parsing, fonts and CSS and so on.
With the bottom-to-top approach, we have a new way of addressing the entire application performance issues.
I am hoping to see more tools in the future helping in following this approach because nobody is talking about it.
I am able to find the root cause because I read this story written by the Engineering Manager at Google
I am reading more about bundle size for app performance and the root cause behind our apps being really slow.
Because I am done adding image optimisation, react rendering issues and the usual way of optimising applications. It’s time to go beyond it finding the root cause and play with it.
If you find more readings around it please do share I would love to read.
Until next time, have a good day.