What should you measure when an application is slow?

Short answer

Slowness is not a single problem: first describe which action is slow, for which user and under what conditions, then measure the browser, server, database and external services separately. Scaling up the server without measuring brings temporary relief but does not fix the cause.

Slowness is not a single problem

Initial page load, an API request, report generation and bulk data transfer can have different bottlenecks. First describe which task is slow, for which users and under what conditions.

Measurement order

Separate browser network timings from server processing time. Then examine the distribution of database query times, external service calls and background jobs. Track slower-user percentiles as well as averages.

Avoid guessing at the solution

A larger server may offer temporary relief while unnecessary queries or unbounded lists remain. Adding caching without a clear invalidation policy can introduce inconsistent data.

What to record during measurement

For each slow example, record the action name, user role, data volume, time, device and connection details and the request ID. If browser, application and database times can be matched by the same ID, the bottleneck becomes evidence instead of a guess. Do not write personal data or access keys to logs.

What consulting should deliver

Ask for a reproducible case, baseline measurements, evidence of the bottleneck and a before-and-after comparison. Define success for a specific task and data volume rather than accepting a vague promise of improvement.

Frequently asked questions

Two questions we are often asked on this topic.

Does scaling up the server solve the problem?

Sometimes temporarily; but if unnecessary queries or unbounded listings continue, the cost rises and the problem stays. Measuring first and then making targeted changes lasts longer.

Is adding a cache always a good idea?

No. If it is not defined which data becomes invalid and when, a cache can show inconsistent data. First measure the source of the slowness, then decide whether a cache is really needed.