Debug a performance issue
Ranks the plausible causes of a slowdown by likelihood and names the measurement that confirms each one before you touch any code.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Forcing a named measurement per hypothesis before any fix stops the classic misdiagnosis loop — a confident fix for the wrong cause that costs a full deploy cycle to disprove.
- →Ranking hypotheses by likelihood, instead of listing every possible cause with equal weight, gives you an actual place to start rather than an undifferentiated checklist.
- →Labelling the suggested fix as provisional keeps the prompt honest about what it can and can't know about your system without having seen the real profiler output.
Part by part
- List the plausible causes ranked from most to least likely
- Ranking rather than listing. An unordered set of ten possibilities is the same as no answer when you have to choose what to investigate first.
- name the specific measurement or diagnostic
- The instruction that makes this a debugging prompt rather than a guessing one. Each hypothesis has to come with the thing that would falsify it.
- before proposing any fix for it
- Ordering is deliberate. Given a symptom, a model will offer a fix immediately, and a fix applied before a measurement is how performance work turns into folklore.
- labelled clearly as provisional until that measurement is actually taken
- Keeps the suggested fix honest about its own status, which matters when the output gets pasted into a ticket and read later as a conclusion.
- say so instead of picking one to sound decisive
- The guard against false confidence. Several unrelated causes producing identical symptoms is the normal case in performance work.
Common mistakes
Why is my app slow?With no symptoms and no stack, the answer is a list of generic causes — N+1 queries, missing indexes, too many renders — that applies to every application ever written and points at nothing.
How do I make this faster?Jumps straight to optimisation with no diagnosis, so you get changes applied to code that may not be the bottleneck. Time spent optimising the wrong thing is invisible and unrecoverable.
My page takes 3 seconds. Fix it.A single number without a breakdown cannot be diagnosed. Where those three seconds go — server time, transfer, parse, render — determines the entire investigation, and each points somewhere different.
Questions
Why insist on measurement before fixes?
Because performance intuition is unreliable even for people who wrote the code. A fix applied without a before-and-after cannot be shown to have helped, and the ones that appear to work often coincided with something else.
What symptoms are worth pasting?
When it is slow rather than just that it is: always or under load, first request or every request, one endpoint or all of them. Those distinctions eliminate more hypotheses than any amount of code does.
Can it diagnose without profiler output?
It can rank hypotheses and tell you which measurement to take, which is genuinely the useful half. It cannot tell you where the time actually went, and any answer claiming to is guessing.
What if the ranking is wrong?
That is fine, and expected. The value is a checked list of candidates with a falsification for each, so a wrong first guess costs one measurement rather than an afternoon of speculative changes.