[Bug]: Slow initial page loading since upgrade to v7, taking more than one minute to download chunks

[fabien-thebaud-ariadnext]

Describe the bug

I'm using Storybook 7.0.6 for react-vite, and since migrating from 6.5 to 7.0.6, I'm experiencing a very slow page loading time. When I look at the network panel in Chrome, I see that the server is waiting for a long time (usually around 1 minute) before finally sending chunks that weight only a few kb.

Not sure if it's related, but I've also this warnings in the console:

To Reproduce

No response

System

Environment Info:

  System:
    OS: Linux 4.19 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (12) x64 Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz
  Binaries:
    Node: 18.14.1 - ~/.nvm/versions/node/v18.14.1/bin/node
    Yarn: 3.2.3 - /usr/bin/yarn
    npm: 9.3.1 - ~/.nvm/versions/node/v18.14.1/bin/npm
  Browsers:
    Chrome: 112.0.5615.121
    Firefox: 102.10.0esr

Additional context

I've just upgraded my project from 6.5 to 7. It's a yarn mono repo with only two packages (design system implementation in react/vite and storybook).

And here's the main.ts file:

import type { StorybookConfig } from '@storybook/react-vite';
const config: StorybookConfig = {
  stories: [
    '../src/stories/**/*.stories.mdx',
    '../src/stories/**/*.stories.tsx',
  ],
  staticDirs: ['../public'],
  addons: [
    '@storybook/addon-essentials',
    '@storybook/addon-a11y',
  ],
  core: {
    builder: '@storybook/builder-vite',
    disableTelemetry: true, 
  },
  framework: {
    name: '@storybook/react-vite',
    options: {},
  },
  docs: {
    autodocs: true,
  },
};
export default config;

And my dependencies:

  "dependencies": {
    "@emotion/react": "11.10.6",
    "@emotion/styled": "11.10.6",
    "@company/design-system-react": "0.0.3-rc1",
    "@mui/material": "5.11.12",
    "react": "18.2.0",
    "react-dom": "18.2.0"
  },
"devDependencies": {
    "@babel/core": "7.21.0",
    "@mdx-js/react": "2.3.0",
    "@storybook/addon-a11y": "7.0.6",
    "@storybook/addon-actions": "7.0.6",
    "@storybook/addon-docs": "7.0.6",
    "@storybook/addon-essentials": "7.0.6",
    "@storybook/addon-interactions": "7.0.6",
    "@storybook/addon-viewport": "7.0.6",
    "@storybook/addons": "7.0.6",
    "@storybook/builder-vite": "^7.0.6",
    "@storybook/manager-api": "7.0.6",
    "@storybook/preview-api": "7.0.6",
    "@storybook/react": "7.0.6",
    "@storybook/react-vite": "7.0.6",
    "@storybook/testing-library": "0.1.0",
    "@storybook/theming": "7.0.6",
    "@types/react": "18.0.28",
    "@types/react-dom": "18.0.11",
    "@vitejs/plugin-react": "3.1.0",
    "babel-loader": "8.3.0",
    "eslint-plugin-storybook": "0.6.11",
    "storybook": "7.0.6",
    "typescript": "4.9.5",
    "vite": "4.1.3"
  }

[dkrefta]

Same here, I'm using now the feature flag

 features: {
    storyStoreV7: false, // 👈 Opt out of on-demand story loading
  },

but only if you want to stay with the slower version 7, but you can also downgrade as well 😄

[shilman]

@dkrefta to confrm, you're seeing the same perf problem in v7, but the problem goes away when you opt-out of on-demand story loading?

Do either of you a have a reproduction repo you can share? If not, can you create one? Go to https://storybook.new or see repro docs. Thank you! 🙏

[dkrefta]

Hi @shilman, all good? After using the opt-out of on-demand seems more stable but is still, a pain to load. Sure, I will try to create a repo at the end of the day ( after work ) with the same config that I use. Thanks

[fabien-thebaud-ariadnext]

Hi @shilman I tested the "opt-out of on-demand story loading" config, it didn't improve loading time in my case. I wasn't able to create a repo with the same exact issue, this is the closest I could get: https://stackblitz.com/edit/github-qkhmgm The initial page loading after running yarn storybook is not as slow as what I have on my machine (~30 seconds compared to 1 to 2 minutes) but it's still pretty slow.

[aushwin]

Same issue with version 7. Vite builds in 12 seconds. But the initial load for the stories is around 30-40 seconds @shilman

[jaredjbarnes]

Has there been any progress on this? I have the same problem on 7.0.9

[littlefengers]

Same thing, I removed almost everything from our SB, left 1 component, but it still has at least a 15 second wait to see the single component.

The static SB on Chromatic opens instantly though.

[kaiyoma]

