What this prompt does
This prompt runs a comprehensive frontend performance audit for the app you describe and returns a prioritized, actionable fix list. You provide [app_description], [framework], [bundler], [hosting], your [current_score], and the [pain_point] that bothers you most, and it audits Core Web Vitals, bundle size, assets, network/caching, rendering, and monitoring.
The structure works because "make it faster" is useless — real performance work is a sequence of specific, measurable fixes. The prompt splits the audit into LCP, INP, and CLS, then into bundle, asset, and caching layers, mirroring how Core Web Vitals are actually chased. It analyzes your [top_n_deps] heaviest dependencies, recommends code-splitting and lighter library substitutions, and enforces a performance budget using your [js_budget] and [css_budget]. Critically, it sorts every fix by impact so you know what to ship first.
When to use it
- An app feels sluggish and you need a prioritized plan instead of scattered tips.
- Your Lighthouse or Core Web Vitals scores are dropping and you need to find the cause.
- A specific
[pain_point]— like a slow product page on 4G — is hurting conversions. - Your bundle has grown and you need to find and replace the
[top_n_deps]heaviest dependencies. - You're setting performance budgets (
[js_budget],[css_budget]) and want CI gates to enforce them. - You need to brief a team on what to fix first, ranked by expected performance gain.
Example output
You get an audit broken into the same areas you'd work through manually: a Core Web Vitals section with concrete LCP, INP, and CLS fixes (preloading, scheduler.yield(), explicit media dimensions); a bundle analysis naming your [top_n_deps] heaviest packages with a substitution table; asset, network, and rendering recommendations; a monitoring section with budgets and Lighthouse CI gates; and a final prioritized action plan sorted high/medium/low impact with an estimated gain per fix.
Pro tips
- Name your real
[framework]and[bundler]; the code-splitting and tree-shaking advice is specific to them. - Put your actual
[current_score](mobile and desktop) so the model knows how far you have to climb. - Make
[pain_point]concrete — a named slow page beats "it's slow" and focuses the whole audit. - Set
[top_n_deps]based on how deep you want the dependency analysis to go. - Use
[js_budget]and[css_budget]as real targets so the monitoring and CI section produces enforceable gates. - Work the prioritized plan top-down; ship the high-impact fixes first and re-measure before tackling the rest.
