SWC is slow when importing directly from @mui/material

[omerman]

Hello,
I recently started working with mui v5.
I noticed that development will compile slowly if directly importing from @mui/material.
I was able to fix it using modularizeImports

It seems like an issue with SWC development server, I think it would be be best if SWC in dev either won't load all of @mui/material especially when a large chunk should be tree shaked. Or at least cache it once in a friendly way.

Please let me know what you think

[mikebuilds]

I think this is a bigger issue with MUI in general, and even worse when it's used with Typescript...

MUI have a guide on how to reduce the issue when using Babel
https://mui.com/material-ui/guides/minimizing-bundle-size/

Edit
For anyone stumbling across this comment, using modularizeImports works well without having to fallback to babel.

const nextConfig = {
  reactStrictMode: true,
  experimental: {
    modularizeImports: {
      "@mui/material": {
        transform: "@mui/material/{{member}}",
      },
      "@mui/icons-material": {
        transform: "@mui/icons-material/{{member}}",
      },
    },
  },
};

https://nextjs.org/docs/advanced-features/compiler#modularize-imports

[dimitur2204]

This improved compiled modules on load by 10,000 for me. Seems to work even though using an experimental flag to do that seems sloppy

[gentrith44belt]

@mikebuilds
This seems to work for components, but do you have any idea how to handle the utilities
E.g.
import { alpha } from "@mui/material";

[merri-dei]

Did you figure it out @gentrith44belt ? We also have the same problem with importing classes e.g. import { buttonClasses } from '@mui/material';.

[omerman]

@MJtH I'm familiar with the guide, I still think it should be possible not to load entire lib should be oossible and take less time, or caching it as I said before..
I dont think we should rely on the modulorized imports feature.. It seems very sloppy to tell the truth 🤷

[anthonyalayo]

@omerman the issue is with MUI and is not specific to Next.js. I just filed an RFC here: mui/material-ui#35840

[dimitur2204]

@omerman @MJtH
In [email protected] they made the modularizeImports non experimental and it seems to be working good! I hope it fixes it for all of you. This is how it looks in my next.config files:

  modularizeImports: {
    '@mui/material': {
      transform: '@mui/material/{{member}}',
    },
    '@mui/icons-material': {
      transform: '@mui/icons-material/{{member}}',
    },
  }

[anthonyalayo]

@dimitur2204 the transformation for @mui/material does not work for all imports.
They mentioned this in their PR for updating their docs: mui/material-ui#35457 (comment)

On top of that, @mui internally is using barrel files which results in thousands of modules being pulled in even if you do the transformation above, ie. using default path imports instead of named imports. modularizeImports will definitely bring down the module count from 10K+ to 2K+, but it is still heavy.

[dimitur2204]

@dimitur2204 the transformation for @mui/material does not work for all imports.

Yeah you are right. It doesn't go down from 2k, but still it is now bearable for me. Before that is wasn't.

They mentioned this in their PR for updating their docs: mui/material-ui#35457 (comment)

Good find on that one :)

[anthonyalayo]

@dimitur2204 hopefully if my RFC goes through we can get it down even less than that.

[xandert93]

Hi guys, very much a novice to this, but experiencing the issues documented here.

I did attempt the modularizeImports fix, but I still got 25k+ modules and compile time of 17s for a page. Any suggestions? Thank you!

[neil92]

For anyone else having this issue, I did some digging, and these are ideas that I've tried that optimize development building (not production building) with MUI and Next.js:

Option 1: Switch to Turbopack during npm run dev (warning: in beta)
I measured a 10-60% improvement in speed. I don't know why it's so variable.

1. Below are versions of MUI and Next.js that I'm using in package.json. When upgrading from MUI from 5.14 to 5.15 and Next.js from 13.5 to 14.0, I changed the boilerplate a bit. See this example and mui documentation.

    "@emotion/cache": "~11.11.0",
    "@emotion/react": "~11.11.4",
    "@emotion/styled": "~11.11.0",
    "@mui/icons-material": "~5.15.12",
    "@mui/material": "~5.15.12",
    "@mui/material-nextjs": "~5.15.11",
    "@mui/x-data-grid": "~6.19.6",
    "@mui/x-date-pickers": "~6.19.0",
    "next": "~14.0.4",

2. Next, add the --turbo flag in the package.json. For more information please see Next.js turbopack documentation.

Option 2: Lazy Load & Exclude selective libraries from initial webpack
I have a feeling there is a better way to do this, but this does work. I measured a ~60% improvement in speed, but I also didn't take a lot of measurements so this might also be highly variable.

1. I used BundleAnalyzer to analyze which packages were the largest.
2. I found that @mui/x-data-grid and xlsx were a large packages and only some of my page.tsx files required it. The rest of the example uses xlsx, but I'm sure you could apply it to @mui/x-data-grid.
3. Run npm uninstall xlsx in the root directory of your project.
4. In my src/libs folder I created a xlsx folder with an xlsx.js file with the following code:

/* eslint-disable @typescript-eslint/no-var-requires */
module.exports = require('./node_modules/xlsx');

5. In the xlsx folder, I created the following packages.json file:

{
  "name": "xlsx",
  "main": "xlsx.js",
  "dependencies": {
    "xlsx": "git+https://git.sheetjs.com/sheetjs/sheetjs.git#v0.19.3"
  }
}

6. Run npm install --save-dev after you've cd'd in to the xlsx folder.
7. In the button event where the user needs to parse the uploaded xlsx file, I lazy load the package. Please see Next.js documentation for a deeper explanation.

    const xlsx = (await import('@/libs/xlsx')).default;
    const { read, utils: xlsxUtils } = xlsx;
    const { files } = event.target;

I ended up using and merging Option 1 into my main branch. I also have a feeling you could combine the two options for even more speed.