Why web applications get slow, and where the time actually goes

A quotation portal that takes five seconds to open a customer file. A webshop that falls over on the day of the promotion. An internal system where staff stare at a half-drawn screen after every click. This kind of delay tends to get filed away as a technical detail for the IT department, but it hits revenue, productivity and customer trust.

Here is what stands out in practice: the cause is almost always looked for in one place. The hosting. The programming language. That one busy database. Usually that picture is wrong. A slow application is normally the result of a chain in which a few links don't quite fit together, with each one adding half a second. Fix only the visible symptom and you buy yourself a few months of quiet, nothing more.

What a few seconds really cost

Users don't compare business software with other business software. Without thinking about it, they compare it with the apps they use for the rest of the day. A dashboard that hangs starts to feel unreliable very quickly, even when the numbers turn out to be perfectly correct.

With internal processes, the damage adds up without ever showing in a report. Fifty employees waiting four seconds twenty times a day lose more than 250 hours a year between them. On customer-facing platforms the effect is more visible: a slow search result, request form or checkout simply lowers the odds that someone finishes what they started.

That doesn't mean everything has to respond within half a second. A heavy analytical report is allowed to take its time, as long as the user can see something is happening and has a rough idea of how long. A stock check during checkout, or a screen a support agent keeps open all day, is a different story. The speed you need follows from the business process, not from a target number sitting in a report somewhere.

Where the time usually goes

Queries that grew along with the data

The database is the classic one, especially in applications that have been running for a few years. A query that worked fine on a hundred records becomes a brake once the same tables hold hundreds of thousands of orders, users or log lines. Nothing changed in the code, only in the volume of data underneath it.

The usual culprits: missing indexes, selects that pull in far more than needed, and queries sitting inside a loop. The N+1 problem shows up regularly too. The application fetches a list first, then makes a separate database call for every single item on it. With ten results nobody notices. With a thousand results the page stalls.

More processing power rarely solves this. First you need to know which query costs time, how often it runs and why. A handful of well-chosen indexes and tighter selects will often gain you more than a bigger server. Indexes aren't a free lunch, by the way. They speed up reads, but they make writing large volumes of data slightly slower. On tables that are written to constantly, that is a genuine trade-off.

Integrations you don't control

Web applications rarely stand on their own. They exchange data with accounting software, payment providers, CRM and ERP systems, carriers, identity providers and marketing tools. Every external call is one more dependency. If a single service responds slowly, your page sits waiting on a system you have no say over.

A product page that pulls live stock, price, product information and delivery options from four different systems on every visit can be built perfectly well and still be operationally fragile. Those two things are not mutually exclusive.

The real question, per piece of data, is how current it has to be. A stock level on an overview page can usually be a few minutes old. At checkout it can't, because there the reservation has to be checked for real. Making that distinction matters more than choosing between synchronous and asynchronous calls. The point isn't to detach everything from the request, but to know which information a user can safely see a few minutes late.

Too much work behind one click

Someone clicks a button and expects a response. Behind that button, far more sometimes happens than needs to: generating an export of ten thousand rows, processing images, queueing a mailing, merging data from three sources. As long as all of that happens inside the same request, the user is looking at a spinner.

Work like that belongs in a background process. The application confirms straight away that the job has been received, a worker does the heavy lifting, and the user gets a notification once the file or report is ready. That saves more than waiting time. It also stops one large export from eating all available capacity while fifty other people sit and wait.

There is a condition attached. Background processing needs queues that are watched, error messages that land somewhere and retries that don't run forever. An export that quietly failed and that nobody hears about isn't progress, it's a new problem. Monitoring is part of the solution, not something for later.

A frontend that grew by accretion

Not all delay lives on the server. An application can feel slow because the browser has to download and process too much JavaScript, styling, imagery and third-party script. Dashboards, portals and webshops grow organically: a tracking tool gets added, a chat widget, a new component, a testing script. Each one looks harmless on its own. Together they make a start screen of several megabytes.

Poorly optimised images remain stubbornly common. Serving a three megabyte photo into a box two hundred pixels wide costs mobile users data and seconds, with nothing in return. The same goes for functionality loaded on every page when a few percent of visitors will ever use it.

The approach isn't exciting, but it works: decide what the first screen genuinely needs, load that immediately and defer the rest. Strip out anything nobody can point to as useful. For an internal application, a plain and fast screen is nearly always nicer to work with than an interface full of movement.

Infrastructure that no longer fits

A server can be online and still fall short. Not enough CPU, memory filling up, slow storage, or a web server that was never properly configured. Problems like these peak at the worst possible moment: during a mailing, a campaign, the month-end close or a busy order day.

For a simple website with predictable traffic, a shared environment is fine. For a business-critical application with many concurrent users, integrations and databases you need more control: separated environments, enough resources, caching in the right place and room to grow. But as noted above, adding capacity without analysis isn't a solution. An inefficient application will fill a bigger server just as easily.

This is exactly why it helps to have development and hosting under one roof. Someone who knows the application and can look into the infrastructure at the same time traces a problem in an afternoon instead of three weeks. It also avoids the three-way conversation between developer, host and integration partner about whose turn it is. At LJPc we treat those layers as one technical whole for that reason.

No caching, and sessions getting in the way

Some data hardly ever changes and still gets recalculated on every request: categories, settings, permission structures, frequently used overviews. Without caching, the application redoes the same work over and over. At thirty visitors an hour nobody notices. At a thousand they do.

Caching does have to be set up deliberately, because a cache that lingers too long serves outdated information. The question per type of data is: how old is this allowed to get, and when should it be refreshed? General content can sit for a long time, user-specific data for a short while, and a final price or stock reservation is always checked live. Making that distinction is half the job.

Session handling is easily forgotten here. If every page has to read, lock and write back a pile of session data, queues build up the moment people work at the same time. We see this mostly in customer portals and internal systems where dozens of employees stay logged in all day.

Measure first, then start fixing

"It feels slow" is a serious signal and a useless diagnosis at the same time. So start with numbers. How long does that page or API call actually take? Is the time spent in the browser, the application, the database or an external integration? Does it happen always, only under peak load, or only during one specific action?

With logging, performance monitoring and a few targeted tests you get a timeline of a single request. Something surprising often comes out of it: that ninety percent of the wait comes from one query, or from an external API that needs ten seconds once every twenty calls. Only with a timeline like that can you prioritise on impact instead of on gut feeling.

Look past averages while you're at it. An average response time of one second looks fine, while five percent of requests take eight seconds. Those five percent shape how your application is experienced, because those are the moments people talk about. So measure outliers, error rates and behaviour under realistic load as well.

Getting faster without creating new problems

The quickest technical fix isn't always the smartest one. A cache buys you speed and must never show wrong information. Asynchronous processing makes a screen feel immediate, but then the status messaging has to be right. An index can make a query ten times faster and should be tested before it reaches production.

So work in small steps. Take on the biggest demonstrable delay, measure again, and check what it did to stability and user experience. In most projects, three or four targeted changes deliver more than a rebuild. Sometimes the analysis shows the opposite, and it turns out the architecture, the integrations or the hosting environment simply no longer match the current scale. That is useful information too, and better to know now than after another year of optimising at the margins.

A fast web application isn't a trick. It's the result of code, database, integrations and infrastructure that were set up together for the work your organisation asks of them every day. Treat delay as a business risk rather than a glitch that will blow over, and you keep a grip on growth, continuity and the experience of everyone who works with the system.