Performance optimization prompts for ChatGPT, Claude and Codex

The best performance optimization prompts start with a measurement, not the code: give the model a profile, a query plan or before and after timings, name the metric you care about, and ask it to rank fixes by expected impact. Below are 13 performance optimization prompts for ChatGPT, Claude, Claude Code and Codex for finding bottlenecks, speeding up backend code, fixing Core Web Vitals and keeping performance from regressing.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{metric:p95 latency}} means p95 latency unless you change it.

Three habits matter more than the wording:

• Measure first. A profile or a timing table points the model at the real bottleneck. Without one, it guesses, and the guesses are usually small loop tweaks.
• Name one metric and a target. "p95 under 300 ms" gives the model a way to say when to stop.
• Measure again after every change. Keep the same workload and machine so the numbers are comparable.

In an agent, ask it to run the profiler, benchmark or load test itself and report before and after numbers.

Related collections cover nearby ground: the debugging prompts include finding why one endpoint is slow and fixing N+1 queries, and the SQL prompts cover query plans and indexes. This page is about measuring and improving performance across a whole system.

How do you find what is actually slow?

1. Write a measurement plan before optimizing

Optimizing without a baseline is how teams spend a week and ship nothing measurable.

I want to make {{target:the search page}} faster. Help me write a
measurement plan before I change any code.

Context: {{context:Node.js API with PostgreSQL, about 200 requests per second at peak}}

Give me:
1. The one metric that best reflects what users feel, and the percentile
   to track (median alone hides slow requests).
2. A realistic workload to measure with, and how to reproduce it.
3. How to record a baseline, including how many runs and how to judge
   noise between runs.
4. A target and a stopping rule.
5. What to profile first, and with which tool.

2. Read a flame graph or CPU profile

Profilers produce more data than anyone can read. Node's --cpu-prof flag starts the V8 CPU profiler and writes the profile to disk before exit; load the .cpuprofile file into the Chrome DevTools Performance panel, which shows it as a flame chart, and copy the top functions.

Here are the top functions from a CPU profile of {{program:our API under load}},
with self time and total time.

{{profile_summary}}

Relevant code:
{{code}}

1. Which functions are the real bottleneck, and which only look busy
   because they call something slow?
2. For the top two, explain why they are expensive.
3. Suggest fixes ranked by expected gain versus effort.
4. Tell me what to measure to confirm each fix worked.

3. Review a benchmark for mistakes

A bad microbenchmark can prove almost anything. This catches the common traps before you trust a number.

Review this {{language:JavaScript}} benchmark before I trust its results.

{{benchmark_code}}

Results:
{{results}}

Check for: missing warmup, work the compiler or runtime can skip because
the result is unused, too few iterations, measuring setup along with the
work, inputs that are unrealistically small or cached, and run-to-run
variance. Rewrite the benchmark to fix what you find and tell me how to
report the result (median, spread, number of runs).

How do you speed up backend code with AI?

4. Find algorithmic complexity problems

The biggest wins usually come from doing less work, not doing the same work faster.

Review this {{language:Python}} code for time and space complexity.

Typical input size: {{size:10,000 items}}, growing to {{max_size:1 million}}.

{{code}}

For each function, give its complexity in big-O terms and point to the
line that causes it. Flag nested loops over the same data, repeated
lookups in lists that should be sets or maps, and sorting inside loops.
For each problem, show the faster version and the new complexity.

5. Design a cache for a slow read

Caching fixes slow reads and creates stale data bugs. This prompt makes the trade-offs explicit.

I want to cache {{what:the product details response}} to cut latency.

How the data is read: {{reads:about 50 reads per write}}
How it changes: {{writes:edited by admins a few times a day}}
How stale it may be: {{staleness:up to 60 seconds is fine}}
Stack: {{stack:Node.js, PostgreSQL, Redis available}}

Recommend where to cache (in process, shared cache, HTTP cache or CDN),
the cache key, the expiry, how to invalidate on writes, and how to stop
many requests from rebuilding the same entry at once when it expires.
List what can go wrong and how I would notice.

6. Move work out of the request path

A request that sends email, resizes images or calls three services in a row is slow by design.

Here is a request handler that is slower than it should be.

{{code}}

1. List every I/O call it makes, in order, and whether each one depends
   on the result of an earlier one.
2. Show which calls can run concurrently and which can be batched into a
   single round trip.
3. Identify work the user does not need to wait for, and how to move it
   to a background job with {{queue:our existing job queue}}.
4. Rewrite the handler, keeping the same response and error behavior.

7. Cut memory use and allocations

High memory use slows programs through garbage collection pauses and swapping, even before anything crashes.

This {{language:Go}} code uses more memory than expected when processing
{{workload:a 2 GB log file}}.

{{code}}

