# How to Speed Up a Web App: Quick Wins for Young Products

> How to speed up a web app without a rewrite: images, database indexes, caching, fewer requests and lazy loading, plus how to measure before and after.

Published: 2026-09-11 · Source: https://subxcat.com/articles/performance-quick-wins · Author: SUBXCAT

Performance is how quickly an app shows people what they came for and responds to what they do. To speed up a web app at an early stage you almost never need to rework the architecture: most of the time goes to a handful of simple things, namely heavy images, database queries without indexes and unnecessary round trips to the server.

A vibe-coded app flies on an empty database and a fast laptop. It gets slow for someone on a mid-range phone, on the train, once the table has ten thousand rows. Here is an order of work that gives a noticeable result in a day or two.

## Measure first, then speed up

Without measuring, you'll optimise what feels slow rather than what is slow. Before changing anything, write down the starting numbers.

- **Lighthouse** in Chrome's developer tools. Run it in mobile mode and look at the time until the main content appears and the total page weight.
- **The Network tab** with network throttling on. Sorting by size shows the heaviest files immediately; sorting by time shows the slowest requests.
- **Server response time** for your main APIs, from logs or monitoring. If an endpoint takes more than a second, the problem is almost certainly not the frontend.

Measure the same pages under the same conditions before and after. Put the numbers in the change description; you'll want them in a month.

## Images: the cheapest win

Most often a page is slowed down by one or two images uploaded as-is: a phone photo of several megabytes shown in a card the size of your palm.

- Compress and resize images to the size they're displayed at, with some headroom for high-density screens.
- Use modern formats, WebP or AVIF instead of PNG and JPEG where you can.
- Set width and height so the page doesn't jump around while loading.
- If users upload their own images, resize them on the server at upload time instead of serving the original.

## Database indexes

An index is a table of contents for a table. Without one, the database scans every row on every query. With a hundred rows nobody notices; with a hundred thousand, a query that took milliseconds starts taking seconds.

The telltale sign: a list page gets slower as data grows even though the code hasn't changed. To speed up a web app in that situation, look at which fields you filter and sort by most, usually `user_id`, a status and the creation date, and add indexes on exactly those:

```sql
create index orders_user_created_idx on orders (user_id, created_at desc);
```

You can check whether a query uses an index by putting `explain` in front of it. Don't index everything: each index slows down writes and takes space.

## Fewer requests

The second common cause is too many calls to the server or the database.

- **The N+1 problem.** The code fetches a list of fifty orders, then queries the customer for each one separately. Fifty-one queries instead of one or two. AI assistants write this happily because it's simple.
- **Repeats on the client.** The same request fires every time you switch screens. Data-fetching libraries can cache responses and not re-ask for what they just received.
- **Extra fields.** The query pulls every column, including large text ones, when the screen needs two.

## Caching

A cache is a saved answer that can be served again without recomputing it.

- Serve static assets (scripts, styles, images) with a long cache lifetime and a hash in the filename. Most bundlers do this for you; the main thing is not to break it in your hosting settings.
- Data that rarely changes, such as a catalogue, settings or public pages, can be cached on the server for a few minutes.
- Never cache personal data where another user could receive it. That's not a speed-up, it's a leak.

## Lazy loading

Not everything has to load at once. Images below the first screen get `loading="lazy"`. Heavy parts of the interface, like an editor, charts or a map, load only when the person gets to them. The less JavaScript on the first screen, the sooner the page responds on a phone.

## In short

- You can usually speed up a young web app without a rewrite: images, the database and extra requests eat most of the time.
- Measure in mobile mode on a slow network first, then change things, then measure again the same way.
- Compressed images in modern formats are the cheapest win.
- Indexes on filter and sort fields and fixing N+1 queries pay off as data grows.
- Cache static assets and rarely changing data; lazy-load everything below the first screen.

If your app has become slow and you can't tell why, SUBXCAT can find the bottlenecks and remove them without rewriting the project.