bee-dev-frontend-performance

name	bee:dev-frontend-performance
title	Frontend development cycle performance testing (Gate 6)
category	development-cycle-frontend
tier	1
when_to_use	Use after E2E testing (Gate 5) is complete in the frontend dev cycle. MANDATORY for all frontend development tasks - ensures performance meets thresholds.
description	Gate 6 of frontend development cycle - ensures Core Web Vitals compliance, Lighthouse performance score > 90, and bundle size within budget.
trigger	- After E2E testing complete (Gate 5) - MANDATORY for all frontend development tasks - Validates performance before code review
NOT_skip_when	- "Performance is fine on my machine" - Users have slower devices. - "We'll optimize later" - Performance debt compounds. - "It's a small change" - Small changes can cause big regressions.
sequence	{"after":["bee:dev-frontend-e2e"],"before":["bee:requesting-code-review"]}
related	{"complementary":["bee:dev-cycle-frontend","bee:dev-frontend-e2e","bee:qa-analyst-frontend"]}
input_schema	{"required":[{"name":"unit_id","type":"string","description":"Task or subtask identifier"},{"name":"implementation_files","type":"array","items":"string","description":"Files from Gate 0 implementation"}],"optional":[{"name":"performance_baseline","type":"object","description":"Previous performance metrics for comparison"},{"name":"gate5_handoff","type":"object","description":"Full handoff from Gate 5 (E2E testing)"}]}
output_schema	{"format":"markdown","required_sections":[{"name":"Performance Testing Summary","pattern":"^## Performance Testing Summary","required":true},{"name":"Core Web Vitals Report","pattern":"^## Core Web Vitals Report","required":true},{"name":"Handoff to Next Gate","pattern":"^## Handoff to Next Gate","required":true}],"metrics":[{"name":"result","type":"enum","values":["PASS","FAIL"]},{"name":"lcp_ms","type":"integer"},{"name":"cls_score","type":"float"},{"name":"inp_ms","type":"integer"},{"name":"lighthouse_score","type":"integer"},{"name":"bundle_size_change_percent","type":"float"},{"name":"iterations","type":"integer"}]}
verification	{"automated":[{"command":"npx lighthouse http://localhost:3000 --output=json --quiet 2>/dev/null | jq '.categories.performance.score'","description":"Lighthouse performance score","success_pattern":"0\\.[9-9]"},{"command":"grep -rn \"'use client'\" --include='*.tsx' --include='*.ts' src/ | wc -l","description":"Count client components","success_pattern":"[0-9]+"}],"manual":["LCP < 2.5s on all pages","CLS < 0.1 on all pages","INP < 200ms on all pages","Bundle size increase < 10%","No bare <img> tags (all use next/image)"]}
examples	[{"name":"Performance tests for dashboard","input":{"unit_id":"task-001","implementation_files":["src/app/dashboard/page.tsx"]},"expected_output":"## Performance Testing Summary\n**Status:** PASS\n**LCP:** 1.8s (< 2.5s)\n**CLS:** 0.03 (< 0.1)\n**INP:** 95ms (< 200ms)\n**Lighthouse:** 94 (> 90)\n**Bundle Change:** +3.2% (< 10%)\n\n## Core Web Vitals Report\n| Page | LCP | CLS | INP | Status |\n|------|-----|-----|-----|--------|\n| /dashboard | 1.8s | 0.03 | 95ms | PASS |\n\n## Handoff to Next Gate\n- Ready for Gate 7 (Code Review): YES\n"}]

Dev Frontend Performance Testing (Gate 6)

Overview

Ensure all frontend pages meet Core Web Vitals thresholds, achieve Lighthouse Performance > 90, maintain bundle size within budget, and minimize client component usage.

Core principle: Performance is a feature. Users on slow devices and connections deserve a fast experience. Performance budgets are enforced, not suggested.

<block_condition>

• LCP > 2.5s on any page = FAIL
• CLS > 0.1 on any page = FAIL
• INP > 200ms on any page = FAIL
• Lighthouse Performance < 90 = FAIL
• Bundle size increase > 10% without justification = FAIL </block_condition>

CRITICAL: Role Clarification

This skill ORCHESTRATES. Frontend QA Analyst Agent (performance mode) EXECUTES.

Who	Responsibility
This Skill	Gather requirements, dispatch agent, track iterations
QA Analyst Frontend Agent	Run Lighthouse, measure CWV, analyze bundles, audit components

