Making slow software fast, based on measurement rather than guesswork

Measure first, then fix the thing that is actually wrong

The most expensive mistake in performance work is optimising the wrong thing. Somebody decides the server needs upgrading, spends money on a larger machine, and the site is still slow because the real problem was one database query running fifty times per page. We always measure before recommending anything, and the measurement usually points somewhere nobody expected.

On the browser side we look at what a real visitor experiences on a mid range phone over an ordinary mobile connection, not what a developer sees on a fast computer connected to the same network as the server. That means examining how long it takes for the page to become visible, how long until the main content appears, whether the layout jumps while loading, and how long before the page responds to a tap.

On the server side we look at how long the application takes to produce a response, which database queries dominate that time, how many queries each page issues, what is being fetched that nobody uses, what could be cached, and what work is happening while a user waits that should have been pushed into a background job.

The problems we find most often

The single most common finding is a query pattern that issues one database call for every row in a list. It is invisible with twenty records and devastating with twenty thousand, and it is responsible for more slow pages than every other cause combined. The fix is usually small once it has been identified.

Second is missing indexes, where the database is reading an entire table to find a handful of rows. Third is images, either uncompressed or served at dimensions far larger than they are displayed, which punishes mobile visitors most. Fourth is scripts, particularly third party tags for analytics, chat widgets and advertising that quietly add seconds to every page load. Fifth is heavy work being done while somebody waits, such as generating a report or sending a batch of emails during a page request.

Caching, background jobs and doing less

Caching is the fastest improvement available in most applications. We use Redis to hold the results of expensive queries and rarely changing pages, with expiry rules chosen so that information does not go stale in ways that matter. The art is in deciding what is safe to cache, since caching the wrong thing produces confusing bugs that are far worse than being slow.

Background processing with Celery removes waiting entirely for work that does not need to happen immediately. Sending notifications, generating reports, processing uploads and calling slow external services all move out of the request cycle, so the user gets an instant response and the work completes where nobody is watching.

The most underrated technique is simply doing less. Pages that fetch data nobody looks at, dashboards that calculate twenty figures when three are read, and lists that load everything when a page of results would do. Removing unnecessary work is faster than optimising it, and it stays fast as data grows.

What improvement is worth

For a shop, page speed maps directly to completed orders, particularly on mobile where a significant share of visitors leave before a slow page becomes usable. For a business system, the arithmetic is even simpler. If a screen used two hundred times a day takes four seconds instead of one, that is ten minutes of paid time lost every day for every person doing it, and it never appears on an invoice. Performance work is one of the few technical investments where the return can genuinely be calculated in advance.