Management software is rarely slow because the server is too small. It is slow because of a few hastily written queries, a few screens loading far too much data, and because nobody measured before changing anything. This article works from the layer closest to the data outwards, in the order you should tackle it.

Step 0 — Measure before you change

Optimising on instinct is the fastest way to waste time. You need three numbers before touching code: which request is slowest, which part of it is slow (data access, processing, transfer), and how often it runs.

Minimum tooling: record the duration of each operation, list the most resource-hungry queries on the database side, and check page load time in the browser. An operation taking 3 seconds but used once a day matters less than one taking 300 milliseconds and running thousands of times.

1. Queries — where most of the time goes

Four problems account for the majority of real cases:

• Queries inside loops. Fetch a list, then run another query per row. A 50-row page becomes 51 round trips to the database. Fix: fetch related data in the same call, or preload it in batches.
• Selecting more columns than needed. The list screen shows six columns but the query pulls the whole entity, including a long notes field. Fix: project directly into the display object.
• Missing indexes on filter and sort columns. Especially date columns and foreign keys that are filtered constantly.
• Filtering after the data has arrived. A condition written on the application side forces the database to read the whole table anyway.

One cheap but effective trick: on read-only screens, turn off entity change tracking. The memory and time saved on large lists is significant.

2. Paging and filters

No list screen should return everything. A few principles:

• Always enforce a maximum row count on the server, even when the interface does not send one.
• Sorting must be stable — add a secondary key, or rows will jump between pages.
• Counting total rows is a separate query and often costs more than fetching the data. On very large tables, consider showing "there is a next page" instead of an exact total.

3. Caching in the right places

Caching is powerful but easy to get subtly wrong. Split it by data type:

• Rarely changing master data (units, job titles, contract types): cache in application memory and clear it when that master data is edited. This is where caching pays off most.
• Data shared across processes: use an external cache with a short expiry.
• Transactional data: mostly should not be cached. Wrong numbers are worse than slow numbers.

Rule: only cache once you can answer "what invalidates this". If you cannot answer, do not cache.

4. Push heavy work to the background

Large report exports, bulk notifications, synchronising with external systems — none of these should run while a user waits. Put them on a queue, return the result when finished, and show progress. Besides a faster interface, this stops one heavy task from taking down the application when many people click at once.

5. Transport and front end

• Compress responses: JSON and static files compress very well, at almost no cost.
• Set long cache lifetimes for fingerprinted static files; keep the main page uncached so a new deployment takes effect immediately.
• Images: compress and limit dimensions at upload time, rather than letting the browser download the original and scale it down.
• Load on demand: split the front-end bundle per module so the first visit does not download the whole application.

6. Keeping the speed you gained

Optimising once and forgetting is a reliable way to return to the starting point within a year. Worth maintaining:

• Automatic alerts when an operation exceeds a preset time threshold.
• Testing against real data volumes, not sample data — a table with ten thousand rows and one with ten million behave very differently.
• Reviewing the most expensive queries periodically; that list changes as the business changes.

Most management systems can be several times faster without spending anything on hardware. The only conditions are: measure first, fix the right place, and never cache something whose lifecycle you do not control.