web-performance-reviewer

Name: web-performance-reviewer
Author: AdamBien

40stars10forks

How to install web-performance-reviewer?

adambien/airails/web-performance-reviewer

$npx -y skills add AdamBien/airails --skill web-performance-reviewer

Installs into the current project.

Summary

Review web frontends for performance issues by driving the rendered site through Chrome DevTools MCP — throttled performance traces, Core Web Vitals judged against thresholds, network waterfall analysis, and heap-snapshot leak checks for SPAs. Composes on top of web-static or `

Files · 1

View on GitHub

SKILL.md

1	Review the runtime performance of $ARGUMENTS by measuring the rendered site in a real browser
2	through the Chrome DevTools MCP tools (`chrome-devtools`). Produce a prioritized, evidence-backed
3	report. If the `chrome-devtools` MCP tools are unavailable, report the review as not runnable —
4	do not judge performance from source code alone.
5
6	## Composition
7
8	Composes on top of `/web-static` or `/web-components` (and their shared `/web-conventions`).
9	This skill is a reviewer, not a builder: it measures and prioritizes; fixing belongs to the
10	composed stack skill, and re-verification after a fix belongs to that stack's own loop.
11
12	Never part of green. The `/web-static` verification loop stays fast and deterministic;
13	performance numbers are slow to gather and jitter run-to-run, which makes them a bad gate.
14	This review runs only on explicit request — before publishing, after adding images/fonts/JS,
15	or when something feels slow. A red finding here never turns the composed stack's green red.
16
17	## Philosophy
18
19	- Lab, not field — everything measured here is lab data from one Chrome on one machine;
20	useful for finding problems and comparing before/after, never a claim about real-user metrics
21	- Unthrottled localhost lies — a site served by zws on localhost loads in milliseconds
22	regardless of how bloated it is; only throttled runs reveal what users on mid-range phones see
23	- Numbers jitter — a single trace is an anecdote; conclusions come from the median of
24	repeated runs, and high variance is itself a finding to report
25	- The trace is the oracle — never diagnose from reading source; the trace, the waterfall,
26	and the heap snapshot are the evidence, source reading only explains what they found
27	- If it is fast, say so — do not invent issues; a clean report is a valid outcome
28
29	## Serve
30
31	Serve the site root with zws exactly as the composed stack prescribes: `java zws <site-root>`
32	(or the copy bundled with `web-conventions`: `java <web-conventions skill dir>/scripts/zws <site-root>`).
33	Never use `--live` during measurement — the injected reload script and its SSE stream would
34	appear in every trace and waterfall and contaminate the evidence. Measure against a plain instance.
35
36	## Measurement Loop
37
38	### 1. Establish lab conditions
39
40	Before any trace, throttle via `emulate`: 4× CPU slowdown and Slow 4G network, with the
41	page resized to 375×667 (`resize_page`) — the mobile mid-range profile is the honest default.
42	Repeat the headline trace at 1280×800 unthrottled only as a secondary data point, never as the verdict.
43
44	### 2. Trace
45
46	Run `performance_start_trace` with a page reload, then `performance_stop_trace`. Extract from
47	the trace result: LCP, CLS, and TBT (the lab proxy for INP when no interaction is
48	traced). Run at least 3 traces and judge the median; when the spread across runs exceeds
49	~20% on any metric, report the variance instead of pretending precision.
50
51	### 3. Drill into insights
52
53	For each metric that misses its threshold, run `performance_analyze_insight` on the insights the
54	trace flags (LCP breakdown, render blocking, document latency, CLS culprits, third parties) —
55	the insight names the culprit element, resource, or task; put that in the finding, not a guess.
56
57	### 4. Read the waterfall
58
59	`list_network_requests` (and `get_network_request` for suspects): total transfer size, request
60	count, render-blocking CSS and fonts, images without modern formats (`WebP`/`AVIF`) or
61	`loading="lazy"`, oversized images relative to display size, missing compression, and cache
62	headers. This is the check that stays meaningful even when the trace looks fine on a fast machine.
63
64	### 5. Corroborate with Lighthouse
65
66	`lighthouse_audit` with the performance category, as corroboration for the trace findings —
67	its opportunity list often names savings in bytes and milliseconds worth quoting as evidence.
68	The trace remains the primary source; when the two disagree, trust the trace and say so.
69
70	### 6. SPA extras (with `/web-components` only)
71
72	- Interaction responsiveness — trace with recorded interactions (c

People who liked this also viewed

6 picks

Type

web-performance-reviewer

40stars10forks

View on GitHub

How to install web-performance-reviewer?

adambien/airails/web-performance-reviewer

$npx -y skills add AdamBien/airails --skill web-performance-reviewer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Review the runtime performance of $ARGUMENTS by measuring the rendered site in a real browser
2	through the Chrome DevTools MCP tools (`chrome-devtools`). Produce a prioritized, evidence-backed
3	report. If the `chrome-devtools` MCP tools are unavailable, report the review as not runnable —
4	do not judge performance from source code alone.
5
6	## Composition
7
8	Composes on top of `/web-static` or `/web-components` (and their shared `/web-conventions`).
9	This skill is a reviewer, not a builder: it measures and prioritizes; fixing belongs to the
10	composed stack skill, and re-verification after a fix belongs to that stack's own loop.
11
12	Never part of green. The `/web-static` verification loop stays fast and deterministic;
13	performance numbers are slow to gather and jitter run-to-run, which makes them a bad gate.
14	This review runs only on explicit request — before publishing, after adding images/fonts/JS,
15	or when something feels slow. A red finding here never turns the composed stack's green red.
16
17	## Philosophy
18
19	- Lab, not field — everything measured here is lab data from one Chrome on one machine;
20	useful for finding problems and comparing before/after, never a claim about real-user metrics
21	- Unthrottled localhost lies — a site served by zws on localhost loads in milliseconds
22	regardless of how bloated it is; only throttled runs reveal what users on mid-range phones see
23	- Numbers jitter — a single trace is an anecdote; conclusions come from the median of
24	repeated runs, and high variance is itself a finding to report
25	- The trace is the oracle — never diagnose from reading source; the trace, the waterfall,
26	and the heap snapshot are the evidence, source reading only explains what they found
27	- If it is fast, say so — do not invent issues; a clean report is a valid outcome
28
29	## Serve
30
31	Serve the site root with zws exactly as the composed stack prescribes: `java zws <site-root>`
32	(or the copy bundled with `web-conventions`: `java <web-conventions skill dir>/scripts/zws <site-root>`).
33	Never use `--live` during measurement — the injected reload script and its SSE stream would
34	appear in every trace and waterfall and contaminate the evidence. Measure against a plain instance.
35
36	## Measurement Loop
37
38	### 1. Establish lab conditions
39
40	Before any trace, throttle via `emulate`: 4× CPU slowdown and Slow 4G network, with the
41	page resized to 375×667 (`resize_page`) — the mobile mid-range profile is the honest default.
42	Repeat the headline trace at 1280×800 unthrottled only as a secondary data point, never as the verdict.
43
44	### 2. Trace
45
46	Run `performance_start_trace` with a page reload, then `performance_stop_trace`. Extract from
47	the trace result: LCP, CLS, and TBT (the lab proxy for INP when no interaction is
48	traced). Run at least 3 traces and judge the median; when the spread across runs exceeds
49	~20% on any metric, report the variance instead of pretending precision.
50
51	### 3. Drill into insights
52
53	For each metric that misses its threshold, run `performance_analyze_insight` on the insights the
54	trace flags (LCP breakdown, render blocking, document latency, CLS culprits, third parties) —
55	the insight names the culprit element, resource, or task; put that in the finding, not a guess.
56
57	### 4. Read the waterfall
58
59	`list_network_requests` (and `get_network_request` for suspects): total transfer size, request
60	count, render-blocking CSS and fonts, images without modern formats (`WebP`/`AVIF`) or
61	`loading="lazy"`, oversized images relative to display size, missing compression, and cache
62	headers. This is the check that stays meaningful even when the trace looks fine on a fast machine.
63
64	### 5. Corroborate with Lighthouse
65
66	`lighthouse_audit` with the performance category, as corroboration for the trace findings —
67	its opportunity list often names savings in bytes and milliseconds worth quoting as evidence.
68	The trace remains the primary source; when the two disagree, trust the trace and say so.
69
70	### 6. SPA extras (with `/web-components` only)
71
72	- Interaction responsiveness — trace with recorded interactions (c

People who liked this also viewed

6 picks

Type