Add performance measurement

[sgraband]

What it does

This commit adds a script for performance measurement using the Chrome DevTools tracing.
Currently the startup time of the browser-app is being measured.
The script uses Puppeteer so other processes can be measured in the future as well.
For more information see the README.md in the scripts/performance directory.

This PR is intended as the first step to an eventual performance test suite which could also be integrated into the CI tooling.
See #9722 for more information about this topic.

Example output:

[Performance][Startup][1] Largest Contentful Paint (LCP): 2.95 seconds
[Performance][Startup][2] Largest Contentful Paint (LCP): 2.823 seconds
[Performance][Startup][3] Largest Contentful Paint (LCP): 2.829 seconds
[Performance][Startup][4] Largest Contentful Paint (LCP): 2.835 seconds
[Performance][Startup][5] Largest Contentful Paint (LCP): 2.778 seconds
[Performance][Startup][6] Largest Contentful Paint (LCP): 2.795 seconds
[Performance][Startup][7] Largest Contentful Paint (LCP): 2.772 seconds
[Performance][Startup][8] Largest Contentful Paint (LCP): 2.672 seconds
[Performance][Startup][9] Largest Contentful Paint (LCP): 2.706 seconds
[Performance][Startup][10] Largest Contentful Paint (LCP): 2.804 seconds
[Performance][Startup][MEAN] Largest Contentful Paint (LCP): 2.796 seconds
[Performance][Startup][STDEV] Largest Contentful Paint (LCP): 0.072 seconds

Contributed on behalf of STMicroelectronics

Signed-off-by: [email protected]

How to test

See the README on how you can run the script manually or run the performance:startup node script in the root directory to measure the startup time. You can also adjust the parameters to for example execute more iterations or to run the test headful.
Additionally, you can import the generated files in scripts/performance/profiles in the performance tab of the Chrome DevTools.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[tsmaeder]

What do we need this for?

[sgraband]

Without this option the script showed a warning:

The node binary used for scripts is /tmp/yarn--1627025300882-0.06251617126804576/node but npm is using
/home/simon/.nvm/versions/node/v12.22.1/bin/node itself. Use the --scripts-prepend-node-path option to include the
path for the node binary npm was
executed with.

However, right now i cannot reproduce it. Should i remove it?

[tsmaeder]

yarnpkg/yarn#6685 I haven't traced trough all that, but I think yarn is just making copies 🤷 I think we should remove it (or understand why it happens).

[sgraband]

Removed it.

[tsmaeder]

@sgraband thanks for this contribution: it's important that we keep track of startup performance. I have a bunch of suggestions/comments which are mostly code style issues.

[sgraband]

@tsmaeder I rebased the changes to master. Could you have another look?

[colin-grant-work]

@sgraband, it looks like the builds are failing here because running yarn on this commit changes the yarn.lock. You may need to commit those changes so that the builds are satisfied that our yarn.lock is up to date.

[sgraband]

@colin-grant-work rebasing seemed to do the trick.

[colin-grant-work]

This script is performing correctly for me and seems like a reasonable basis for judging changes in startup performance for the application. @tsmaeder, do you have any additional comments?

[tsmaeder]

@colin-grant-work nothing to prevent merging.

[sgraband]

Rebased and removed the .npmrc file.