Home > Net >  What is a reasonable size / order of magnitude for code splitting
What is a reasonable size / order of magnitude for code splitting

Time:05-27

We are working no a large React code base and want to split up the application into smaller chunks using react-loadable.

My team mates are currently trying to make each and every component lazy-loadable. I do not think this is the right approach, as lazy loading also comes with some overhead, so I would prefer lazy loading larger building blocks like whole pages.

I have found lots of content on how to use lazy loading, however I have not found much information when comes to whether it makes sense to use lazy loading.

How should one approach lazy loading in React (in general / as a start)? What is good measure to determine whether lazy loading makes sense for a component?

CodePudding user response:

That's a interesting question and as tdelaney said, this is very opinion based and it depends on the kind of application your team is working on.

Why not load everything in a lazy manner?

I wondered why not to lazy load everything.

Imho, loading every component in a lazy way is not so advantageous. Your application may result boring to user by showing too many spinners/loader animations.

Furthemore:

  • the complexity of writing and maintaining the code increases significantly. That's because for each component you have to manage both the "loading" (see Suspense in the below snippet) and the "loaded" status and appearance.
  • your performance may be affected by many browser re-paintings of big areas.

How I'd approach to this

In my case, I started examining the scenarios from an user point of view in order to improve the user experience and reduce the "freezing" times.

For instance, I wanted the users of my web application (which is embedded in retail kiosks but also available for mobile devices), to quickly show a SplashScreen and then load each chunk separately. After showing a SplashScreen, my intent was to show the App component with just "ui skeletons" of the child components while these (children of App component) were loading their nested child. That made my application looking modern and very fast. Then, many components for not visible/nested pages could be shown after user interactions, when clicking buttons, opening modals etc., etc... In this way it gained several seconds.

To sum up:

  • render SplashScreen
  • lazy load and render Application
    • render skeletons of visible components
    • lazy load and render visible components
      • render children

The following is an index file I am currently using to implement it in a quite large project:

import React,{ lazy, Suspense, FC } from 'react';
import { createRoot } from 'react-dom/client';

import SplashScreen from "./SplashScreen";
const App = lazy(() => import('./App'));

const Application: FC = () => {
  console.log("Rendering <Application/>");

  return (<Suspense fallback={<SplashScreen/>}><App /></Suspense>);
}

const appRoot = createRoot(document.getElementById('app-container'));
appRoot.render(<Application />);

See the Code-Splitting section React.lazy and Critical rendering path for details.

I hope this has been helpful to you.

  • Related