Benchmark
- 1.4k installs
- 238k repo stars
- Updated August 5, 2026
- affaan-m/ecc
This is a copy of benchmark by affaan-m - installs and ranking accrue to the original listing.
Benchmark is an ECC agent skill that establishes performance baselines, detects regressions after code changes, and compares technology stack alternatives using browser metrics such as Core Web Vitals and bundle size tar
About
Benchmark is an ECC performance skill for measuring baselines, catching PR regressions, and comparing stack alternatives. Mode 1 drives a real browser via browser MCP to capture Core Web Vitals—LCP under 2.5s, CLS under 0.1, INP under 200ms, FCP under 1.8s, and TTFB under 800ms—plus total page weight under 1MB and JS bundles under 200KB gzipped. Developers reach for Benchmark before launch, when users report slowness, or when evaluating framework swaps. The skill turns subjective performance complaints into measured thresholds suitable for CI-style gates.
- Three distinct modes: Page Performance, API Performance, and Build Performance
- Measures Core Web Vitals including LCP < 2.5s, CLS < 0.1, INP < 200ms, FCP < 1.8s, TTFB < 800ms
- Runs API benchmarks with 100 hits tracking p50/p95/p99 latency under 10 concurrent load
- Captures build times, hot reload speed, and bundle sizes against strict targets
- Detects regressions before and after PRs with quantitative before/after comparison
Benchmark by the numbers
- 1,398 all-time installs (skills.sh)
- +86 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/affaan-m/ecc --skill benchmarkAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.4k |
|---|---|
| repo stars | ★ 238k |
| Last updated | August 5, 2026 |
| Repository | affaan-m/ecc ↗ |
How do you catch web performance regressions before launch?
Establish performance baselines, catch regressions after code changes, and objectively compare technology stack options.
Who is it for?
Developers shipping web apps who need measured Core Web Vitals baselines and PR regression checks before release.
Skip if: Backend-only services with no browser UI should skip Benchmark because its primary mode targets page and bundle metrics.
When should I use this skill?
A developer measures PR performance impact, sets baselines, investigates slow pages, or compares stack alternatives before launch.
What you get
Performance baseline report with LCP, CLS, INP, FCP, TTFB, page weight, and JS bundle measurements.
- Performance baseline report
- Regression comparison
By the numbers
- Targets LCP under 2.5s, CLS under 0.1, INP under 200ms, FCP under 1.8s, and TTFB under 800ms
- Flags page weight over 1MB and JS bundles over 200KB gzipped
Files
ベンチマーク — パフォーマンスベースラインと回帰検出
使用時期
- PR前後にパフォーマンスへの影響を測定
- プロジェクトのパフォーマンスベースラインを設定
- ユーザーが「遅く感じる」と報告したとき
- ローンチ前 — パフォーマンスターゲットを満たしていることを確認
- スタックを代替案と比較
動作方法
モード1：ページパフォーマンス
ブラウザMCPを介してリアルブラウザメトリクスを測定：
1. 各ターゲットURLに移動
2. Core Web Vitalsを測定：
- LCP (Largest Contentful Paint) — ターゲット < 2.5s
- CLS (Cumulative Layout Shift) — ターゲット < 0.1
- INP (Interaction to Next Paint) — ターゲット < 200ms
- FCP (First Contentful Paint) — ターゲット < 1.8s
- TTFB (Time to First Byte) — ターゲット < 800ms
3. リソースサイズを測定：
- 合計ページウェイト（ターゲット < 1MB）
- JSバンドルサイズ（ターゲット < 200KBgzipped）
- CSSサイズ
- 画像ウェイト
- サードパーティスクリプトウェイト
4. ネットワークリクエストをカウント
5. レンダリングブロッキングリソースをチェックモード2：APIパフォーマンス
APIエンドポイントをベンチマーク：
1. 各エンドポイントに100回ヒット
2. 測定：p50、p95、p99レイテンシ
3. トラック：レスポンスサイズ、ステータスコード
4. ロード下でテスト：10個の同時リクエスト
5. SLAターゲットと比較モード3：ビルドパフォーマンス
開発フィードバックループを測定：
1. コールドビルド時間
2. ホットリロード時間（HMR）
3. テストスイート期間
4. TypeScriptチェック時間
5. Lint時間
6. Dockerビルド時間モード4：前後の比較
変更前後に実行して影響を測定：
/benchmark baseline # 現在のメトリクスを保存
# ... 変更を加える ...
/benchmark compare # ベースラインと比較出力：
| Metric | Before | After | Delta | Verdict |
|--------|--------|-------|-------|---------|
| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
| Build | 12s | 14s | +2s | WARNING: WARN |出力
.ecc/benchmarks/にJSONとしてベースラインを保存。Gitで追跡されるため、チームはベースラインを共有します。
統合
- CI：すべてのPRで
/benchmark compareを実行 /canary-watchとペアリングしてデプロイ後の監視/browser-qaとペアリングして完全な出荷前チェックリスト
Related skills
TddFollow test-driven development with a strict red-green-refactor loop when creating reliable features or fixing bugs.544k196k
Test Driven DevelopmentEnforce writing failing tests before any production implementation code.181k264kQaRun conversational QA sessions that turn user-reported bugs into well-written, domain-aware GitHub issues without manual ticket writing.179k196kMigrate To ShoehornAutomatically update TypeScript test files that rely on unsafe `as` type assertions by replacing them with type-safe partial objects from @total-typescript/shoehorn.164k196k
Webapp TestingVerify frontend behavior, debug UI issues, capture screenshots, and inspect logs of a running local web application using Playwright.123k165k
Playwright CliRun browser automation, generate element snapshots, inspect DOM attributes, and execute Playwright tests from the terminal.102k12.3kHow it compares
Choose Benchmark over generic load testing when you need browser Core Web Vitals and frontend bundle thresholds tied to PR workflows.
FAQ
Which metrics does Benchmark measure?
Benchmark measures Core Web Vitals including LCP, CLS, INP, FCP, and TTFB via browser MCP, plus total page weight and gzipped JS bundle size against documented thresholds such as LCP under 2.5 seconds.
When should Benchmark run in a release cycle?
Benchmark runs before launch, around pull requests, when users report slowness, or when comparing stack alternatives to ensure performance targets and baselines are met.