What this prompt does
This prompt produces a prioritized performance optimization plan for a React app, grounded in your actual problems rather than guesswork. It audits unnecessary re-renders (React.memo, useMemo, useCallback), adds code splitting with React.lazy, virtualizes large lists, optimizes images, analyzes the bundle, offloads heavy computation to a Web Worker, adds Suspense boundaries, and proposes a Service Worker caching strategy — all tied to before/after targets for LCP, FID, and CLS, with a Profiler usage guide.
The variables anchor the plan in reality. [performance_issues] describes the symptoms (slow load, janky scrolling, large bundle), [app_details] gives context, and the rest target specific fixes: [split_targets] are routes to lazy-load, [large_lists] are the components to virtualize with [virtualization_lib], and [heavy_computation] is what moves to a Web Worker. Because the prompt insists on working from real Profiler data and tying each fix to LCP and CLS targets, the effort stays honest — you address the unnecessary re-renders and oversized bundles that usually cause slowness, with list virtualization typically the single biggest win on data-heavy screens.
When to use it
- Diagnosing a React app that feels slow without knowing the root cause
- Prioritizing performance work so you fix the costly problems first
- Virtualizing lists rendering thousands of rows that jank on scroll
- Code-splitting heavy routes to shrink the initial bundle
- Moving CPU-heavy work (parsing, aggregation) off the main thread
- Tying optimization effort to measurable Core Web Vitals targets
Example output
You get a prioritized plan: a re-render audit naming likely offenders, code-splitting recommendations for your [split_targets], a virtualization approach for [large_lists] using [virtualization_lib], image optimization steps, a bundle analysis with tree-shaking suggestions, a Web Worker plan for [heavy_computation], Suspense boundary placement, and a Service Worker caching strategy. Each item carries before/after targets for LCP, FID, and CLS, plus a guide to using the React DevTools Profiler to confirm the wins are real rather than assumed.
Pro tips
- Fill
[performance_issues]from real measurements (5s load, 2MB bundle), not impressions — the plan is only as good as the symptoms you feed it - Start with
[large_lists]virtualization if you have data-heavy screens; it's usually the biggest single win for the least risk - Don't carpet-bomb with React.memo; the audit should identify specific re-render hotspots, and over-memoizing adds its own overhead
- Pick a
[virtualization_lib]you'll maintain (TanStack Virtual is solid) rather than rolling your own windowing - Validate each fix against the LCP/CLS targets in the Profiler before moving on, so you don't chase premature optimizations
- Be precise about
[heavy_computation]; only genuinely blocking work belongs in a Web Worker, since the messaging overhead isn't free
