Improve performance for larger storybooks

[trevordmiller]

First off, thanks for such a fantastic tool! Our company loves storybook and uses it in hundreds of projects.

Is your feature request related to a problem? Please describe.

Building a storybook with many stories currently leads to webpack performance warnings:

"asset size limit: The following asset(s) exceed the recommended size limit (244 KiB)"

Describe the solution you'd like

It would be great if storybook could implement the code splitting recommendations from the webpack team as shown in the error message attached below; under the hood, so all storybook users with default setups could upgrade and benefit from the performance improvements for "free" without extra config.

Describe alternatives you've considered

We have considered extending the default webpack config or using "full control" mode, but would prefer not to "eject" from the default storybook setup. We have also considered breaking up our component library but all the components work together well and it doesn't make sense to break them up from a consuming developer experience.

Are you able to assist bring the feature to reality?

I love contributing to open source! But probably don't have time for this currently unless someone can provide a simple implementation.

Additional context

Using default setup (we are not extending or using "full control" of the default webpack setup) of @storybook/react": "^5.0.3".

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[trevordmiller]

Our organization uses storybook for hundreds of projects and we see this performance warning on many of them.

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[trevordmiller]

@shilman I noticed you removed the inactive label - is this something that the storybook team plans to address? If this is an isolated problem with our organization, I understand and we can close this issue and try to improve things on our end. But it seems to me with how often we are seeing this warning across the many many storybooks we maintain that perhaps it is a problem for many other teams as well? Would it be possible to code split by default or something, per the link in the web pack warning?

[shilman]

@trevordmiller I think this is happening for most storybook users. Nobody is working on it right now, but I don't want performance issues to go stale and get swept under the rug so I "reactivated" it. If anybody wants to give it a go, they are welcome to. Hope at some point we can do a perf-oriented release and tackle this and a bunch of other related issues...

[ndelangen]

This related to #6806

With the current config.js is real hard to enable code-splitting in an automated fashion.

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[stale]

Hey there, it's me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one. Cheers and thanks for using Storybook!

[johnhunter]

We have the same issue for a different reason. Our Storybook is served from AWS lambda. We recently added IE11 support for our components in Storybook and the additional babel transpilation / polyfilling has pushed the vendor~main over the lambda maximum file size.

[shilman]

@johnhunter We'll do a perf sprint at some point soon and hopefully can get the bundle size down. In the meantime ... that sucks! @ndelangen any thoughts on options here?

[johnhunter]

Thanks @shilman, we're already appending to the Storybook webpack.config so its pretty straightforward to resolve using webpack-merge. The relevant parts of our webpack.config.js look like this:

const webpack = require('webpack');
const merge = require('webpack-merge');


const maxAssetSize = 1024 * 1024;

module.exports =  async ({ config, mode }) => {
  return merge(config, {
    //...

    optimization: {
      splitChunks: {
        chunks: 'all',
        minSize: 30 * 1024,
        maxSize: maxAssetSize,
      }
    },
    performance: {
      maxAssetSize: maxAssetSize
    }
  });
};

This can produce quite a few bundles on larger projects. If the concern is improve build speed there are a few splitChunk settings you can play with.

[kkomelin]

For those who's in search of how to adjust Storybook webpack config, see Custom Webpack Config section of the Storybook docs.

[EvanCarroll]

Why is this closed, I'm still getting this error..

[shilman]

@EvanCarroll have you tried storyStoreV7 in 6.4? https://storybook.js.org/blog/storybook-on-demand-architecture/