I am also seeing pretty awful build/load times in Storybook 7. I did an upgrade from Storybook 6, where I also upgraded from webpack 4 to 5 at the same time, and the experience is pretty horrific:

Storybook 6: 1.5 - 2 minutes Storybook 7: builds for ~10 minutes, uses 8 GB of memory, and crashes

I've also tried switching to Vite, and Storybook + Vite is so much slower than building my entire UI:

Building full UI (Vite): ~4 minutes Building Storybook: ~10 minutes

I've had nothing but trouble trying to migrate to Storybook 7. The command-line tool for auto-migration doesn't work, and every config I've tried is just really slow. Storybook 7 is basically unusable.

[shilman]

@kaiyoma do you have any reproduction we can look at? i can't imagine what is taking so long. our build benchmarks and tests on a variety of public projects are fast, especially for vite projects. we've seen some minor slowdowns moving from webpack4 to webpack5, but overall things have gotten faster in storybook7. i'd love to get to the bottom of it.

also i'm sorry to hear you've been having trouble with migrations. again, we've tested on a wide variety of projects in the leadup to release and most of the user feedback has been how smooth the upgrade has been. if you file an issue describing the problem i'd be happy to take a look.

[kaiyoma]

@shilman I'd really love to give a repro, but I'm not sure how to go about that, since this is a really massive enterprise project and I can't share any of the code, beyond our Storybook configs.

Is there some way to get more information about what Storybook is doing while it's building? Even when I enable verbose logging for builds, there still isn't any helpful output. And when I run the dev server, there's no logging at all about what's taking so long. I just see Storybook pausing for long periods of time seemingly without making any progress, though I can see Node chugging away in my Task Manager, usually taking up an entire CPU core.

[shilman]

For anybody who is having perf issues with 7.0 please try the following workarounds:

1. Upgrading to 7.1, either by running npx storybook@next upgrade --prerelease or by simply editing your package.json. 7.1 contains this perf improvement https://github.com/storybookjs/storybook/pull/23018, which we don't plan to patch back.

2. Turning off Typescript docgen in your .storybook/main.js:

export default {
  // etc.
  typescript: {
    reactDocgen: false,
  },
}

Details

I took a look at @fabien-thebaud-ariadnext 's stackblitz reproduction above and was seeing preview dev times of ~15s. I had another, similarly empty, vite project that was giving me preview dev times of ~2s which is what I'd expect.

I started applying the minor differences from the second project to the first, including stuff like Vite version, Storybook version, tsconfig, etc. The major difference I saw was that when I upgraded to 7.1, I could get the preview dev time down to 4s -- still almost double what I'd expect, but back in the ballpark. Then I tried disabling docgen and got the preview dev time down to .8s. I downgraded to 7.0 and the preview dev time went up to 2s.

	docgen	no docgen
7.0.23	15s	2s
7.1.0-alpha.39	4s	.8s

For anybody who's interested, on my local machine the times were all a bit faster:

	docgen	no docgen
7.0.23	4s	.8s
7.1.0-alpha.39	2s	.6s

[shilman]

@kaiyoma AFAIK there are a few contributors the startup time:

1. Storybook-specific overhead, which should be mostly constant at 0-2s depending on your machine.
2. The bundling itself, as performed by Webpack or Vite. This is kind of a black box to us but in general Vite is a constant 0-2s because it's doing everything on-demand.
3. Loading typescript to analyze your components, which can take 1-2s for a small project. This can be disabled by adding the following to your main.js:

export default {
  // etc.
  typescript: {
    reactDocgen: false,
  },
}

On the last point, I also tried disabling docgen in @fabien-thebaud-ariadnext 's project and saw the preview build time on my local machine drop from 2s to .6s. We've been aware of this bottleneck for awhile and have some short term workarounds planned. Long term, we plan to revamp the way we handle docgen in Storybook.

NOTE: I've updated the perf summary in the previous comment with the docgen trick, which was also gave a big improvement

[kaiyoma]

Okay cool, this is very helpful! I'm in the middle of upgrading our project to ESM and Vite and Node 18, so I might put Storybook on the back burner until that's done. But all this info is very relevant, and I'll definitely try a 7.1 version soon to see if it helps.

[fabien-thebaud-ariadnext]

@shilman As recommended, I added typescript: { reactDocgen: false }, to my configuration and it did the trick, page loading time is now down from ~90 seconds to ~1 second. Thank you for your help!

[shilman]

@fabien-thebaud-ariadnext that's amazing. Is there any chance we can look at your project? I would expect a perf gain but not one of that magnitude. We're planning to rearchitect things and understanding some pathological cases like this could help inform that work

[fabien-thebaud-ariadnext]

It's company code so I'm not allowed to share it. Our design system is a yarn monorepo with two separate packages: the components library (React with Emotion for styling) and the Storybook. We do have a lot of small components like icons (~60) and illustrations (~60) that we display in galleries. Other than that we only have about 10 "regular" components and their corresponding stories and a handful of documentation pages in mdx.

