Changelog

New

This PR adds the framework required to run component stress tests and a couple of examples.

The tests run on Storybook and measure the time it takes for a component to react to a state change.

This is how one of them looks like:

I tried to make the code self explanatory but I'll give a brief overview of how the pieces fit together here.

StressTest.tsx is a helper component to be used in Storybook, that takes care of all the performance measuring part of the stress tests. It has a very simple API so that defining the tests is as simple as possible.
It uses afterframe and a React state update to do this. We trigger a state update, which the component will react to and rerender appropriately according to the test defined. The afterFrame library calls the function when the next frame starts and measures the elapsed time. The reasoning behind this approach is well explained in this article.

[Component].stress.stories.tsx contain the stress tests for a few components. The components will react to the state change by interacting with the count prop provided in the render function. This reaction is what the stress test will measure.

stress-tests.yml defines the workflow that runs the stress tests. It runs the Playwright tests against the Storybook server and stores the results in a file. This file is stored in the cache and compared to the previous results. Each commit will generate a new result in the cache.

If the result of any commit is slower than the alert threshold defined there, the workflow will fail and a comment will be added to the commit with the results.

StressTests.test.ts is where the Playwright tests are defined. The tests just run the Storybook story and grab the mean result from them.

stress-test-reporter.ts gets the results from the Playwright tests and stores them in a file, in a format that benchmark-action/github-action-benchmark expects.

FAQ

How much of a stable environment do you need for this to be reliable?

So far, defining runs-on: ubuntu-latest-4-cores on the workflow has been very reliable. Running the tests locally is also very consistent from run to run but, as you can imagine, it will only be useful to compare numbers between runs on the same hardware.

How accurate is it at detecting regressions?

Very accurate according to my tests. Here's an example of enabling and disabling CSS modules on ActionList:

Rollout strategy

• Patch release
• Minor release
• Major release; if selected, include a written rollout or migration plan
• None; if selected, include a brief description as to why

Testing & Reviewing

Merge checklist

• Added/updated tests
• Added/updated documentation
• Added/updated previews (Storybook)
• Changes are SSR compatible
• Tested in Chrome
• Tested in Firefox
• Tested in Safari
• Tested in Edge
• (GitHub staff only) Integration tests pass at github/github (Learn more about how to run integration tests)