LF-5422 Add bundle size measurement and a committed size baseline for the webapp

[kathyavini]

Description

This PR adds two development-only scripts:

• pnpm bundle-snapshot and
• pnpm bundle-compare

that allow us to track the download costs associated with a given frontend build, and with moving from one build to another.

The use of the scripts is outlined pretty exhaustively in the README.md, so I'll just link there 🙂

This PR also includes output from pnpm bundle-snapshot against our current release v3.13.1. This snapshot can be compared with pnpm bundle-compare against, e.g., the Vite 5 build (seeing the effect of all of those SVGs removed 😍), or against v3.13.0 to evaluate the update costs for this release in particular.

E.g. here is some of the bundle-compare output for yesterday's release

You can then hand the full snapshots in question to a agent for further querying. For instance, I wanted to know how we got to 2MB of re-download for a release that barely touched the frontend, and the answer, depressingly, was those 3 new strings in 5 languages 😢

1. Ten locale chunks change content → their hashes move. 175.4 KB
2. The i18n chunk embeds those filenames → its content changes → its hash moves.
3. Every chunk importing i18n embeds that filename → re-hashes. And so on up the graph to the entry chunk, which carries the filename of everything it imports. 440.3 KB
4. Result: 286 of 343 precached JS chunks re-fetched — 83% — totalling 1894 KB.

The hope is to use and track the snapshots moving forward to quantify the download and re-download costs of what we ship to clients, to test the upcoming tickets in the Network Cost epic, and to identify new candidates for network cost savings.

The committed baseline

bundle-snapshots/3.13.1-e043dd90c.json is the v3.13.1 release. It names the a commit on this branch rather than the release tag, only because the scripts do not yet exist in the tagged tree, and --release enforces a clean (commit-matching) git.

As recommended in the readme, --release snapshots moving forward can be generated on the release tag, and it's simplest to do right after release, when packages have not yet diverged.

Jira link: https://lite-farm.atlassian.net/browse/LF-5422

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Please see readme!

Some instructive comparisons I recommend:

• v3.13.0 to v3.13.1
• v3.13.1 to Vite 5

Note: For older releases that predate the scripts themselves, it's generally easier to request Claude to spin up a worktree and copy the commits over. However, after merge and going forward, the process is just

cd packages/webapp

# Measure any branch you want to compare. The build takes a few minutes.
pnpm bundle-snapshot --label integration

# Diff it against the most recent release baseline (or any other snapshot)
pnpm bundle-compare 3.13.1-e043dd90c integration

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have ordered translation keys alphabetically (optional: run pnpm i18n to help with this)
• I have added the GNU General Public License to all new files

[SayakaOno]

It’s great that we can quickly test without building the Docker container, thank you!

pnpm bundle-snapshot --release

Do we want to add this to the release checklists?

[kathyavini]

Thanks @SayakaOno!

Do we want to add this to the release checklists?

That would be great! 🙏 I was thinking around the same time as the backport PR. And hopefully it doesn't become annoying to keep up 🤞