Memory profile or observations:
{{profile}}

Find where memory is allocated in hot paths, data that is loaded fully
when it could be streamed, copies that could be avoided, and objects kept
alive longer than needed. Rewrite the worst parts and estimate the
memory saved for each change.

8. Size a connection pool and timeouts

Under load, many "slow" services are really waiting for a connection. This uses your numbers instead of defaults.

Help me size the database connection pool and timeouts for this service.

Instances: {{instances:4}}
Peak requests per second: {{rps:300}}
Typical query time: {{query_time:15 ms}}, slow queries up to {{slow_query:2 s}}
Database connection limit: {{db_limit:100}}
Current settings:
{{settings}}

Estimate how many connections each instance needs at peak, check the total
against the database limit, and recommend pool size, acquire timeout and
query timeout. Explain what users will see if the pool runs out, and which
metric to watch.

How do you fix Core Web Vitals with AI?

According to web.dev, a good page has Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of page loads. Start from field data where you have it, then reproduce in the lab.

9. Break down a slow LCP

web.dev's LCP guide splits LCP into four subparts: time to first byte, resource load delay, resource load duration and element render delay. Knowing which one is large tells you what to fix.

My page's LCP is {{lcp:4.1 seconds}} on mobile. The LCP element is
{{element:the hero image}}.

Timing for each LCP subpart from DevTools or my monitoring:
{{subparts}}

Page HTML head and the LCP element markup:
{{html}}

Tell me which subpart is the main problem and why. Suggest fixes for that
subpart first (for example, server response, discovering the image earlier,
fetchpriority, image size and format, render-blocking CSS or JavaScript).
Rank fixes by expected impact on LCP.

10. Fix a slow interaction (INP)

web.dev's INP guide breaks each interaction into input delay, processing duration and presentation delay. The fix depends on which phase is slow.

Clicking {{interaction:the "Add to cart" button}} feels slow. INP for this
interaction is {{inp:450 ms}}.

Performance panel summary (long tasks, event handlers, rendering):
{{trace_summary}}

Event handler code:
{{code}}

Identify which phase is slow: input delay, processing duration or
presentation delay. Then suggest fixes for that phase, such as breaking up
long tasks, showing visual feedback before heavy work, deferring work that
is not needed for the next frame, or reducing rendering cost.

11. Remove layout shifts (CLS)

Layout shifts come from a short list of causes, which web.dev lists in its CLS guide: images without dimensions, ads, embeds and other late-loaded content, web fonts, and animations.

My page has a CLS of {{cls:0.28}}. These elements shift:
{{shifting_elements}}

Relevant HTML and CSS:
{{markup}}

For each shift, name the cause and give the fix: width and height or
aspect-ratio on media, reserved space for embeds and ads, placing late
content below the fold, font fallback settings, or transform-based
animation. Show the corrected markup or CSS.

How do you keep performance from regressing?

12. Write a load test with pass and fail thresholds

A load test without thresholds produces charts nobody reads. Grafana k6 supports thresholds such as an error rate below 1% and p95 duration below a set number of milliseconds, which fail the run when crossed.

Write a {{tool:k6}} load test for {{endpoint:GET /api/search?q=shoes}}.

Traffic shape: {{shape:ramp to 200 virtual users over 2 minutes, hold 5 minutes}}
Goals: {{goals:p95 under 300 ms, under 1% errors}}
Auth: {{auth:bearer token from an environment variable}}

Include realistic think time and varied inputs so caches don't make the
results look better than production. Add thresholds for the goals so the
run fails when they are missed. Explain how to read the summary output.

13. Add a performance budget to CI

Performance erodes one small change at a time. A budget in CI makes each regression visible in the pull request that caused it.

Help me add a performance budget check to our CI for {{project:a Next.js marketing site}}.

What to guard: {{budgets:JavaScript bundle size per route, LCP in a lab run, API p95 from a short load test}}
CI system: {{ci:GitHub Actions}}

For each budget, suggest the tool, a realistic starting threshold based on
today's numbers, and how to keep the check stable (fixed hardware, several
runs, comparing against the main branch). Write the CI job and explain how
a developer should respond when it fails.

What should you check before trusting a speedup?

For deeper work on web performance, the Core Web Vitals skill guide and the performance optimization skill guide cover skills that apply these checks automatically.

Turn your favorite one into a skill

If you profile often, the measurement plan and flame graph prompts make good skills, since Claude Code or Codex can then follow the same measure, change, measure loop every time. Paste one into the free SKILL.md generator to get a valid SKILL.md. Once your pipeline runs the budget check, the CI/CD prompts help keep it fast.

Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks like {{metric:p95 latency}} stay fillable, Cmd+K finds any prompt, and skills you save there install into Claude Code or Codex with one command.