At the start everything appeared instantly. Today the main list takes eight seconds to show, your users click twice because they think nothing happened, and somebody has started saying the app is sluggish.
Nothing changed in the code. The volume of data changed, and it exposes choices that were invisible while the database was empty.
The threshold beyond which a screen feels slow is documented: 2.5 seconds for the largest element on the page to appear, measured across three quarters of page views. Past that, users assume something is wrong.
Cause number one: one query per displayed row
This is the most frequent defect in generated applications, and developers have a name for it, the cascading query problem.
In practice: your screen lists orders. For each order it also wants the customer name. So the code asks for the list of orders, then, for each one, goes back to fetch the matching customer. Thirty orders trigger thirty-one trips to the database instead of one.
With thirty rows nobody notices. With three thousand, the screen waits on three thousand round trips, each costing a few milliseconds that add up.
The defect never shows during development, because development happens on a near-empty database. It is fixed by asking for the data in a single request, which usually takes a few hours per affected screen.
Cause number two: load everything, sort in the browser
A generated application often builds a list by fetching an entire table, then filtering and sorting on the browser side. The result is correct and the code is simple.
The day the table holds forty thousand rows, the browser downloads forty thousand rows to display twenty. On a desktop with fibre that stays tolerable. On a phone on mobile data in a corridor, the screen never appears at all.
The fix is to request only what is displayed, page by page, and to let the database handle sorting and searching. Budget half a day per screen, more where filters are numerous.
Cause number three: images
A photo from a recent phone weighs several megabytes. Displayed in a thumbnail an inch across, it is downloaded at full resolution then shrunk by the browser.
A gallery of twenty photos then pushes sixty megabytes across the network to display the equivalent of a postage stamp. The cost is double: display time and transfer bill.
The fix is mechanical and quick. Reduced versions are generated at upload, and the screen displays the size it needs.
Cause number four: connections that are never released
Every exchange with the database occupies one of a limited number of simultaneous connections. Code that opens a connection without closing it properly gradually exhausts that pool.
The symptom is confusing: the application works perfectly during testing, then turns everyone away in the middle of the day, before recovering after a restart. Many teams conclude they have a hosting problem and pay for a bigger plan, which simply moves the threshold.
Cause number five: long jobs in the wrong place
An export of every customer, a monthly report, a bulk email send. When those run in the same place as the screens, they monopolise resources and the application slows for everyone while they last.
Triggered at eleven in the morning by a user who wants their export, they produce exactly the effect observed: “it is slow, but only sometimes”.
The underlying flaw: the code repeats itself
Those five causes are fixed one by one. A sixth makes them more likely and more expensive to address: duplication.
The GitClear study covering more than 200 million changed lines between 2020 and 2024 shows the share of copy-pasted lines rising from 8.3% to 12.3%, while moved lines, the mark of refactoring, fell from 24.1% to 9.5%.
In a generated application that means the same database query is written across six different screens. Fixing the slowness then means finding all six, and a partial fix leaves the problem in place wherever nobody looked.
How to find out where your slowness comes from
Guessing is expensive. Measuring is quick.
A copy of your database is filled to a realistic volume, the one you will reach in six months. The most-used screens are then opened while watching, through the browser developer tools, what is requested and how long each call takes.
The result is almost always the same: two or three screens hold most of the problem, and the rest of the application behaves properly. That is good news, because targeted work is enough in most cases.
What not to do
Increase server power first. It masks the symptom for a few months, costs every month, and the problem returns with a larger volume and a higher bill.
Rewrite the whole application. Slowness rarely comes from the overall architecture, it comes from a few specific places.
What slowness actually costs
The direct cost shows on the hosting bill. The indirect cost weighs more and shows less.
Your internal users work around it. They export to a spreadsheet, work alongside the application, and re-import when they remember. The application stops being the reference, and discrepancies settle in.
Your external users leave. On an order form, every extra second of waiting loses a share of visitors. The 2.5-second threshold is not a comfort recommendation, it is the point at which behaviour changes.
Your teams stop reporting. After three months of slowness nobody raises it any more, and a genuine outage disappears into the background noise.
Finally, slowness masks other defects. A screen taking eight seconds to answer makes it impossible to tell a heavy operation from a stuck one. The day a task genuinely fails, nobody notices.
What we do
We measure against a realistic volume and hand you the list of what is slowing your application, screen by screen, with the expected gain and the cost of each fix, in plain language.
You choose what gets handled. Each batch is quoted at a fixed price, and we measure again after the work so the improvement is observed rather than announced.