Upgrade Storybook, enable Lazy Compilation

[IanVS]

As mentioned in #11314, I'm in the process of writing a blog post comparing the performance of various storybook features. I don't want to spoil anything, but I think this is the change which makes the most sense for this particular project, because it is not as invasive or disruptive as swapping over to Vite, and it still has significant startup performance improvements.

Changelog

New

• Enables Lazy Compilation and Code Splitting in Storybook.

Changed

• Updated Storybook from 6.4.9 to 6.5.0-beta.1

Testing / Reviewing

Start the storybook, compare startup time to previous, browse around to verify nothing is broken. Build the production storybook, and also investigate. I did not see any changes, but am not as experienced in this project as the maintainers, obviously.

You should see that initial startup time is much faster, at a slight cost of increased time to download additional code-split packages while navigating to different stories.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	88458b2
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/627423aefd6eee000896cc60
😎 Deploy Preview	https://deploy-preview-11315--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-components-react ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	aba9c98
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/626b4ff51d550b000917a923
😎 Deploy Preview	https://deploy-preview-11315--carbon-components-react.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-components-react ready!

Name	Link
🔨 Latest commit	88458b2
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/627423ae9bb3df0008930067
😎 Deploy Preview	https://deploy-preview-11315--carbon-components-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[joshblack]

Thanks for doing this @IanVS! 🙏 Just pushed up a small commit after running yarn dedupe, will definitely check this out!

[joshblack]

One thing I noticed when trying this PR out and comparing it to what is in main is that the startup time seems to be approximately the same (~40-45s). The only difference I noticed when viewing stories is that lazy compilation will compile those pages on-the-fly whereas on main it will have already built them so there is no loading.

Based on your experience, is there a better way we should be splitting up our storybook to take advantage of these new features? Or am I misunderstanding where the benefits come from for these updates? 👀

Thanks again for putting this together! Really appreciate it 🙏

[IanVS]

Hi @joshblack, here are the results I got on my 2019 Intel MBP:

But I'm realizing now that I need to re-run the Lazy numbers taking into account a change made in the other pr, here:

bf24128 (#11316)

Without that change, code-splitting is less effective. I just ran one more test including that commit, and I got a cold startup time-to-first-render of 33 seconds (half of current webpack 5 baseline), and a warm startup of 11 seconds (~ 1/3 of baseline).

So, my suggestion would be to merge #11316 first (I can clean it up if you need), and then rebase this PR on top.

[IanVS]

I can clean up the conflicts. Here are the final results in the Storybook blog post, by the way. https://storybook.js.org/blog/storybook-performance-from-webpack-to-vite/

[IanVS]

I'm not sure why there were failing prettier and eslint issues, but I fixed them in a few separate commits, in case they need to be taken back out. I think this should be ready for review / consideration.

[joshblack]

Thanks @IanVS! When looking at VRT, it seems like we're hitting some loading states in this mode. Would you happen to know of a way we could wait for storybook to resolve before we snapshot the story? Totally understand if not, just wanted to check to see 👀

[IanVS]

Storybook adds .sb-preparing-story to the body (or a direct child of the body, can't remember) of the iframe while it's loading. I've used waitForSelector with percy configs before, but I haven't looked to see how exactly you're configuring percy right now and whether or not you'd be able to use that. But, those are the pieces I'd start with exploring, at least.

[IanVS]

@joshblack are you seeing better performance on this branch now?

[joshblack]

@IanVS yes! Much faster start-up time on my machine (around 25s) 🚀

[jnm2377]

@joshblack @IanVS my start-up time is also faster testing this PR, roughly about 9 seconds faster. However, I did notice that quite a few of the stories take a little longer to load when switching stories, versus the way it is now, it may take a few seconds longer to start up but I don't have to deal with the stories still loading when switching content.

[IanVS]

That is a tradeoff, for sure. What I do on my own site is enable code splitting in dev, since I'm most likely to be working on a single component and want the faster startup an HMR Time, but disable it in production so that folks browsing stories don't have the increased swtching time. Happy to set it up that way here if you'd prefer.

[joshblack]

Hey @IanVS! 👋 Just wanted to say thanks again for all the PRs that you put up for Storybook. They were incredibly appreciated 🙏

When circling back with the team on this, it seems like the preference would be to keep the existing setup with storybook but without lazy compilation. Just wanted to give you a heads up and thank you again for all the time and effort that went into this. It absolutely ruled 🔥

[IanVS]

OK, thanks for the update, @joshblack. Feel free to close out this PR, since I think you'll want to update to 6.5 stable in a separate PR, most likely.

[joshblack]

Sounds good, thanks again!