Conversation
`extension-profiling`, `react-render-delta`, `data-analysis` and `benchmark-design`, split from #43 so the audit half reviews separately. The existing `performance` skill is mobile-scoped and advisory — it says what to change. Nothing in the repo says how to prove a change worked, and the extension has no profiling skill at all.
`yarn build:test` runs webpack with `--mode production`, which sets `NODE_ENV=production`, and React's production build records no profiling data. The statistics example labeled two non-significant results "no effect", which an underpowered run and a true null cannot tell apart.
`benchmark-design`, `benchmark-statistical-hygiene`, `metrics-pipeline-design` and the two benchmark-facing Web Vitals files now ship in #162 (add E2E benchmark design and statistics skills). This PR keeps profiling, render-delta proof and data analysis.
…nits Choosing the round with the cleanest signal after seeing the data is cherry-picking a time range, so per-round results are sensitivity. A Cohen's d cutoff sets meaningfulness from the benchmark's own spread, so the difference worth acting on is fixed from product impact instead.
A percentile is not a cohort, and an outcome read without the fraction of users on a build that contains the change is not valid. Each change is confirmed in the release whose traffic is read, with pre- and post-change clients kept apart. A PR's baseline is its merge-base, and a profiling run names the wallet state it ran on.
MajorLift
marked this pull request as ready for review
September 18, 2026 14:25
rvelaz
approved these changes
Sep 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The
performancedomain's extension skills (perf-rendering,perf-hooks-effects,perf-react-compiler,perf-state-management) say what to change for React rendering, and none of them gives a method for measuring whether a change worked. AuseMemothat recomputes on every render still looks correct in review, and only a re-render count separates it from one that works.Overview
Extends the
performancedomain with three measurement skills and one knowledge file.extension-profilingcomparesmetamask-extensionperformance between branches using why-did-you-render, the React DevTools Profiler and E2E benchmarks.react-render-deltatests whether a rendering or memoization change reduced work, from re-render counts and reselect's.recomputations(), and aborts any arm whose change did not reach the built bundle.data-analysisattributes metric movements to the code changes in a release, and rates each attribution High, Medium or Low confidence.domains/performance/knowledge/web-vitals-attribution-import.md:web-vitals/attribution, an import path within theweb-vitalspackage, reports which script or element caused each metric, and the file says not to skip it for bundle size.