Performance Measurement App

[spmonahan]

Problem

We don't currently have a way to measure Fluent UI control performance in the context of an application. All Fluent UI pull requests currently have two performance related gates:

1. Bundle Size
2. Perf testing with flamegraphs

Bundle size allows us to track component and overall package size and flamegraphs give us information about the performance of an individual component but neither of these give us good insight into the overall performance of Fluent UI components when combined together to build an application.

We need a sample test bed application that will be used to analyze the client-side rendering performance of Fluent UI components so we can understand how changes to Fluent UI are likely to impact real world applications. This test bed application will be a "representative application" in that, while it is simplified for ease of testing, it is complex enough to be a stand-in for an actual production application. This can include things like a large DOM structure with lots of nesting, using hundreds of controls and having multiple views.

This deliverable will allow us to start establishing performance baselines and give us insights to move forward with future performance improvements like reducing rendering time and improved performance automation.

Appetite

4 weeks

Solution

This solution will deliver an application in the Fluent monorepo that can be used for manual performance testing. Manual performance testing includes, but is not necessarily limited to, using tools like DevTools' Performance tab, React's Profiler and edge://tracing to profile applications and identify areas for improvement.

This solution is a first step in and the results may serve as the foundation for future work or take us in an entirely different direction.

1. [x] Pick a tool for creating static applications (e.g., Create React App, Create Next App, etc.)
2. [x] Establish the criteria for a "representative application"
3. [x] Build a representative application using Fluent UI React v9 controls
4. [x] Build a representative application using Fluent UI React v8 controls
5. [ ] Document a basic manual profiling process

Risks (Rabbit holes)

1. Hypotheticals: it's really easy to start thinking about writing tests to cover regressions, automating this work etc. While it's good to give some consideration to the future, this project is already fairly wide in scope so we need to focus on the identified deliverable over the potential for this work in the future.
2. Making performance changes: while doing this work we'll likely identify ways to improve Fluent's performance. This work isn't meant to provide recommendations for improving perf, though if something is simple and/or a huge improvement we can make a separate issue for it.

Out of scope (No-gos)

While this project has a concrete deliverable it is also exploratory in nature and as such it has some explicit non-goals.

1. Automated testing: this issue is focused on manual testing as it's not clear what good automated performance tests look like.
2. Performance Recommendations/Improvements: ultimately this work is the foundation for us to be able to make recommendations and improvements to Fluent UI's performance but this stage of the work is focused on establishing the foundation and working toward baselines.

[spmonahan]

Pick a tool for creating static applications

I want an off-the-shelf solution for quickly creating a new app because, at least to start, I want to avoid all the fiddly setup involved in Webpack/Rollup/etc. To start we plan to compare Fluent UI React v8 and v9 but in the future we'll likely want to compare Fluent UI Web Components and perhaps other frameworks like Svelte.

For these reasons I eliminated Create React App as a solution, as it is focused on React applications only. Ditto for Create Next App as Next.js is built for React.

For this project I'll be using Vite as its scaffolding app provides templates for popular frameworks like React and Svelte along with Vanilla JS (i.e., Web Components).

[spmonahan]

Criteria for a "representative application"

1. Components used to build the application should be available in both Fluent UI v8 and v9.
2. Use each version of the library based on its documentation (i.e., don't try to optimize anything or use "one cool trick" -- we're trying to get a baseline)
3. DOM structure should be deeply nested with hundreds of components.
4. Application should provide mechanisms to update components on page
   1. Update many or most components on the page
   2. Update few components on the page
5. Application must work as static client-side HTML pages (i.e., no server, no SSR, can be loaded locally via file://)
6. Keep it simple. Admittedly, this is a mushy criterion, but the idea is that this work is to establish a baseline so we don't need to get into DetailsList-levels of complexity yet. Also, if we're getting good data from this we may want to build equivalent Web Component and Svelte apps and we don't want to have to re-implement a complicated app or components when making cross-framework comparisons.

[spmonahan]

Manual Testing Process

chrome://tracing

1. Open the app in Chrome 103 or later.
2. Open another tab and navigate to chrome://tracing
3. In the dialog select "Manually Select Settings". Pick all the settings in the left pane and "blink.debug" in the right pane
4. Press "Record"
5. Interact with the app, click buttons, scroll lists, etc.
6. Stop the recording.
7. View the results.

A particularly interesting piece of data is "SelectorStats" which is triggered by "recalculateStyles". SelectorStats will show the CSS selectors that were evaluated as part of the style recalculation and information related to how long they took to evaluate.