extension-profiling

Browser Extension Profiling

Methodology for profiling and comparing extension performance across branches or commits.

When To Use

• Validating that a refactor reduces unnecessary re-renders (needs before/after comparison)
• Establishing baseline metrics for a performance initiative
• Investigating a reported UI slowdown in the extension

Do Not Use When

• Single-run comparisons — statistical significance requires ≥10 runs per scenario
• The change touches only non-render paths (background scripts, network with no UI impact)
• Target behavior is server-side latency, not UI rendering

Workflow

1. Build both branches on the same machine and Chrome version: yarn build:test for the E2E benchmarks, and a development build (yarn start or yarn build:test:dev) for the React DevTools Profiler. For a PR, build the PR's merge-base as the baseline, not main's tip. The merge-base is the build the PR actually changed.

2. WDYR profiling (unnecessary re-render counts)

   ENABLE_WHY_DID_YOU_RENDER=true yarn start
   

   Flags to watch:

   • different objects that are equal by value → object recreation
   • different functions with the same name → callback recreation
   • props object itself changed but values equal → parent cascade

3. React DevTools Profiler for flame graphs and commit timings, on a development build. yarn build:test passes --mode production, which sets NODE_ENV=production, and React's production build records no profiling data.

   yarn devtools:react
   

4. E2E benchmarks for scenario durations

   yarn test:e2e:benchmark
   

5. Collect ≥10 runs per scenario. Discard top/bottom 10%. Report mean, median, stddev, p75, p95.

6. Effect size: report the difference in the metric's own units alongside Cohen's d. Cohen's d is the difference divided by the benchmark's own spread, so the difference worth acting on comes from product impact, fixed before the runs.

Common Pitfalls

Mistake	Correct Approach
Running branches on different machines or Chrome versions	Same machine, same Chrome, no other apps running
Pooling all runs including noisy late-session ones	Fix the primary analysis, and any rule for dropping a round, before the runs. Report per-round stats as sensitivity, with explicit round attribution
Reporting absolute re-render counts without scenario context	Normalize per-action; cascade fixes show multiplied impact at root
Skipping cache and state reset between runs	Clear browser cache, reset extension state for each run

Pre-Profiling Checklist

• [ ] Both branches built with yarn build:test (benchmarks) and a development build (React DevTools Profiler)
• [ ] Same machine, same Chrome version
• [ ] No other tabs or applications running
• [ ] WDYR enabled: ENABLE_WHY_DID_YOU_RENDER=true
• [ ] Cache and extension state cleared between runs
• [ ] Wallet state sized for the scenario: yarn start:with-state runs yarn start with a generated fixture wallet (30 accounts by default). A null on an empty wallet is a fact about the fixture, not the code