At 9 a.m., the application feels perfectly normal.
By lunchtime, customers are complaining that pages take several seconds to load. Support reproduces the problem, but only on larger customer accounts. CPU looks acceptable, the servers are technically available and the most obvious error dashboards show nothing unusual.
One team suspects the frontend. Another wants to add application servers. Someone else notices that a database query that normally finishes quickly occasionally takes several seconds.
This is what makes application performance problems difficult: “the app is slow” describes the symptom, not the cause.
Poor performance can begin in the browser, application code, database, network, infrastructure or an external service. It can appear only under load, affect one workflow rather than the whole product, or exist primarily for users on slower devices and networks.
The first task is therefore not to make the application faster. It is to identify where the time is being spent.
AWS's Performance Efficiency guidance recommends taking a data-driven approach to performance, measuring different parts of the architecture rather than choosing optimizations based on assumption.
For Levelworks, this is the practical meaning of Performant App Health: important workflows should respond within acceptable limits under the conditions in which customers actually use them, and the team should be able to identify why performance changes when those limits are missed.
Here are ten of the most common reasons an application becomes slow.
Performance investigations become unproductive when everyone is discussing a different symptom.
“The app is slow” could mean:
Start with a specific workflow and measurement.
For web applications, Google's Web Vitals separates aspects of user experience such as loading performance through Largest Contentful Paint (LCP), responsiveness through Interaction to Next Paint (INP), and visual stability through CLS. Google also recommends field measurement because real users experience different devices, networks and interaction patterns that laboratory tests cannot completely reproduce.
For server-side workflows, look at request latency by endpoint and preferably distributions such as median, p95 or p99 rather than relying only on averages.
Once you can say:
Checkout p95 increased from 800 ms to 3.4 seconds after traffic passes 500 requests per minute.
you have something that can actually be investigated.
The database is one of the first places to investigate when application response time increases as data grows.
Common causes include:
A query that performs well against 20,000 rows may behave very differently after the table contains 20 million.
Consider an endpoint displaying 100 orders. If the application first retrieves the orders and then performs another query for each order's customer details, it may issue 101 database requests instead of one or two well-designed queries. This is the classic N+1 pattern.
PostgreSQL's current Performance Tips documentation recommends using tools such as EXPLAIN and EXPLAIN ANALYZE to understand how queries are actually executed rather than guessing from the SQL alone. It also notes that query performance depends on data distribution, planner statistics and execution choices.
Signs that the database deserves attention include response time increasing with account size, high database CPU or I/O, long-running queries, lock waits, or application traces showing most request time inside database spans.
[Internal Link: “How Database Performance Affects the Speed of Your App”]
A request can be slow even when every individual service is reasonably fast.
Imagine a dashboard that performs these calls sequentially:
User service 120 ms
Billing service 180 ms
Analytics service 350 ms
Notification service 110 ms
Recommendations 240 ms
Individually, none looks catastrophic.
If they sit sequentially on the critical path, however, latency accumulates.
This problem becomes more pronounced in applications where one backend request fans out into many internal services or where the frontend needs numerous API requests before it can render useful content.
Look for:
Chrome's DevTools Network panel can help web teams inspect individual requests and understand which resources or API calls are delaying a page.
The diagnostic question is simple:
How many network boundaries must this workflow cross before the user gets a useful result?
Not every task triggered by a user's request needs to finish before the application responds.
Suppose checkout performs the following before showing confirmation:
Some of those operations may be necessary to confirm the transaction.
Others could potentially happen afterwards.
When non-critical work sits synchronously on the request path, users inherit the latency of every operation.
This is particularly noticeable when tasks involve document generation, external notifications, analytics, image processing or large calculations.
A useful investigation is to draw the critical path and ask:
What must complete before the user can safely receive a response?
Moving appropriate work to asynchronous processing can reduce request time, but this should be a business decision rather than a blanket instruction to queue everything.
Applications often slow down before they fail.
CPU approaches its limit, requests wait longer for execution, memory pressure increases garbage collection, database connection pools fill up, or workers become occupied waiting for slow downstream services.
Eventually, the queue of waiting work creates latency even though the application remains technically available.
Container limits can also contribute. Kubernetes documents that CPU limits are enforced through throttling, while memory pressure can eventually lead to processes being terminated when configured limits are exceeded. Kubernetes: Resource Management for Pods and Containers
Do not look only at total infrastructure utilization.
Check the constrained resource that corresponds to the slow workflow:
An application with 40% average CPU can still have one critical service repeatedly hitting its CPU limit.
Sometimes nothing is inherently wrong with the code.
The workload has simply outgrown the resources available to it.
An application originally designed for 5,000 active users may now serve 100,000. A monthly reporting job may now process ten times as much data, while traffic peaks that were once unusual have become normal.
The symptoms often appear gradually:
AWS defines performance efficiency partly as maintaining efficient use of resources as demand and technology change, reinforcing that architecture and capacity assumptions need periodic review rather than being set permanently at launch. AWS Well-Architected: Performance Efficiency
Adding capacity may help, but first confirm that capacity is truly the bottleneck. Scaling inefficient code can otherwise become an expensive way to postpone the real fix.
An application may be fast internally and still feel slow because an external provider sits on the critical path.
Common examples include:
If checkout waits three seconds for a payment provider, optimizing your own controller from 150 ms to 80 ms will barely change what the customer experiences.
Distributed tracing is particularly useful here because it can show how much of a request's total duration belongs to internal processing versus downstream dependencies.
Also examine whether the dependency must remain synchronous.
A slow payment authorization probably cannot simply be postponed.
A delayed analytics event often can.
Performance investigations should therefore separate latency you own directly from latency introduced by systems you depend on.
Backend response time can look excellent while users still describe the application as slow.
The browser may be downloading large JavaScript bundles, rendering complex interfaces, decoding oversized images or spending too much time running JavaScript on the main thread.
This is particularly visible on lower-powered devices.
Google's Web Vitals guidance separates loading performance from responsiveness for exactly this reason. LCP reflects loading experience, while INP measures how responsive a page is to user interactions.
Frontend causes can include:
If server-side traces show a request completing quickly but users still wait several seconds before they can see or interact with the result, the bottleneck may have moved beyond the server.
Real-user data matters because your development machine is rarely representative of every customer's device.
Applications often repeatedly calculate or retrieve information that changes infrequently.
Examples include:
Caching can reduce the amount of repeated work, but its absence is not the only performance problem.
Poor cache design can also hurt performance.
A cache with an extremely low hit rate still sends most work to the underlying system. A large number of keys expiring simultaneously may generate a burst of database requests, while caching at the wrong layer may provide very little benefit.
The key diagnostic question is not:
Are we using a cache?
It is:
Are repeated expensive operations actually being avoided?
Compare cache hit/miss rates, backend workload and latency between cached and uncached requests before assuming that adding more caching will solve the problem.
[Internal Link: “Caching Explained: When It Makes Your App Faster and When It Doesn’t”]
Performance degradation often arrives without a major code change because the data itself has changed.
A query that retrieves every event for a customer may be fine when typical customers have 100 events.
Years later, large customers have 500,000.
The code is identical.
The workload is not.
Data growth can affect:
This is why performance testing with tiny development datasets can be misleading.
When slowness disproportionately affects long-standing or high-volume customers, ask whether the performance characteristic scales with:
The fix may involve database design, pagination, archiving, query changes or another approach, but diagnosis begins by recognising that performance assumptions can expire as data grows.
Sometimes the slow endpoint is not the process consuming the resources.
A nightly export begins using most database I/O.
A large indexing job consumes CPU.
An analytics query locks or heavily scans tables needed by customer requests.
A bulk import saturates worker capacity.
Users see slower pages even though none of those pages directly invoke the background job.
This type of resource contention is easy to miss when teams monitor each workflow separately.
Look at whether latency correlates with:
Performance is determined by shared resources, not just request code.
If user-facing and background workloads compete for the same constrained resource, separating their capacity, scheduling expensive work differently or limiting resource consumption may be necessary.
An average can make a badly performing application appear healthy.
Suppose nine requests complete in 200 ms while one takes 8 seconds.
The average is still below a second, yet one in ten customers has a terrible experience.
That is why percentiles are useful.
A simplified view might be:
Metric
What it tells you
p50
Typical experience
p95
Experience of slower 5%
p99
Tail latency affecting the slowest 1%
Throughput
Amount of work being processed
Error rate
Whether slowness is becoming failure
Saturation
Whether resources are approaching their limits
Break those measurements down further by endpoint, customer segment, geography, device, application version or data size where relevant.
An overall latency graph can hide a severe problem affecting one important workflow.
A useful performance investigation follows the request.
For a slow workflow, ask:
Browser: Is the delay in loading or rendering?
Network: Are there too many or unusually slow requests?
Application: Which function or service consumes the time?
Database: Which queries dominate latency?
Dependencies: How much time is spent waiting externally?
Infrastructure: Which resources become saturated when latency rises?
This is why traces, metrics, real-user measurement and query analysis work better together than any single dashboard.
A practical diagnostic table can help:
Symptom
First places to investigate
Slow for every user all day
application code, database, frontend
Slow only at peaks
capacity, resource saturation, connection pools
Slow for large accounts
queries, data volume, payload size
Server fast, browser slow
frontend rendering, JavaScript, network
One workflow slow
dependencies and code specific to that path
Sudden slowdown after release
changed code, configuration, queries
Intermittent multi-second delays
external dependencies, contention, tail latency
[Internal Link: “Application Performance Optimization: A Practical Guide”]
There is no single fix for a slow application because there is no single kind of application slowness.
Adding servers will not fix a bad query. Creating an index will not reduce a huge JavaScript bundle. Caching will not help if most latency comes from an external payment service, and optimizing backend code will have limited effect if users are blocked by rendering on low-powered devices.
The important discipline is to locate the delay before deciding how to remove it.
For Levelworks, that is what Performant App Health should represent: not a one-time benchmark achieved at launch, but an application's continuing ability to provide responsive behaviour as its users, data, dependencies and infrastructure change.
When an application starts feeling slow, the most useful first question is therefore not:
“How do we make it faster?”
It is:
“Where, exactly, are our users waiting?”
Once that is known, performance stops being a vague complaint and becomes an engineering problem that can be measured.
