production build is too big - reactjs

My src folder total size is 2.6 MB and the production build is 2.7 MB. It is taking too much time to load in the browser. I am generating a build using npm run build. I have started my project with create-react-app command. How to reduce the bundle size? Please help me.
I followed this link https://codeburst.io/how-i-cut-my-react-javascript-bundle-size-in-half-with-three-lines-of-code-fe7798ecbd3f as well but the result is same.

To increase loading performance of your app, another pointer could be using code splitting feature from webpack.
Or you can even consider Server-Side Rendering with react-based frameworks like nextjs or gatsby

You can increase your application perforce there are some methods to follow
We have to use React Js latest version or above 16
We have to Remove unwanted imports in the components
Using shouldComponentUpdate()we have to control the rendering method, if its necessary then only render the component
Re Usable of components
Using Lazy Loading Concept we can increase the performance

Related

Which is better way to create a react app?

I have been working with reactjs from last 7-8 months, I have always used create-react-app to get started with any react application. but, by exploring more ways to get started with a react application I came to know there is a thing called vite which is I guess is providing a faster and leaner development experience for modern web projects.
I used it once till now, not in production yet as I am not very confident about it. So, which is a better way to get a simple template for react app. which is also better in production environment. Does using any one affects in production?
CRA uses webpack to handle its core functionalities. In the development webpack repeats the bundling process every time there is a change in the code. As a result, when your source code grows larger, everything becomes sluggish. The time it takes to serve a dev server and build your projects increases significantly.
Vite only needs to pre-bundle your dependencies using esbuild the first time you start development before it begins to serve your app.
Vite doesn’t need to bundle the entire app or transpile the modules and code before starting a dev server; transpiling is done on-demand, thus making it significantly faster than CRA.
https://blog.logrocket.com/vite-3-vs-create-react-app-comparison-migration-guide/#:~:text=Vite%20and%20CRA%20are%20not,and%20which%20modules%20are%20supported.

How can I know if everything actually optimized?

I built a simple react app using Gatsby. All that the app does create a calender and show it to the screen. When I checked the performance of the app using LightHouse, I got 90% on desktop perf and 31% on mobile perf.
This is a bare bone site. I thought Gatsby would convert my react code to HTML and that is supposed to load blazing fast...
So I checked the html of the page, </script></head><body><div id="___gatsby"></div><script src="/polyfill.js" nomodule=""></script><script src="/commons.js"></script></body></html>
It looks like the whole page just runs from JS script; nothing is actually converted to HTML.
What did I do wrong? I ran the site using npm run develop?
When you run gatsby develop all page requests are served the barebones HTML shell that loads a development-targeted version of Gatsby that will render everything client-side only and integrates hot-module reloading1. No minification is performed on your source files this way, React is in development mode, and there are streaming connections opened to the dev server to listen for changes.
When you run gatsby build, Gatsby will create static HTML file entry points to each of your pages that contain the pre-rendered page in an optimized format. Each of your plugins should also produce optimized output, such as inlining critical CSS or generating minified CSS classnames. JavaScript will be tree-shaken, minified, and bundled in chunks by webpack, and React will be loaded in production mode.
If you'd like to test the performance of your Gatsby site before deploying, you can get a rough indicator by running gatsby build and then gatsby serve, then running your Lighthouse audit on that page. Keep in mind that this won't test the network or server performance of your live site, so it isn't going to match precisely (but should at least catch content related issues).
1 This is actually set to change starting with v2.3.0, which enables SSR during development.

Using EmojiMart in production in reactjs appliacation

I'm trying to implement an emoji picker with a text input, I came across a package called Emojimart it was really good and working effectively, but running it in production makes my bundle size too big,
so I'm wondering if there is anyone who used it in production and if there is any tips on how to make it production ready?
Or: if there is any other alternatives.
Note: Reproducing what I have will take only 2 steps
Create react app with create-react-app
Install emojimart
Then check the bundle size and performance of the app, you will notice the difference.
There was a discussion about that in the Emoji Mart project: https://github.com/missive/emoji-mart/issues/156 - unfortunately I don't see a solution that wouldn't require you to eject the app or use react-app-rewired.
Since you're using React, maybe you could give emoji-picker-react a try. The bundle size in a new project is around 120 KB (80 KB gzipped).

Webpack builds react app with possibility to load vendor libs from node_modules on runtime

We have a lot of React applications in our portal, there area lot of cases that there a a lot of them on same page but because of the size of those bundles the load time is very slow.
All application are using the classic combo react, redux, ramda...
So there is a lot of duplicity in each bundle, I am looking for a way to have those shared resources aside and cached by browser.
Is there a way to setup webpack build to dynamically load those common libraries from some url instead of bundling hem to the final bundle?
I use webpack 4, I have already tried SplitChunksPlugin, that is generating vendor chunk fine but it looks like that generated vendor chunk can be used just for one particular app
Thanks for help
After the research I find out that there is a dll plugin that is doing exactly what I wanted: https://webpack.js.org/plugins/dll-plugin/

Does a React application HAVE to run on its own server process?

I come from a background in Angular, but I wanted to start learning React. I want to make a React front-end for a nodejs Express web service.
In Angular, I could simply build the source code into a static folder with a standard index.html, and it can be deployed on any web server. With React however, every tutorial I see is about running React in its own server using create-react-app and npm start.
I know you can also just use script tags to import the React framework in a static page, but then you can't use JSX syntax, and I would like to. Is it possible to simply build a React project into a static folder with an index.html that can be deployed on any web server?
Yep, you can do what you're describing. If you want to use JSX syntax, you'll need Babel, which transpiles it into standard JavaScript.
You can avoid the complexities of setting it up by using create-react-app to create the app, then running npm build instead of npm start. This will compile everything into a build directory, complete with index.html.
CRA uses its server for development purposes. You don't need CRA for using React of course. But, as your app getting bigger and bigger you will need some more extra tools. For example you want to see your code instantly without refreshing your browser. Here comes the dev server and hot reloading.
CRA uses Webpack behind the scenes. It is a great tool for bundling (obviously) all your files (including css), minifying, uglifying, optimizing your code etc.
For simple code or testing purposes using one file and attaching React and Babel to your file could be enough but for real apps you will need more. Either you will use something like Webpack on your own or you will use CRA and let it do all the extra stuff for you.

Resources