Design system performance tuning

[loliver]

Hi all,

We're having a discussion internally on how to handle splitting our themes to produce smaller css files. Presently with the default usage of createTheme on our system (6 themes, presently 25 or so components but growing) we are producing a 593kb css file.

One option we're looking at is using createTheme lower down our tokens tree, so instead of createTheme(themeObject) we'd be using createTheme(themeObject.components.componentName) and having separate themes created per component. This then comes with the issue of having to bootstrap consuming apps with every component they use to get theme classes applied.

Has anyone looked in to doing this sort of performance tuning on their design system? I know I read somewhere that the authors had thought about trying to attempt tree shaking the generated vars and/or classes with the Webpack plugin but it was very far in the too hard basket for now.

Cheers,
Oli

[mattcompiles]

Hey @loliver 👋

Not sure where you heard about tree shaking not working. That issue was specific to treat rather than vanilla-extract. You should be able to tree shake your themes as long as you're using the createThemeContract API. If you've done that, make sure each theme lives in its own file. Then normal CSS splitting techniques should apply.

[loliver]

Thanks for the link, will give it a read and see if I can gleam any nuggets of wisdom from it.

[loliver]

I added the vendor chunk split from here and it looks like Webpack sees the generated css as living under Vanilla Extract rather than the package we have our design tokens in, going to figure out how to rename our Style Dictionary exports and see if I can match purely by filename and see if that helps.

[loliver]

Got it working!

The following cache group splits all of the generated sheets based on debugId, would be cool if there was some way to put a more human readable identifier on there to split by when you generate the css with the plugin.

      vendor: {
        test: /[\\/]node_modules[\\/]/,
        name(module) {
          // get the name. E.g. node_modules/packageName/not/this/part.js
          // or node_modules/packageName
          const packageMatch = module.context.match(
            /[\\/]node_modules[\\/](.*?)([\\/]|$)/
          )
          const packageName =
            packageMatch.indexOf('@vanilla-extract') > -1
              ? packageMatch[1] + '.' + module.debugId
              : packageMatch[1]

          // npm package names are URL-safe, but some servers don't like @ symbols
          return `npm.${packageName.replace('@', '')}`
        },
        priority: 0
      }

That's given me the following files:

• npm.vanilla-extract.2920.css
• npm.vanilla-extract.2919.css
• npm.vanilla-extract.2612.css
• npm.vanilla-extract.2917.css
• npm.vanilla-extract.2921.css

[mattcompiles]

Nice work. Thanks for reporting your findings. I agree this definitely should be easier though. Will have a look into it.

[mattcompiles]

Had a look into this. Looks like best way to target CSS extracted via vanilla for code splitting is using the following.

cacheGroups: {
  myCss: {
    test: (m) => {
      if (m.type === 'css/mini-extract') {
		const cssResource = m.issuer.matchResource; // -> 'MyApp/src/style.css.ts.vanilla.css'
        // Replace with whatever check you want
        return /some-test/.test(cssResource)
      }
    },
  }
}