# App Performance Budget Planner

Set measurable performance budgets for an AI-built app and turn them into architecture choices, tests, and regression gates.

## Prompt

You are a web performance engineer who specializes in practical performance budgets for small product teams.

Inputs:
1. App, users, devices, and critical journeys: {{app_context}}
2. Current stack, hosting, assets, and data flows: {{technical_context}}
3. Baseline measurements or observed performance problems: {{baseline}}
4. Business and user experience priorities: {{performance_goals}}
5. Tooling, accessibility, budget, and implementation constraints: {{constraints}}

Do the following:
1. Define user-centered performance goals for the critical journeys, including appropriate loading, interaction, stability, API, asset, and runtime measures.
2. Translate the goals into page or route budgets for JavaScript, CSS, images, fonts, requests, server response, data volume, and expensive client work, stating assumptions when no baseline exists.
3. Identify likely budget risks in the supplied architecture, including large dependencies, hydration, repeated fetching, unbounded lists, media, third-party scripts, and inefficient database access.
4. Recommend prioritized changes with expected impact, effort, measurement method, and quality tradeoffs, preserving accessibility and required functionality.
5. Produce a performance budget table, critical-journey test plan, local and CI checks, monitoring events, regression thresholds, and a staged optimization backlog. Do not optimize synthetic scores while ignoring real-user outcomes.

## Best for

Vibe coders who want objective performance limits before generated features and dependencies make an app slow.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Describe real devices and network conditions.
- Measure critical journeys before setting final budgets.
- Include server, data, media, and client costs.
- Add regression checks to CI after optimization.

## Customization tips

- Budget third-party scripts explicitly.
- Use real-user metrics alongside lab tests.
- Preserve accessibility during loading optimizations.
- Prioritize the largest user-visible bottleneck first.

## Example input

App: Mobile-first local events directory built with Next.js, Supabase, and a map library. Users often browse on mid-range Android phones over 4G. Baseline: event list LCP 4.1 seconds, 620 KB JavaScript, 2.8 MB images, and map loads on every visit. Goal: event details should feel fast and search should respond promptly. Constraints: map remains available but not essential on initial list view; images are uploaded by organizers; free-tier monitoring preferred.

## Example output

The budget caps initial route JavaScript, responsive image bytes, API response time, and search interaction latency, with targets tested on a mid-range mobile profile. The plan lazy-loads the map after explicit user intent, generates upload variants, limits list payloads, and removes a duplicated date library before cosmetic micro-optimization. CI checks bundle size and Lighthouse thresholds, while real-user metrics capture LCP, INP, route, device class, and map activation rate.