Bottleneck
The single resource that limits system throughput, such that improving anything else produces no gain.
At any moment a system has exactly one binding constraint. Effort spent elsewhere yields nothing — which is the most commonly ignored fact in performance work, and the reason optimisation projects frequently deliver no measurable improvement.
Finding it: look for the resource nearest saturation, and for the queue that is growing. Utilisation alone can mislead — a resource at 100% might be the bottleneck or might simply be efficiently busy — so the signature to look for is queueing: requests waiting for that resource while others are idle.
Candidates in rough order of frequency: database (query plans, locks, connections), external service latency, connection or thread pool limits, disk I/O, network bandwidth or round trips, lock contention, and only then CPU.
Two properties that shape how the work goes:
The bottleneck moves. Fix the database and the constraint becomes the application's serialisation, or the network. Performance work is iterative by nature, and a plan that assumes one fix will suffice is wrong.
Only the bottleneck's improvement counts. This is the argument for measuring first and for resisting the optimisation that is easiest to reach for.