---
name: mcp-frontend-performance-debugger
description: >
  Diagnose and improve slow, laggy, memory-growing web frontends through reproducible browser telemetry, trace analysis, DOM/render profiling, network evidence, and lifecycle review. Use for long tasks, delayed interactions, excessive renders or JS interop, listener/observer leaks, unstable load performance, or regressions that require before/after budgets and soak tests. Supports generic web apps with optional .NET/Blazor/WASM, DevExpress grid, and Tesi Platform references. Do not use for a purely visual grid-layout bug or generic E2E flow testing.
---

# MCP Frontend Performance Debugger

Diagnostica performance frontend in modo evidence-gated: misura prima, attribuisci il costo, applica il cambiamento minimo utile e verifica con la stessa baseline. Non dedurre una causa da un singolo screenshot, da una sensazione di lentezza o dal solo numero di righe di codice.

## Quick routing

Usa questa skill per:

- long task, input delay, UI che resta bloccata o interazioni calde lente;
- render ripetuti, DOM churn, layout thrashing, JS interop e callback ridondanti;
- crescita di heap, nodi DOM, listener, observer, timer o richieste in-flight;
- analisi di Chrome Performance trace, PerformanceObserver, console e Network;
- benchmark cold/warm, budget p95/worst, reload ripetuti e soak mount/unmount;
- concorrenza asincrona frontend: supersession, coalescing, cancellation e disposal.

Non usarla come skill primaria per:

- glitch esclusivamente visivi di grid, scrollbar, flicker o geometria -> `mcp-grid-ui-debugger`;
- sola automazione di un flusso funzionale E2E -> `mcp-browser-automation`;
- sola review statica senza sintomo runtime -> `mcp-code-reviewer`;
- indagine multi-sorgente con ticket, DB, commit e documenti -> `mcp-technical-analyst`.

Se il problema di grid combina glitch e lentezza sistemica, usa questa skill per il profiling e `mcp-grid-ui-debugger` per la diagnosi geometrica.

## Routing delle reference

Leggi solo le reference necessarie:

- workflow, metriche, budget e soak: [references/evidence-workflow.md](references/evidence-workflow.md);
- trace Chrome, PerformanceObserver, DOM e leak: [references/browser-telemetry.md](references/browser-telemetry.md);
- .NET, Blazor WebAssembly e JS interop: [references/dotnet-blazor-wasm.md](references/dotnet-blazor-wasm.md);
- DevExpress grid e Tesi Platform: [references/devexpress-tesi-platform.md](references/devexpress-tesi-platform.md).

## Workflow obbligatorio

### Parallelizzazione portabile

Segui sempre la policy sub-agent del progetto o dell'host. Mantieni localmente percorso critico, decisioni architetturali, integrazione e sintesi finale. Delega soltanto attività indipendenti e bounded, per esempio estrazione read-only di una trace, inventario listener/observer o verifica separata di test e documentazione.

Assegna le attività per capacità (`scout`, `technical analyst`, `code reviewer`, `test writer`, `implementer`) senza imporre nomi di tool, client, provider o modelli. Impedisci deleghe ricorsive quando non servono e assegna un solo owner alle modifiche del working tree. Se l'host non supporta sub-agent, esegui lo stesso workflow sequenzialmente senza degradare i gate di evidenza.

### 1. Definisci scenario e contratto

Fissa URL o flow, dataset, viewport, browser, build, CPU/network throttling e stato cold/warm. Separa il benchmark rappresentativo dall'identità del caso: non inserire group ID, scenario ID, tenant, record ID o widget instance nella logica applicativa.

Definisci budget prima di cambiare codice. Distingui interazioni calde senza fetch, prime aperture, operazioni con rete e caricamento iniziale.

### 2. Raccogli una baseline ripetibile

Riutilizza la sessione browser richiesta dall'utente quando contiene autenticazione o stato utile. Non cambiare browser senza consenso esplicito. Registra almeno tre campioni per flussi brevi e usa p50/p95/worst quando il volume lo consente.

Raccogli solo segnali utili al sintomo: main-thread time, long task, render generation, DOM reads/writes, richieste duplicate, nodi, heap, listener/observer/timer e geometry readiness.

### 3. Attribuisci il costo

Classifica ogni costo come:

- scripting/interop;
- rendering managed/framework;
- style/layout/paint;
- rete o serializzazione;
- attesa intenzionale, debounce o lock;
- leak o ownership lifecycle;
- misura perturbata dallo strumento.

Se una funzione WASM resta non attribuita e domina il profilo, richiedi simboli solo dopo aver escluso JS, layout, rete e duplicazioni osservabili.

### 4. Incrocia runtime e sorgente

Cerca nel codice gli owner reali di listener, observer, RAF, timer, interop reference, request e cache. Verifica `dispose`, cancellazione, error path e callback obsolete. Usa history/blame quando serve distinguere regressioni introdotte dal change set da logica preesistente.

Separa sempre:

- fatto osservato;
- inferenza;
- ipotesi ancora da provare;
- punto condizionale non necessario secondo le metriche.

### 5. Applica correzioni proporzionate

Preferisci, quando l'evidenza le giustifica:

- una sola lettura rappresentativa invece di scansioni DOM complete;
- tutte le letture prima delle scritture;
- coalescing per frame o per chiave;
- generation token e cancellazione delle risposte obsolete;
- ownership esplicita e disposal di listener/observer/timer/RAF;
- cache con scope, TTL, cardinalità e invalidazione definiti;
- mount-once per pannelli costosi riaperti spesso;
- diagnostica opt-in e non-production.

Non mantenere due controller o due pipeline per un beneficio marginale. Non introdurre retry ladder, polling indefinito o listener globali permanenti per mascherare una race. Non sostituire una causa misurata con un refactor architetturale non dimostrato.

### 6. Verifica dopo rebuild o deploy corretto

Se lo stack richiede compilazione, fermati e chiedi al solution owner di ricompilare. Dopo la conferma, esegui reload pulito e ripeti la stessa matrice. Verifica anche logica, UI, console, rete e ripristino dello stato, non solo la metrica ottimizzata.

### 7. Esegui acceptance e soak proporzionati

Copri almeno load cold/warm, interazioni calde, prima apertura e riapertura, errore, cancellazione e disposal. Per sospetti leak, alterna mount/unmount o navigation, forza GC solo quando disponibile e confronta heap, nodi e listener rispetto al baseline.

Non dichiarare “nessuna regressione” se drag, cross-tab, grouping o altri flussi modificati non sono stati verificati. Registra esplicitamente i gate residui e distingui blocchi implementativi da acceptance operative lunghe.

## Output atteso

Produci una sintesi con:

1. scenario e ambiente;
2. baseline e budget;
3. colli di bottiglia con evidenza;
4. modifiche e loro scope (globale, componente, opt-in diagnostico);
5. risultati prima/dopo;
6. regressioni verificate;
7. punti chiusi perché non necessari;
8. rischi e acceptance residue.

Evita valori di performance senza unità, metodo di misura o numero di campioni. Non presentare il wall time dell'automazione browser come input delay della pagina.

## Sinergie

- Usa `mcp-browser-automation` per rendere ripetibile il flusso dopo la diagnosi.
- Usa `mcp-grid-ui-debugger` quando la lentezza include un difetto geometrico specifico della griglia.
- Usa `mcp-code-reviewer` per il consolidamento statico del change set.
- Usa `mcp-handoff-pack` per un handoff finale con evidenze e rischi residui.
- Usa `mcp-docs-navigator` per indicizzare le decisioni stabili; usa memoria solo come contesto, mai come fonte autoritativa.