What this prompt does
This prompt turns ChatGPT into a structured performance audit session for a specific application. Rather than asking vague questions like "how do I make my app faster," the template forces you to supply concrete symptoms and current metrics upfront — which means the AI can reason about trade-offs rather than give generic advice. The five numbered investigation areas in the template are not arbitrary; they map to the most common performance failure modes across web applications, from ORM misuse to frontend render blocking.
What makes it effective is the [current_metrics] and [target_metrics] pairing. By anchoring the conversation to real numbers (e.g., p95 API latency at 1.4s, target 300ms), you get prioritized fixes rather than a laundry list. The prompt also requests expected improvement per optimization, which gives you a rough ROI signal before you spend hours implementing anything.
When to use it
- Your Laravel or Django app is under load and slow queries are showing up in Telescope or the slow query log but you are not sure which ones matter most.
- A React or Vue bundle has ballooned past 500KB and Lighthouse scores are dropping.
- An API endpoint that was fine at 100 requests per hour is now timing out at 10,000.
- You have added Redis or Memcached but are not confident your cache invalidation strategy is correct.
- A background job is consuming memory across its lifetime and the worker eventually crashes.
- You are preparing for a traffic spike (product launch, press coverage) and want to pre-emptively tighten the stack.
Example output
Given application_type: Laravel REST API, symptoms: p95 response time 2.1s on /api/orders, tech_stack: Laravel 11, MySQL 8, Redis, caching_layer: Redis:
1. N+1 issue found in OrderController@index
- Fix: eager load with ->with(['customer', 'items.product'])
- Expected gain: ~60% query reduction, est. 800ms saved
2. Missing composite index on orders(user_id, created_at)
- Fix: CREATE INDEX idx_user_created ON orders(user_id, created_at);
- Expected gain: full-table scan to index scan, est. 400ms saved
3. Redis cache for /api/orders (per user, 60s TTL)
- Fix: Cache::remember("orders:{$userId}", 60, fn() => ...)
- Expected gain: cache-hit path drops to ~40ms
Pro tips
- Fill
[symptoms]with actual log output or profiler traces, not your guess. "Slow" is useless. "EXPLAIN shows 80K rows examined on the orders table" is actionable. - If your
[tech_stack]includes an ORM (Eloquent, ActiveRecord, SQLAlchemy), name it explicitly — the AI will tailor N+1 detection to that ORM's syntax rather than raw SQL advice. - Run this prompt once per layer in isolation. One session for database, a separate session for frontend. Mixing all five areas in one response often produces shallow coverage of each.
- After getting the fixes, paste the actual migration or code back into a follow-up message and ask ChatGPT to review it for correctness before deploying — it will catch index naming collisions and cache key collision risks.
- Set realistic
[target_metrics]. Asking for a 10x improvement on a well-tuned stack will skew the output toward impractical architectural rewrites. Incremental targets (e.g., p95 from 2.1s to 500ms) produce grounded, implementable suggestions.
