As with any performance improvements, it’s important to have the tooling to evaluate if any changes provide value.
browser devtools with network throttling
Decide what’s the lowest network speed that need to work relatively fast. (I have picked fast 3G)
Build the application as for production environment
npm run build and then
serve -s build -l 3002 in CRA or open the deployed app.
Throttle the network and force load all resources without using cache CMD+Shift+R. If the application loads relatively fast, there might not be the need to split the code at all.
- TinyMCE used in only one page
- Lodash being included 3 times (lodash.js lodash.min.js lodash-es)
- React-Player used only in a few pages
- Translations (en and pl)
- Constants contained some not needed data
Tackle the biggest issues and evaluate the results (step 4)
- Use React.lazy and Suspense to lazy load parts of the application
- When doing manual webpack code splitting remember about defining shared dependencies
- Check for babel transforms eg. babel-plugin-lodash
- Some modules can be aliased
lodash: 'lodash-es',so they are included only once.
- Some packages offer optimization themselves eg.
import ReactPlayer from 'react-player/lazy'lazy loading players for different video hostings.
- Load translation files lazily using eg. i18next-xhr-backend
Details depend on every specific case.
If tackling the biggest elements is not enough, continue splitting the app per route or group of routes accessible for different users. eg. split admin routes, regular user routes and not logged in guests routes.
Unless your application is gigantic, following all steps should be enough. In my case handling initial issues found in step 4 was enough.Tweet