
Performance Profiling
Measure Core Web Vitals and runtime bottlenecks with a measure-first workflow and optional Lighthouse automation before optimizing bundles or UI.
Overview
Performance Profiling is an agent skill most often used in Ship (also Launch SEO) that enforces measure-analyze-optimize workflows around Core Web Vitals and targeted profiling tools.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill performance-profilingWhat is this skill?
- 4-step workflow: Baseline → Identify → Fix → Validate
- Core Web Vitals thresholds for LCP, INP, and CLS with good versus poor bands
- Stage-aware tooling table (local Lighthouse, Lighthouse CI, production RUM)
- Bundled `scripts/lighthouse_audit.py` for CLI Lighthouse runs
- Problem-to-tool map covering bundle analyzer, DevTools Performance, Memory, and Network
- 4-step profiling process: Baseline → Identify → Fix → Validate
- Core Web Vitals targets: LCP good under 2.5s, INP under 200ms, CLS under 0.1
Adoption & trust: 760 installs on skills.sh; 40.1k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are tempted to rewrite frontend code without baseline metrics, so optimizations miss the real LCP, INP, or bundle bottleneck.
Who is it for?
Indie builders shipping web UIs who need a disciplined vitals workflow from local dev through CI to production checks.
Skip if: Native mobile-only performance tuning or backend-only API latency work with no browser surface.
When should I use this skill?
User needs performance profiling, Core Web Vitals measurement, or Lighthouse or DevTools guided optimization—not guessing at fixes.
What do I get? / Deliverables
You capture a baseline, isolate the dominant issue with the right tool, ship a validated fix, and can re-run Lighthouse via the bundled audit script.
- Documented baseline metrics and identified bottleneck
- Validated post-fix measurement plan or Lighthouse audit output
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Performance profiling belongs on the Ship shelf because it gates release confidence through measured LCP, INP, and CLS—not speculative rewrites. Perf subphase fits the explicit Core Web Vitals targets, profiling workflow, and Lighthouse or DevTools tool matrix in the skill body.
Where it fits
Baseline bundle analyzer output after adding a heavy charting library.
Run the 4-step loop on a staging URL before tagging a release.
Confirm LCP and CLS meet "good" bands documented in the skill before publishing a marketing landing page.
Compare production RUM trends after a validated fix ships.
How it compares
Use as a structured profiling ritual instead of ad-hoc Lighthouse runs without baseline or validation steps.
Common Questions / FAQ
Who is performance-profiling for?
Solo developers shipping browser-based products who need Core Web Vitals discipline and clear tool choice across dev, CI, and production.
When should I use performance-profiling?
During Ship perf before release; during Build frontend when bundle size spikes; and during Launch SEO when organic rankings depend on passing LCP, INP, and CLS thresholds.
Is performance-profiling safe to install?
The Lighthouse script hits URLs you specify; review the Security Audits panel on this Prism page and avoid auditing sensitive staging without auth controls.
SKILL.md
READMESKILL.md - Performance Profiling
# Performance Profiling > Measure, analyze, optimize - in that order. ## 🔧 Runtime Scripts **Execute these for automated profiling:** | Script | Purpose | Usage | |--------|---------|-------| | `scripts/lighthouse_audit.py` | Lighthouse performance audit | `python scripts/lighthouse_audit.py https://example.com` | --- ## 1. Core Web Vitals ### Targets | Metric | Good | Poor | Measures | |--------|------|------|----------| | **LCP** | < 2.5s | > 4.0s | Loading | | **INP** | < 200ms | > 500ms | Interactivity | | **CLS** | < 0.1 | > 0.25 | Stability | ### When to Measure | Stage | Tool | |-------|------| | Development | Local Lighthouse | | CI/CD | Lighthouse CI | | Production | RUM (Real User Monitoring) | --- ## 2. Profiling Workflow ### The 4-Step Process ``` 1. BASELINE → Measure current state 2. IDENTIFY → Find the bottleneck 3. FIX → Make targeted change 4. VALIDATE → Confirm improvement ``` ### Profiling Tool Selection | Problem | Tool | |---------|------| | Page load | Lighthouse | | Bundle size | Bundle analyzer | | Runtime | DevTools Performance | | Memory | DevTools Memory | | Network | DevTools Network | --- ## 3. Bundle Analysis ### What to Look For | Issue | Indicator | |-------|-----------| | Large dependencies | Top of bundle | | Duplicate code | Multiple chunks | | Unused code | Low coverage | | Missing splits | Single large chunk | ### Optimization Actions | Finding | Action | |---------|--------| | Big library | Import specific modules | | Duplicate deps | Dedupe, update versions | | Route in main | Code split | | Unused exports | Tree shake | --- ## 4. Runtime Profiling ### Performance Tab Analysis | Pattern | Meaning | |---------|---------| | Long tasks (>50ms) | UI blocking | | Many small tasks | Possible batching opportunity | | Layout/paint | Rendering bottleneck | | Script | JavaScript execution | ### Memory Tab Analysis | Pattern | Meaning | |---------|---------| | Growing heap | Possible leak | | Large retained | Check references | | Detached DOM | Not cleaned up | --- ## 5. Common Bottlenecks ### By Symptom | Symptom | Likely Cause | |---------|--------------| | Slow initial load | Large JS, render blocking | | Slow interactions | Heavy event handlers | | Jank during scroll | Layout thrashing | | Growing memory | Leaks, retained refs | --- ## 6. Quick Win Priorities | Priority | Action | Impact | |----------|--------|--------| | 1 | Enable compression | High | | 2 | Lazy load images | High | | 3 | Code split routes | High | | 4 | Cache static assets | Medium | | 5 | Optimize images | Medium | --- ## 7. Anti-Patterns | ❌ Don't | ✅ Do | |----------|-------| | Guess at problems | Profile first | | Micro-optimize | Fix biggest issue | | Optimize early | Optimize when needed | | Ignore real users | Use RUM data | --- > **Remember:** The fastest code is code that doesn't run. Remove before optimizing. ## When to Use This skill is applicable to execute the workflow or actions described in the overview. ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing. #!/usr/bin/env python3 """ Skill: performance-profiling Script: lighthouse_audit.py Purpose: Run Lighthouse performance audit on a URL Usage: python lighthouse_audit.py https://example.com Output: JSON with performance scores Note: Requires lighthouse CLI (npm install -g lighthouse) """ import subprocess import json import sys import os import tempfile def run_lighthouse(url: str) -> dict: """Run Lighthouse audit on URL.""" try: with tempfile.Name