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

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:

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.