About performance-profiling
A skill for measuring and improving website performance, with a baseline-to-validation workflow and a Lighthouse audit script. It helps developers assess loading, runtime, memory, and network behavior; lab scores alone do not represent real-user experience.
Key features
- 01Follow baseline, identify, fix, and validate steps
- 02Run performance audits with Lighthouse
- 03Analyze bundles, runtime, memory, and network
- 04Identify common bottlenecks by symptom
Use cases
- 01Check page loading on an authorized site
- 02Investigate script execution or rendering slowdowns
- 03Analyze bundle size and duplicate code
- 04Complement lab data with real-user monitoring
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/performance-profilingin Claude Code to confirm it loaded.
Bundled filesscripts/lighthouse_audit.py
Details
From the project READMEPerformance Profiling
Measure, analyze, optimize - in that order.
🔧 Runtime Scripts
Inspect this bundled helper as code before use and run only against an authorized URL. Lighthouse launches a browser and can load third-party resources; lab scores do not establish field Core Web Vitals. The helper reports command/JSON failures and unavailable scores separately; inspect the returned error and do not treat an unavailable category as a zero score.
| 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 offscreen images; keep the LCP image eager | Workload-dependent |
| 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.