/skill

Benchmark

Original skill by ECC. Credit goes to ECC.

Use this skill to measure speed in a fair and repeatable way.

When to Use

Use this skill when:

• You need a speed baseline.
• You want to check a pull request.
• A user says the app feels slow.
• You are getting ready to launch.
• You want to compare two tools or stacks.

Safety Rules

• Do not send data to a new service.
• Do not add tracking or logs about users.
• Do not test a live site without clear approval.
• Do not run a load test on a shared or live API without clear approval.
• Hide tokens, cookies, passwords, and private user data.
• Use test accounts and test data when login is needed.
• Do not change app data unless the test needs it and the user agrees.
• Stop if the test causes errors or harms other work.

Test Rules

Keep each test fair:

1. Write down the app version, test command, device, and test setup.
2. Use the same URL, data, network speed, and machine for each run.
3. Run a warm-up before timed runs.
4. Run each test at least three times.
5. Report the middle result. Also show the full range.
6. Test one change at a time when you can.
7. Save raw results. Do not report only the best run.
8. Note noise from other apps, cache state, or slow networks.
9. Mark missing or failed data as N/A. Do not guess.
10. If two results are very close, call them the same.

Use project goals when they exist. The goals below are only default guides.

Mode 1: Page Speed

Use an approved browser tool on each target page.

Measure:

• LCP: under 2.5 seconds
• CLS: under 0.1
• INP: under 200 milliseconds
• FCP: under 1.8 seconds
• TTFB: under 800 milliseconds
• Total page size: under 1 MB
• Gzip JavaScript size: under 200 KB
• CSS size
• Image size
• Third-party script size
• Request count
• Files that block page paint

Test both cold and warm loads. Clear the cache for cold loads. Keep it for warm loads.

For pages that need login, use the same test account and state. Wait until the page is ready before you start an action test.

INP needs a real action. Use the same click, tap, or key press in each run. If no action can be tested, report INP as N/A.

Test key screen sizes when the page changes by screen size. At least test one phone size and one desktop size.

Do not treat local results as real-user data. Say that the test is a lab test.

Mode 2: API Speed

Test each API route with the same request data.

Default test:

1. Send a small warm-up set.
2. Send 100 timed requests.
3. Measure p50, p95, and p99 time.
4. Record response size and status code.
5. Test up to 10 requests at once.
6. Compare the results with the project goal.

Also report:

• Error count
• Timeout count
• Requests per second
• Test length
• Cache state
• Any rate limit response

Use a lower request count when the route writes data, costs money, or has a rate limit. Mock or reset write tests when safe. Never repeat a charge, email, post, or delete action by mistake.

A p99 value from only 100 runs can change a lot. Mark it as a rough value.

Mode 3: Build Speed

Measure the work loop:

• Clean build time
• Repeat build time
• Hot reload time
• Test run time
• Type check time
• Lint time
• Docker build time

State whether caches were empty or warm. Do not compare a clean build with a cached build.

If tests run in parallel, keep the worker count the same.

Mode 4: Before and After

Save the current result before a code change:

/benchmark baseline

Make the code change. Then run:

/benchmark compare

Use the same setup for both runs.

A result is a slowdown only when:

• It is worse than the project limit, or
• It is worse by more than normal test noise.

If no project limit exists, use both a fixed and a percent limit. Example:

• Warn when LCP is at least 100 ms and 5% slower.
• Warn when build time is at least 1 second and 5% slower.
• Fail only when the project has a clear fail limit.

Output

Save results as JSON in:

.ecc/benchmarks/

Use clear file names:

.ecc/benchmarks/baseline.json
.ecc/benchmarks/compare.json

Do not replace a baseline unless the user asks or the new baseline is approved. If the folder cannot be written, print the JSON and explain where it should be saved.

Each result must include:

• Date and time
• Git commit, if known
• Test mode
• Test target
• Test command
• Machine and test setup
• Cache state
• Number of runs
• Raw values
• Middle value
• Range
• Limits used
• Errors and notes

Show a short table:

| Metric | Before | After | Change | Result |
|---|---:|---:|---:|---|
| LCP | 1.2 s | 1.4 s | +200 ms | WARN |
| JS bundle | 180 KB | 175 KB | -5 KB | BETTER |
| Build | 12 s | 14 s | +2 s | WARN |

Use these result words:

• BETTER
• SAME
• WARN
• FAIL
• N/A

End with a short summary. Name the largest gain, the largest loss, failed tests, and any limits that were missed.

Example

A user asks:

Check if this pull request made the home page slower.

Run this flow:

1. Check out or measure the base code.
2. Run one warm-up.
3. Run five cold page loads.
4. Save the result with /benchmark baseline.
5. Check out or measure the pull request.
6. Run the same warm-up and five cold loads.
7. Run /benchmark compare.
8. Save the JSON files.
9. Report the table and any test noise.

Example result:

The home page is slower.

LCP rose from 1.8 s to 2.2 s. This is 400 ms, or 22%, slower.
The page still meets the 2.5 s goal.
Image size rose by 310 KB. This is the main cause found.
Result: WARN

Team Use

• Run compare in CI for each pull request when the test setup is stable.
• Keep approved baselines in Git so the team can share them.
• Pair this skill with a canary check after a release.
• Pair it with browser checks before a release.