performance-audit
Structured performance audit covering Core Web Vitals, bundle size, memory profiling, and runtime efficiency.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Structured performance audit covering Core Web Vitals, bundle size, memory profiling, and runtime efficiency.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Rules and strategies for managing agent context window size, avoiding bloat, and preserving signal-to-noise ratio.
Standard patterns for error handling, retry logic, circuit breakers, and graceful degradation.
Detect and remove contradictions across agent policies before execution.
Multi-step tool workflows via code orchestration to reduce latency, context pollution, and token overhead.
Bind project-specific prompts to local schema and workflow artifacts while keeping the harness core generic and globally reusable.
Operational session protocol for task-scoped leases, reconciliation, checkpoints, inspection, queue promotion, and handoff across long-running work.
| name | performance-audit |
| description | Structured performance audit covering Core Web Vitals, bundle size, memory profiling, and runtime efficiency. |
Provide a structured performance audit procedure for web applications, covering load performance, runtime efficiency, and resource usage.
Run Lighthouse in both mobile and desktop modes:
chrome-devtools → lighthouse_audit (device: "mobile", mode: "navigation")
chrome-devtools → lighthouse_audit (device: "desktop", mode: "navigation")
| Metric | Target | Tools |
|---|---|---|
| LCP (Largest Contentful Paint) | < 2.5s | Lighthouse, Performance trace |
| INP (Interaction to Next Paint) | < 200ms | Performance trace |
| CLS (Cumulative Layout Shift) | < 0.1 | Lighthouse, Performance trace |
| FCP (First Contentful Paint) | < 1.8s | Lighthouse |
| TTFB (Time to First Byte) | < 800ms | Network panel |
| Check | Target | How |
|---|---|---|
| Total JS bundle (gzipped) | < 200 KB (initial load) | npm run build + analyzer |
| Largest dependency | Flag > 50 KB gzipped | Bundle analyzer |
| Tree-shaking | No unused exports in bundle | Build output analysis |
| Code splitting | Route-level chunks, not monolith | Build output analysis |
| Duplicate dependencies | Zero duplicates | npm ls --all or analyzer |
Use Chrome DevTools Performance trace:
chrome-devtools → performance_start_trace (reload: true, autoStop: true)
| Check | Target |
|---|---|
| Long tasks (> 50ms) | Identify and split or defer |
| Layout thrashing | No forced synchronous layouts |
| Memory leaks | Heap snapshot comparison (before/after interaction cycle) |
| Animation jank | 60fps for all animations |
| Event listener count | No unbounded growth |
chrome-devtools → list_network_requests
| Check | Target |
|---|---|
| Total requests on load | < 50 |
| Uncompressed assets | All text assets gzipped/brotli |
| Missing cache headers | Static assets have Cache-Control |
| Render-blocking resources | Minimize or defer |
| Image optimization | WebP/AVIF, responsive srcset, lazy loading |
chrome-devtools → take_memory_snapshot (filePath: "baseline.heapsnapshot")
# Perform user interaction cycle
chrome-devtools → take_memory_snapshot (filePath: "after-interaction.heapsnapshot")
Compare snapshots for:
systematic-debugging — for diagnosing specific performance issuestesting-policy — include performance benchmarks in CIcompletion-gate — performance regressions block the gate