--- title: "Application Performance: Where the Time Actually Goes" description: "\"It's slow\" is usually a complaint about one screen, not the whole application. How to find where time is really lost, and why it is almost never where people look for it." canonical: "https://interfase.sk/en/news/application-performance-where-the-time-actually-goes" lang: "en" last_updated: "2026-10-14" --- # Application Performance: Where the Time Actually Goes > "It's slow" is usually a complaint about one screen, not the whole application. How to find where time is really lost, and why it is almost never where people look for it. Published: 2026-10-14 - "It's slow" almost always means one or two screens; the first job is to find out which, not to speed everything up. - The most common cause is not a weak server but the number of database queries behind a single screen. - Average response time misleads — watch the slow percentiles, because those are what users with the most data experience. - Optimising without measuring means speeding up something that was never holding anyone up. "The system is slow." That sentence reaches every development team sooner or later, and it is almost always imprecise — not because it is untrue, but because it is not about the system. It is about one screen somebody opens fifty times a day. The first task, then, is not to speed anything up but to **find out what**. ## Measure before you start Without numbers, optimisation follows impressions, and impressions are usually off. Typically money goes into infrastructure while the problem sits in a single query. You need three things: **which screens are opened most often**, **how long they take to render** and **how that time splits** between database, application logic and browser. And beware the average. If mean response time is 300 ms, it may mean ninety percent of requests take 100 ms and the rest take three seconds. Those three seconds belong to the users with the most data — usually the most important ones. So watch the **slow percentiles**, not the mean. ## The most common cause: too many queries In practice this accounts for about half of cases. A screen shows a list of a hundred orders and fetches the customer for each one separately. Instead of two queries there are a hundred and one. Each is individually fast, so nothing looks odd in the log. Only their sum turns three hundredths of a second into three seconds. The fix is usually simple — load the related data in one go — but finding it without measurement is hard. ## The second cause: loading more than needed A list shows eight columns, but the whole record is pulled from the database including notes and history. Or all twenty thousand rows are loaded and pagination happens in the browser. This also covers **missing pagination in filters** and lookup lists reloaded on every open, even though they change once a year. ## The third cause: missing indexes With a thousand rows in a table it does not matter. At hundreds of thousands it does. It typically shows up as an application that was fast for years and "suddenly" slowed down — with no change to the code, only growth in data. Indexes are not free: they speed up reads and slow down writes. So they get added deliberately, to what is actually filtered and sorted, rather than to every column. We cover a related topic in the piece on [search in a business application](/blog/vyhladavanie-vo-firemnej-aplikacii-full-text-filtre-a-relevancia). ## Perceived speed is half the impression Two applications with identical response times can feel completely different. What decides it is whether the user can see that something is happening. - **Show the shape of the screen immediately** and fill in data as it arrives. - **React to a click at once**, even if the result is confirmed only after the server responds. - **Do not block the whole page** for one slow part of it. This is not cosmetics. A user who sees a response within a hundred milliseconds judges the application as brisk, even when the data lands a second later. ## What not to do first For completeness, the other side. **Rewriting on another framework** does not improve speed by itself. **A bigger server** helps only if the problem really is machine capacity, which it rarely is. And **caching** added before the cause is understood hides the problem until stale data shows up. ## How to keep it Performance degrades gradually and quietly — a column is added, a relation is added, data grows. So it pays to keep measurement switched on permanently, with an alert when response times get worse than last week. It belongs to the same discipline we describe in [CI/CD and safe deployment](/blog/ci-cd-a-bezpecne-nasadzovanie-softveru): the problem should announce itself rather than arrive as a complaint. ## Where to start Take the three most frequently opened screens, measure them, and look at the query count. In most applications that is exactly where you find a saving that is visible immediately and costs a day of work. If your application is holding you up and you want to know precisely where, [get in touch](/kontakt). We do this as part of [custom development](/riesenia/vyvoj) — examples are in our [case studies](/referencie). --- Web version: https://interfase.sk/en/news/application-performance-where-the-time-actually-goes llms.txt: https://interfase.sk/llms.txt