Anthony Bordonaro

Performance Audit Prompt

Prompt
promptsperformanceweboptimization

Performance work is easy to do wrong — you optimize the thing that's fast and ignore the thing that's slow. You add React.memo to a component that renders once while a 200KB dependency ships on every page. This prompt forces a systematic audit: measure first, identify the real bottlenecks, then suggest fixes in priority order.

The prompt

Perform a performance audit on this project. Analyze the following areas and produce a prioritized list of optimizations.

## Areas to analyze

### 1. Bundle size
- Run the build and check output sizes (`npm run build`)
- Read the build output and bundler config to understand code splitting behavior
- Identify the largest dependencies. For each one over 50KB gzipped: is the full package used, or just a small part? Is there a lighter alternative or native API?
- Check for accidental full-library imports (e.g., `import _ from 'lodash'` vs `import debounce from 'lodash/debounce'`)
- Look for code that could be dynamically imported (heavy components, libraries only used on specific pages)
- Check for duplicate dependencies (different versions of the same package in the bundle)

### 2. Rendering performance
- Identify components that re-render on every parent render despite stable props (but only flag this when the component is expensive — don't suggest React.memo on everything)
- Check for inline object/array/function creation in JSX that defeats memoization of child components
- Look for expensive computations in render paths that should be memoized
- Check for layout thrashing patterns (reading DOM measurements then writing styles in a loop)

### 3. Data loading
- How is data fetched? (SSG, SSR, client-side, streaming)
- Are there waterfall requests? (component A fetches, then component B fetches based on A's result, when both could be parallelized)
- Is data over-fetched? (fetching 50 fields when the page uses 5)
- For static sites: is anything fetched client-side that could be fetched at build time?

### 4. Assets
- Images: Are they in modern formats (WebP/AVIF)? Using responsive sizing (srcset or next/image)? Lazy loaded below the fold? Do they have explicit width/height to prevent CLS?
- Fonts: Are they loaded efficiently? (preloaded, font-display: swap, subset to used characters)
- Third-party scripts: Are analytics, chat widgets, or other third-party scripts blocking the main thread? Can they be loaded with async/defer or after interaction?

## Output format

### High impact (do first)
1. **[Issue]** — [What's slow and why]. Fix: [specific action]. Expected improvement: [estimate if possible].

### Medium impact (next iteration)
1. **[Issue]** — [What's suboptimal]. Fix: [specific action].

### Low impact (nice to have)
1. **[Issue]** — [Minor optimization]. Fix: [specific action].

### Already good
- [List things that are already well-optimized, so the developer knows what NOT to touch]

## Rules
- Measure before suggesting. Don't recommend dynamic imports for a 2KB component.
- Prioritize by user-perceived impact: LCP, INP, CLS. Not by developer aesthetics.
- Be specific about the fix. "Optimize images" is useless. "Convert hero.png (1.2MB) to WebP and add width/height attributes to prevent CLS" is actionable.
- Don't recommend micro-optimizations that save milliseconds. Focus on changes that move metrics by 100ms+.
- If the project is already fast, say so. Not every project needs optimization.
- Only report what you can verify from the code and build output. Don't speculate about server configuration, CDN settings, or HTTP headers you can't see.

When to use it

  • Before a launch — catch the obvious performance issues
  • After adding a heavy feature or dependency — check the bundle impact
  • When users report slowness — get a structured investigation instead of guessing
  • Quarterly check-in — prevent performance from degrading gradually

When NOT to use it

  • On a prototype or MVP — performance doesn't matter until you have users
  • When you already know the bottleneck — just fix it
  • When you need real-user metrics — this is a code-level audit, not a Lighthouse replacement. Pair it with actual Core Web Vitals data.

Tips

  • For Next.js projects, next build output includes page sizes and first-load JS. That's your starting point.
  • The "Already good" section is important — it prevents the team from wasting time optimizing things that don't need it.
  • For deeper dependency analysis, pair this with the Dependency Audit prompt which also checks for unused and outdated packages.
  • Third-party scripts are often the biggest performance problem and the easiest to overlook because they're not in your bundle analysis.
Back to AI Toolkit