performance-audit-edho-ferdian

Diagnose and fix performance issues through measured profiling, budgets, and re-measured deltas.

2|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/edhoferdian/EEF --skill performance-audit-edho-ferdian-edhoferdian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: performance-audit-edho-ferdian
Source: https://github.com/edhoferdian/EEF/tree/main/.agents/skills/performance-audit-edho-ferdian
Command: npx skills add https://github.com/edhoferdian/EEF --skill performance-audit-edho-ferdian-edhoferdian

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Performance complaints like "the app feels slow" are usually handled with guesswork. This Skill replaces guessing with a measure-then-fix workflow: it runs real tooling (Lighthouse, bundle analyzers, heap-snapshot diffing, Node/browser profilers, EXPLAIN ANALYZE, flame graphs) to capture a baseline, diagnoses against Core Web Vitals budgets and algorithmic-complexity patterns, applies a targeted fix, then re-measures to prove the delta. ## Core Features & Use Cases - Baseline measurement before diagnosis: Runs Lighthouse, source-map-explorer, webpack-bundle-analyzer, Node --prof, heap-snapshot pairs, or EXPLAIN ANALYZE depending on the target (page, bundle, function, memory, query, or API endpoint). - Budget-driven diagnosis: Checks measurements against a Core Web Vitals budget table (LCP < 2.5s, TBT < 200ms, bundle < 200KB gzip), an algorithmic-complexity table, and leak-pattern catalogues, citing a concrete number for every finding. - Fix and re-measure loop: Applies the smallest behavior-preserving fix, optionally benchmarks 2-4 fix variants against each other, then re-runs the identical measurement and reports a delta table with PASS/FAIL verdicts per metric. - Backend and database coverage: API benchmark mode (p50/p95/p99 serial and concurrent), constraint-vs-queue analysis, Postgres plan reading, slow-query-log workflow, connection-pool saturation diagnosis, runtime N+1 confirmation, and flame-graph profiling for Python (py-spy), Go (pprof), and Java (async-profiler). - Use Case: A user reports "kenapa halaman ini lemot". The Skill runs Lighthouse for a baseline, finds LCP at 2.9s against a 2.5s budget, traces it to an unoptimized hero image and a sequential await chain, fixes both, re-runs Lighthouse, and saves a report showing the measured delta. ## Quick Start Ask the assistant to run a performance audit on the slow page or endpoint, measure a baseline, fix the bottleneck, and re-measure the improvement.

Frequently Asked Questions about performance-audit-edho-ferdian

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose why my web app is slow?

Run a baseline measurement first with Lighthouse or a profiler rather than reading code and guessing. Then diagnose the numbers against Core Web Vitals budgets (LCP under 2.5s, TBT under 200ms), apply a targeted fix, and re-measure with the same tool to confirm the delta.

How to find a memory leak in a React or Node application?

Take two heap snapshots bracketing the suspected leaking action repeated multiple times, force garbage collection before the second snapshot, then use the Comparison view to find objects allocated but not freed. Look for detached DOM nodes, growing listener counts, and closures retaining large objects.

What is the difference between this audit and a static code review for performance?

A static review flags patterns that look slow, like a query inside a loop, with a confidence label but no measurement. This audit actually runs the code, captures query counts, latency, or heap deltas, and confirms or refutes the suspicion with real numbers.

How do I confirm an N+1 query problem at runtime?

Enable per-request query logging and count queries for one logical action. If the count scales linearly with result size (10 items producing 11 queries), the N+1 is confirmed; a constant count means eager loading already resolved it. After fixing, re-measure until the count drops to the theoretical minimum.

Can I profile Python, Go, or Java backends, not just Node?

Yes. Use py-spy for Python (with --idle for wall-clock sampling), Go's built-in pprof with block and mutex profiles, and async-profiler for Java with cpu, wall, alloc, and lock events. Choose on-CPU versus off-CPU profiling based on whether the slowness is compute or waiting.

Why did my optimization not improve end-to-end latency?

The optimized component was likely not the actual constraint. A queue in front of a stage often means an upstream stage or shared resource is the real bottleneck, so speeding up a non-constraint only makes it wait faster. Re-measure end-to-end metrics after every fix, not just component-level numbers.