00:00:00GitHub just released a very powerful add-on for Storybook that completely changes the
00:00:05way we test component performance.
00:00:07It includes a very detailed performance panel filled with valuable insights like measuring
00:00:12frame timing, input responsiveness, layout stability, React profiling, memory pressure
00:00:18and much more.
00:00:19In this video, we'll take a closer look at what this add-on has to offer.
00:00:23It's gonna be a lot of fun, so let's dive into it.
00:00:31Quick question before we begin.
00:00:32Do you know what is shift-left performance testing?
00:00:35It's a development paradigm which dictates that the performance of your app components
00:00:40should be tested earlier in the development process rather than as an afterthought.
00:00:45And this tool is specifically built to help developers make those early judgment calls,
00:00:50giving you a real-time look at how your components behave before they ever hit production.
00:00:55So the Storybook performance panel provides a high-fidelity look at how your components
00:01:00interact with the browser's rendering engine.
00:01:02It tracks, for example, frame timing to identify jitter, you know, those tiny irregular gaps
00:01:07between frames that make animations feel stuttered.
00:01:10It also monitors the main thread for DOM churn and thrashing.
00:01:15DOM churn happens when your code unnecessarily creates, deletes or updates elements in a tight
00:01:20loop while thrashing occurs when the browser is forced to recalculate the layout multiple
00:01:25times in a single frame because you're reading and writing styles back to back.
00:01:30And this add-on adapts to whatever framework you're using.
00:01:33If you're using React, it can highlight metrics like render cascades, which are those small
00:01:38state changes that accidentally trigger a massive slow wave of rerenders across your entire app.
00:01:44And it also tracks P95 duration, which shows your worst-case scenario for your slowest users
00:01:50rather than just an average.
00:01:52And if you aren't using React, the universal mode works perfectly for Vue, Svelte or web
00:01:58components.
00:01:59And for the best results, it is recommended to run this add-on or Chrome or Edge.
00:02:04And they also have a live playbook where we can see these metrics in action.
00:02:08For instance, in the animated box example, we can track exactly how many inline style
00:02:13mutations are happening during an animation.
00:02:16In this case, everything looks healthy.
00:02:18The frame rate and the frame time stays perfectly stable, meaning the browser is handling those
00:02:23style updates without breaking a sweat.
00:02:25However, the heavy list example tells a different story.
00:02:29When we filter this large list, we see a few red flags.
00:02:32First, the cumulative layout shift jumps to a very high value, which indicates that elements
00:02:38are jumping around significantly as they load, creating a jarring experience for the user.
00:02:43We also see a spike in DOM churn, which means that the browser is working overtime to tear
00:02:49down and rebuild a massive number of nodes at once.
00:02:52This also results in dropped frames, which kills the perceived speed and smoothness of
00:02:57the interface.
00:02:58In the element timing example, any DOM element with the element timing attribute is measured
00:03:04for its exact render time.
00:03:06This is incredibly useful because it helps you identify the precise moment when your hero
00:03:11content or your call to action becomes visible, giving you a more accurate picture of perceived
00:03:17performance rather than just generic page load metrics.
00:03:21And when we look at the expensive render example, if we click the re-render button, it causes
00:03:26the p95 duration to spike.
00:03:29This happens because the main thread is being held hostage by the heavy JavaScript execution,
00:03:34making the UI feel very sluggish.
00:03:36We also see frame jitter warnings here, which indicate inconsistent rendering where the time
00:03:41between frames is swinging wildly.
00:03:44And there's also a high total blocking time or TBT.
00:03:47And TBT is a major warning sign because it indicates that the main thread was blocked
00:03:52long enough to prevent the user from being able to interact with the page, like clicking
00:03:57a button or scrolling.
00:03:58And we see a similar breakdown in the memoization waste example.
00:04:03Here the demo shows that re-rendering every single element unnecessarily leads to a massive
00:04:08lag.
00:04:09In contrast, the properly memoized example shows just how much work is saved if we memoize
00:04:15our components.
00:04:16By skipping those redundant renders, we keep the main thread clear and the frame rate locked
00:04:21so we get this buttery smooth 60 frames per second.
00:04:25In the render cascade example, we see exactly what happens when you use set state inside
00:04:30use layout effect.
00:04:31Every single increment triggers a cascade because use layout effect runs synchronously after
00:04:37all DOM mutations, but before the browser has a chance to paint.
00:04:42So by triggering the state update here, you're forcing React to reprocess the component tree
00:04:47and the browser to recalculate the layout a second time before the user even sees the
00:04:52first result.
00:04:53And this is bad because effectively it doubles the work for every single frame, leading to
00:04:58a render lag that can make even simple interactions feel heavy.
00:05:02And then there's the style churn example that also demonstrates a critical observation.
00:05:07What happens when we mutate the inline styles of 600 different nodes at once?
00:05:13We immediately see these stall warnings in the thrashing section, which indicates that
00:05:18the browser is being forced into a reflow loop.
00:05:21It's trying to calculate positions of 600 elements simultaneously while the JavaScript is still
00:05:26making changes.
00:05:27This leads to very unhealthy vitals for our frame metrics because the main thread is completely
00:05:33saturated.
00:05:34So I hope all these examples show you how you can use this storybook add-on to identify
00:05:38bottlenecks in a much more precise environment.
00:05:41Sure, you can use a tool like Lighthouse, but Lighthouse is a broad brush.
00:05:46It doesn't give you that surgical precision to see exactly how an individual component
00:05:51impacts your app's performance.
00:05:53I really encourage you to download this add-on, add it to your storybook suite, and just play
00:05:58around with it.
00:05:59There's so much valuable insights to gain once you see the full picture of how your components
00:06:03actually operate under the hood.
00:06:06So there you have it folks, that is the new GitHub Storybook Performance panel add-on
00:06:10in a nutshell.
00:06:11What do you think about it?
00:06:13And how do you measure performance on your application?
00:06:16Let us know in the comments down below.
00:06:18And folks, if you like these types of technical breakdowns, please let me know by clicking
00:06:22that like button underneath the video and also don't forget to subscribe to our channel.
00:06:28This has been Andres from Better Stack and I will see you in the next videos.