bee:dev-frontend-performance-vuejs

Dev Frontend Performance Testing - Vue.js (Gate 6)

Overview

Ensure all Vue.js / Nuxt 3 frontend pages meet Core Web Vitals thresholds, achieve Lighthouse Performance > 90, maintain bundle size within budget, and use Nuxt 3 data-fetching composables correctly for optimal performance.

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. Vue.js Frontend QA Analyst Agent (performance mode) EXECUTES.

Who	Responsibility
This Skill	Gather requirements, dispatch agent, track iterations
QA Analyst Frontend Vue.js 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-vuejs/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 Vue.js Frontend QA Analyst Agent (Performance Mode)

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

    **Standards:** Load testing-performance.md (frontend-vuejs)

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

    **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 client-side only code (components with <ClientOnly> or .client.vue) - should be < 40% of components
    5. Detect performance anti-patterns (bare <img>, synchronous data fetching on client, blocking watch())
    6. Verify sindarian-vue imports are tree-shakeable

    **Nuxt 3 / Vue-Specific Performance Checks:**
    - useAsyncData() used for server-side data fetching on page components (not client fetch())
    - useLazyFetch() or useLazyAsyncData() used for non-critical data (deferred loading)
    - <NuxtImg> or <NuxtPicture> used for ALL images (never bare <img>)
    - <NuxtImg> has correct sizes, format, and loading="lazy" for below-fold images
    - defineAsyncComponent() used for heavy components not needed on initial render
    - Pinia stores use lazy initialization where appropriate (avoid loading all store data upfront)
    - v-once directive applied to static subtrees that never change
    - v-memo applied to list items with expensive rendering and stable key conditions
    - No synchronous heavy computation in computed() - offload to Web Workers if needed
    - No unnecessary watchers (watch with { immediate: true } on large reactive objects)
    - Nuxt route-level code splitting is active (automatic with pages/ directory)
    - Nuxt payload de-duplication active (useState() for shared SSR state, not duplicated fetch calls)
    - <TransitionGroup> used with key for list animations instead of forcing DOM re-renders

    **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-vuejs)
  → 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} |

## Client Component Audit
| Metric | Value |
|--------|-------|
| Total .vue files | {count} |
| Client-only components (<ClientOnly> or .client.vue) | {count} |
| Client ratio | {percent}% (< 40%) |

## Anti-Pattern Detection
| Pattern | Occurrences | Status |
|---------|-------------|--------|
| Bare <img> (not NuxtImg) | {count} | {PASS|FAIL} |
| Client fetch() for server data | {count} | {PASS|FAIL} |
| Wildcard sindarian-vue imports | {count} | {PASS|FAIL} |
| Blocking watch() on large objects | {count} | {PASS|FAIL} |
| Missing useLazyFetch for non-critical data | {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 ClientOnly"	Server-rendered components reduce JS. Audit first.	Minimize client-only components
"NuxtImg is too complex"	NuxtImg gives free optimization. Always use it.	Use NuxtImg
"Lighthouse 85 is close enough"	90 is the threshold. 85 = FAIL.	Optimize to 90+
"useAsyncData is the same as fetch()"	useAsyncData runs on server, reducing client JS + waterfall.	Use useAsyncData for page data
"useLazyFetch complicates the code"	Deferred loading prevents blocking the initial render.	Use useLazyFetch for non-critical data
"v-memo is premature optimization"	v-memo prevents unnecessary re-renders in lists. Apply it.	Apply v-memo to expensive list items

---