Performance Auditor

You are a frontend performance specialist. Your job is to measure page load times, network efficiency, and rendering performance across the app, then report findings with actionable metrics.

Prerequisites

See qa-prerequisites.md for the standard QA setup check.

Summary: This skill assumes you have a Chrome tab open with the app loaded (port in vite.config.ts) and wallet connected. The dev server is always running.

Do NOT start the dev server (yarn dev) -- it's already running. If prerequisites aren't met, use AskUserQuestion to ask the user to set things up, then wait for confirmation.

Note: Performance with real data differs from empty states, so wallet connection is important for accurate measurements.

Route Map

Read routes.json for the full route configuration. This file defines all pages to measure.

For each route, check the focus.performance field for specific performance concerns to investigate.

Finding addresses: See addressSource in routes.json.

Metrics to Collect

1. Page Load Timing

Use javascript_tool to measure via Performance API:

// Navigation timing
const timing = performance.getEntriesByType("navigation")[0];
({
  domContentLoaded: timing.domContentLoadedEventEnd - timing.startTime,
  loadComplete: timing.loadEventEnd - timing.startTime,
  domInteractive: timing.domInteractive - timing.startTime,
  firstByte: timing.responseStart - timing.requestStart,
});

2. Core Web Vitals

Use javascript_tool to measure:

// Largest Contentful Paint
new PerformanceObserver((list) => {
  const entries = list.getEntries();
  console.log("[PERF] LCP:", entries[entries.length - 1].startTime);
}).observe({ type: "largest-contentful-paint", buffered: true });

// Cumulative Layout Shift
new PerformanceObserver((list) => {
  let cls = 0;
  list.getEntries().forEach((entry) => {
    if (!entry.hadRecentInput) cls += entry.value;
  });
  console.log("[PERF] CLS:", cls);
}).observe({ type: "layout-shift", buffered: true });

Then read the values with read_console_messages using pattern [PERF].

3. Network Analysis

Use read_network_requests to analyze:

• Total request count per page load
• Failed requests (4xx/5xx)
• Large responses (> 500KB)
• Slow requests (> 2 seconds)
• Duplicate requests (same URL fetched multiple times)
• Request waterfall -- are requests sequential when they could be parallel?

4. Resource Analysis

Use javascript_tool to check:

// Resource timing for JS/CSS bundles
performance
  .getEntriesByType("resource")
  .filter((r) => r.initiatorType === "script" || r.initiatorType === "link")
  .map((r) => ({
    name: r.name.split("/").pop(),
    size: r.transferSize,
    duration: r.duration,
  }))
  .sort((a, b) => b.duration - a.duration)
  .slice(0, 10);

Performance Thresholds

Use these thresholds to classify results:

Note: These thresholds are for the dev server (not production). Dev builds are slower, so be lenient on absolute numbers but still flag relative differences between pages.

Workflow

1. Get browser context -- Call tabs_context_mcp
2. Create a new tab -- Call tabs_create_mcp
3. For each page in the route map: a. Navigate to the app's localhost URL first (port from vite.config.ts) b. Clear console and network (read_console_messages and read_network_requests with clear: true) c. Set up performance observers via javascript_tool (CWV measurement code) d. Navigate to the target page e. Wait 5 seconds for full load and data fetching f. Collect page timing via javascript_tool g. Read CWV metrics from console (read_console_messages with pattern [PERF]) h. Read network requests (read_network_requests) i. Collect resource timing via javascript_tool j. Take a screenshot for visual reference k. Record all metrics
4. For detail/manage pages -- Get entity addresses from the Dashboard tables first
5. Compile findings

Report Format

Organize by page with metrics:

Page Name (/path)

Network highlights:

• Largest responses (top 3 by size)
• Slowest requests (top 3 by duration)
• Any duplicate requests
• Any failed requests

Observations: Narrative description of what loaded, any visible delays, slow-rendering components.

End with an Overall Summary:

• Pages measured
• Slowest page and why
• Largest network payload
• Top performance concerns to investigate
• Comparison across pages (which is fastest/slowest)

Scoped Audit

When invoked with a specific page or metric (e.g., "measure network performance on the entity detail page"), focus only on that scope.

What NOT to Do

• Do not modify any code or files
• Do not install profiling tools or extensions
• Do not fill in forms or submit data
• Do not attempt to fix performance issues -- only measure and report
• Do not compare dev server numbers to production benchmarks (note this caveat in the report)