Storybook: Performance when the amount of stories and your code grows...

[ConneXNL]

I am currently trying to optimize my build speeds. When I have 2 stories that use a total of 3 sass files (for example a.scss, b.scss, c.scss) and some react code, I am looking at a build time of 1 - 1.4 seconds whenever I make a change to a.scss.

However, when I add more stories that each have their own react components and their own sass files, the build time of a change to a.scss suddenly becomes 2-3 seconds whereas no code of the added stories is actually re-using a.scss.

Why does adding standalone code slow down other standalone code?

In other words, how can I prevent react-storybook from becoming slower when I continue to add standalone components/styles?

[ndelangen]

678 We should investigate pre-bundling storybook and using the DLL plugin.

@serut has some experience with this. I'll do this eventually if no-one else makes a PR first.. 🙇

[serut]

We tried to setup storybook v3 with our app but it crashes, it just ignores the DLLReferencePlugin and try to compile the entire app, until a Not enough memory happens.
And I don't have time to investigate... :sob:
We have ~30k JS code with 70 internal modules (we use npm link)

[ConneXNL]

Since storybook manages the entries of webpack, wouldn't it be an idea to run each story on its own process?

I currently see no other way than uncommenting all stories I am not actively work on, just to keep the stuff I am working on, update quickly.

Storybook description says: "This allows you to develop UI components in isolation,". However it's really just the UI that is in isolation not the actual build process.

[ndelangen]

@ConneXNL That's the truth currently.

I'd be very interested to know how you'd approach to do this:

Since storybook manages the entries of webpack, wouldn't it be an idea to run each story on its own process?

[jchook]

Could this be accomplished by setting each story (or anthology of stories) as it's own webpack build target? The storybook nav could "hard" link to an individual HTML page for each story. Common libs could use the DllReferencePlugin or similar.

On a related note, Microsoft released Napa.js recently, which allows multithreading.

[danielduan]

Napa doesn't really have anything to do with performance enhancements in this case.

We really need to split up the webpack bundles.

1. parallel webpack - faster compile times on more powerful multithreaded cpus
2. smaller individual bundles - faster time to first paint in terms of download and browser parse time if optimized correctly

@jchook if you'd like to give it a try, we'd love a PR

[stale[bot]]

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 60 days. Thanks!

[stale[bot]]

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!

[AshCoolman]

What contributes to the "start up" time?

I have 170 storyshot tests:

• running all takes 90 seconds
• running _none_ takes 35 seconds

[dan-kez]

I am also concerned about performance. It would be great to parallelize storyshots if at all possible. It's currently the slowest part of my testing pipeline.

[priley86]

hi - i'd like to bump this issue. Are there any known workarounds? Our Storybook at Red Hat, Inc. has gone from a few simple stories to a massive pattern library...
https://rawgit.com/patternfly/patternfly-react/gh-pages/index.html

I've tried the 3.4-rc releases and it doesn't seem to help us out much ;-) ... and yes, Webpack4 is a welcome addition...
https://github.com/patternfly/patternfly-react/pull/269

Ideally we can start code splitting/chunking the stories individually for achieving ideal performance though. If anyone has experience w/ this and Storybook, please PM me. I'm guessing that future releases of Storybook will start to address this in various ways..

[ecrofeg]

Any news on this one?

[igor-dv]

Some of the performance improvements were already done by introducing a manager/preview build split + dlls of the UI. Did anyone check the latest version? Any before->after numbers will be much appreciated.