[danielHin]

In our storybook setup we also facing this issue. We are using @storybook/angular

Our BackstopJS visual regression tests now failing due to the loading time for each story takes long.

With 7.1-alpha and disabling reactDocgen less tests failing, but still the loading time for the stories are the issue. VRT Report showing the storybook loading spinner in all cases the tests failed.

Any recommendations how to solve this?

[littlefengers]

I fixed our slow build issue when I changed how I was merging our MUI theme objects.

[kaiyoma]

@shilman I finished our team's ESM migration and tried Storybook 7 again, using the latest 7.1 alpha. For the most part, it's still pretty terrible and very unusable. I've even configured Storybook to have one (1!) story and it's still behaving badly.

I used npx storybook init to make a new config. It correctly detected my Vite config and set up the correct scaffolding. The first time I ran Storybook, it took 3+ minutes to start:

╭─────────────────────────────────────────────────────╮
│                                                     │
│   Storybook 7.1.0-alpha.41 for react-vite started   │
│   856 ms for manager and 3.37 min for preview       │
│                                                     │
│    Local:            http://localhost:9001/         │
│    On your network:  http://10.95.65.1:9001/        │
│                                                     │
╰─────────────────────────────────────────────────────╯

I then disabled reactDocgen as per the earlier comments and things got much better:

╭─────────────────────────────────────────────────────╮
│                                                     │
│   Storybook 7.1.0-alpha.41 for react-vite started   │
│   1.34 s for manager and 6.69 s for preview         │
│                                                     │
│    Local:            http://localhost:9001/         │
│    On your network:  http://10.95.65.1:9001/        │
│                                                     │
╰─────────────────────────────────────────────────────╯

Great, I'll take that win. However, that's the end of the good news. When I try to actually load the UI in a browser, here's what happens:

• I see a blank white screen for 3.5 minutes. The only indication anything is happening is the small spinner in the browser tab. I can see in my Task Manager that Node is using at least one core (sometimes two) during this time
• At this point, the Storybook UI shows up, as does my one story, but the component itself doesn't load. Instead, there's a spinner rendered in the page
• After another 6 minutes (10 minutes total now), the spinner in the browser tab stops. The spinner on the page keeps going, and the component is still not rendered. Node continues to take up one core. There are no messages of any kind on the command line or in the browser console

Here's what the network tab of devtools looks like. 5+ minutes for DOM content to load!

And after all this, I still have nothing to show for it:

[kaiyoma]

As a follow-up to my last comment, I can report that storybook build works just fine and completes in a reasonable amount of time (~3 minutes). I no longer have docs since I have to disable reactDocgen, but at least I have something working. It seems the performance issues affect the dev server only.

[menasheh]

this is a major issue, starting to question usage of storybook

[kaiyoma]

Here's another (positive!) update. Over the last week, I've been upgrading a lot of our project's dependencies and also fixing our setup code for monaco-editor (which was causing issues in our UI). I'm not sure exactly what did it, but something has also made the Storybook dev server actually work!

Here's what the workflow is like for me now. The initial startup is pretty fast:

╭─────────────────────────────────────────────────────╮
│                                                     │
│   Storybook 7.1.0-alpha.41 for react-vite started   │
│   5.31 s for manager and 947 ms for preview         │
│                                                     │
│    Local:            http://localhost:9001/         │
│    On your network:  http://10.95.65.1:9001/        │
│                                                     │
╰─────────────────────────────────────────────────────╯

When I open that URL in the browser, I see nothing for about 20 seconds, and then the skeleton of the Storybook UI shows up, but only the left and top bars. The controls panel is missing and there's a spinner in the center of the page. The page stays like this while Node and esbuild churn pretty heavily in the background. After about 3 minutes, the rest of the Storybook UI loads, the components load, and then I can actually use Storybook. 🎉

This is a huge improvement over a completely broken Storybook experience, but something is maybe still not quite right here. We can load our full app (through Vite) in about a minute, so it makes no sense to me that Storybook - a small subset of the UI - would take three times as long.

But here is a VERY interesting data point: my coworkers on macOS are not seeing these performance issues (only me on Windows 11), which indicates that perhaps there's some code inside Storybook that isn't cross-platform. 🤔

[menasheh]

Do none of the devs use windows? What's involved in debugging this? I might try to help if someone could point me in the right direction?

[chocnut]

I disabled reactDocgen; it improves the loading significantly (see screenshot). What's with the reactDocgen? I'm using sb v7.1.0

[menasheh]

can we get some eyeballs here?

[shilman]

Can you try out the following canary in your project and let me know whether it resolves any of your issues (or generates new ones)? We're looking to switch the default docgen from react-docgen-typescript to react-docgen, which is much faster and may also fix some long-standing bugs. Many thanks!