---

Standards Reference

MANDATORY: Load testing-performance.md standards via WebFetch.

<fetch_required> https://raw.githubusercontent.com/luanrodrigues/ia-frmwrk/master/dev-team/docs/standards/frontend/testing-performance.md </fetch_required>

---

Step 1: Validate Input

REQUIRED INPUT:
- unit_id: [task/subtask being tested]
- implementation_files: [files from Gate 0]

OPTIONAL INPUT:
- performance_baseline: [previous metrics for comparison]
- gate5_handoff: [full Gate 5 output]

if any REQUIRED input is missing:
  → STOP and report: "Missing required input: [field]"

Step 2: Dispatch Frontend QA Analyst Agent (Performance Mode)

⛔ Agent Name Resolution: MUST resolve bee: names to runtime-qualified names before dispatch. See shared-patterns/shared-orchestrator-principle.md → "Agent Runtime Resolution".

Task tool:
  subagent_type: "bee:qa-analyst-frontend"
  model: "opus"
  prompt: |
    **MODE:** PERFORMANCE TESTING (Gate 6)

    **Standards:** Load testing-performance.md

    **Input:**
    - Unit ID: {unit_id}
    - Implementation Files: {implementation_files}
    - Baseline: {performance_baseline or "N/A"}

    **Requirements:**
    1. Measure Core Web Vitals (LCP, CLS, INP) on all affected pages
    2. Run Lighthouse audit (Performance score > 90)
    3. Analyze bundle size change vs baseline
    4. Audit 'use client' usage (should be < 40% of components)
    5. Detect performance anti-patterns (bare <img>, useEffect for fetching, etc.)
    6. Verify sindarian-ui imports are tree-shakeable

    **Output Sections Required:**
    - ## Performance Testing Summary
    - ## Core Web Vitals Report
    - ## Handoff to Next Gate

Step 3: Evaluate Results

Parse agent output:

if "Status: PASS" in output:
  → Gate 6 PASSED
  → Return success with metrics

if "Status: FAIL" in output:
  → Dispatch fix to implementation agent (bee:frontend-engineer)
  → Re-run performance tests (max 3 iterations)
  → If still failing: ESCALATE to user

Step 4: Generate Output

## Performance Testing Summary
**Status:** {PASS|FAIL}
**LCP:** {value}s (< 2.5s)
**CLS:** {value} (< 0.1)
**INP:** {value}ms (< 200ms)
**Lighthouse:** {score} (> 90)
**Bundle Change:** {+X%} (< 10%)

## Core Web Vitals Report
| Page | LCP | CLS | INP | Status |
|------|-----|-----|-----|--------|
| {page} | {value} | {value} | {value} | {PASS|FAIL} |

## Bundle Analysis
| Metric | Current | Baseline | Change | Status |
|--------|---------|----------|--------|--------|
| Total JS (gzipped) | {size} | {size} | {change}% | {PASS|FAIL} |

## Server Component Audit
| Metric | Value |
|--------|-------|
| Total .tsx files | {count} |
| Client components | {count} |
| Client ratio | {percent}% (< 40%) |

## Anti-Pattern Detection
| Pattern | Occurrences | Status |
|---------|-------------|--------|
| Bare <img> | {count} | {PASS|FAIL} |
| useEffect for fetching | {count} | {PASS|FAIL} |
| Wildcard sindarian imports | {count} | {PASS|FAIL} |

## Handoff to Next Gate
- Ready for Gate 7 (Code Review): {YES|NO}
- Iterations: {count}

---

Anti-Rationalization Table

See shared-patterns/shared-anti-rationalization.md for universal anti-rationalizations. Gate-specific:

Rationalization	Why It's WRONG	Required Action
"Works fine on my machine"	Your machine ≠ user's device. Measure objectively.	Run Lighthouse
"We'll optimize later"	Performance debt compounds. Fix during development.	Meet thresholds now
"Bundle size doesn't matter"	Mobile 3G users exist. Every KB matters.	Stay within budget
"Everything needs use client"	Server components reduce JS. Audit first.	Minimize client components
"next/image is too complex"	next/image gives free optimization. Always use it.	Use next/image
"Lighthouse 85 is close enough"	90 is the threshold. 85 = FAIL.	Optimize to 90+

---