Note that the change is currently only for Vite projects. Instructions in the "how to test" section: 👉 https://github.com/storybookjs/storybook/pull/23825

[volochiy-s]

Hi people; Not sure if my input would help, but when running from macos, I don't have this issue at all, everything loads super-fast (I use builder-vite). But when I load it from a docker container (node:bookworm and standard playwright image), initial load goes up to around 40 secs. During initial load it also doesn't seem to apply my custom plugin to add cache-control header (I'm using it for tests) – all files are loaded with "no-cache", default value; after it loads once, if I refresh the page, everything works fine and cache headers are in place.

[jb-asi]

Can second @volochiy-s on the 40-second initial load time. I am also using macOS; but I experience the same issues outside a dev. container.

[github-actions[bot]]

Hi there! Thank you for opening this issue, but it has been marked as stale because we need more information to move forward. Could you please provide us with the requested reproduction or additional information that could help us better understand the problem? We'd love to resolve this issue, but we can't do it without your help!

[github-actions[bot]]

I'm afraid we need to close this issue for now, since we can't take any action without the requested reproduction or additional information. But please don't hesitate to open a new issue if the problem persists – we're always happy to help. Thanks so much for your understanding.

[lems3]

Hi,

I just had this issue with the latest version (7.6.0).

When installing in an empty project, in HTML, we don,t have the issue. But when trying to add Storybook on top of our Drupal project, we start seeing this issue.

I just wanted to add the info out there about it. We still have no idea how to fix it, but it's clearly linked to our project structure.

[menasheh]

I thought I had this issue, but what actually happened was tailwind was processing all node_modules. Quick and snappy once I took out './**/*/*.{js,jsx,ts,tsx}' from the tailwindconfig

[lems3]

Hi,

I just had this issue with the latest version (7.6.0).

When installing in an empty project, in HTML, we don,t have the issue. But when trying to add Storybook on top of our Drupal project, we start seeing this issue.

I just wanted to add the info out there about it. We still have no idea how to fix it, but it's clearly linked to our project structure.

I just figured out that storybook scans the whole repository, even when we set stories to specific folders... Why ?

[valentinpalkovic]

@lems3 Can you share your findings and let us know where Storybook exactly scans the whole repository?

[lems3]

@valentinpalkovic It's related to Vite. We switched from html-vite to html-webpack5 as a framework, and the issue stopped showing up.

As Vite wasn't a requirement for us and we don't have expertise on it, we're going to stick with Webpack for now.

[frle10]

I need to chime in on this issue. :)

I'm using Storybook 8.2.7 with Vite builder in a monorepo setup with pnpm workspaces. My Storybook app is in /apps/storybook, and I have an internal package in packages/my-package. The storybook app depends on my internal package through package.json like this:

"my-package": "workspace:*"

I've been fighting excruciatingly slow build times and dev server startup for 2 weeks now and couldn't figure out the problem. Turns out adding this:

typescript: {
  reactDocgen: false,
},

to my main.ts fixed everything. Somehow default doc generation is extremely slow, and my internal library contains maybe 50ish components. This is a problem even in Storybook 8.2.7.

[The-Poe]

In my nx mono repo case, I use storybook@7.2.0 and @storybook/react-vite as storybook framework, which use @joshwooding/vite-plugin-react-docgen-typescript to handle typescript docGen.

It turns out that, by default, it would parse the whole mono repo(**/**.tsx) and create a FAT ts program for later parsing comments to componentsDoc while browser loading the page.

So, to restrict the typescript parse scope to the only lib that my storybook was for, adding the below code to .storybook/main.ts worked.

  typescript: {
    //...
    reactDocgen: 'react-docgen-typescript',
    reactDocgenTypescriptOptions: {
      include: ['yourComponentLib/**/*.tsx'],
    },
    //...
  },

This reduces my storybook init time from 1.8 mins to 20 s.

[yhan0704]

@kaiyoma AFAIK there are a few contributors the startup time:

1. Storybook-specific overhead, which should be mostly constant at 0-2s depending on your machine.
2. The bundling itself, as performed by Webpack or Vite. This is kind of a black box to us but in general Vite is a constant 0-2s because it's doing everything on-demand.
3. Loading typescript to analyze your components, which can take 1-2s for a small project. This can be disabled by adding the following to your main.js:

export default {
  // etc.
  typescript: {
    reactDocgen: false,
  },
}

On the last point, I also tried disabling docgen in @fabien-thebaud-ariadnext 's project and saw the preview build time on my local machine drop from 2s to .6s. We've been aware of this bottleneck for awhile and have some short term workarounds planned. Long term, we plan to revamp the way we handle docgen in Storybook.

NOTE: I've updated the perf summary in the previous comment with the docgen trick, which was also gave a big improvement

That is what I needed! Thank you