# Make your app fast

> The usual causes of a slow-feeling app, in diagnosis order, and the prompts that fix each one.

"My app feels slow" almost always has one of a handful of causes, and each has a prompt that fixes it. This page is the diagnosis order, plus what the platform already does so you do not chase ghosts.

## What is already handled

Vaulter serves published apps from an edge network close to your visitors, over HTTPS, with the production build optimized at publish. Hosting speed is not the usual suspect; the causes below live in the app itself, which means you can fix them in chat.

## The usual suspects, in order

### 1. Heavy images

The most common cause by far. A phone photo is 3 to 8 MB; a page showing six of them moves more data than the whole rest of your app. Signs: the layout appears fast but images pop in late; the first visit is slow, later ones fine.

> Compress and resize the images on the home page for the sizes they display at, and lazy-load the ones below the fold.

For images you upload yourself, the [file guide](/docs/data/files-and-storage) has the format-and-size habits that avoid the problem at the source.

### 2. One page doing too much

A dashboard that loads every table, chart, and list at once is slow on arrival even when each piece is fine. Signs: a long blank or spinner on one specific page.

> The dashboard loads everything at once. Load the summary cards first, then load each section when it scrolls into view.

### 3. Long lists without pagination

Rendering 2,000 rows at once makes the browser itself struggle. Signs: the page stutters when scrolling, or gets slower as your data grows.

> Paginate the orders table at 50 per page with search, instead of loading every order.

### 4. Requests in series that could be together

A page that fetches one thing, waits, then fetches the next, feels slower than the same work done at once. This one is invisible from the outside, so just ask:

> The projects page feels slow to load. Look at how it fetches data and speed it up.

## Judge it on the published app

The [preview](/docs/publish/preview-vs-published) is for correctness; the published app is the performance truth, since it is the optimized build on the real network. Test there, on a phone, ideally on cellular data, because that is where your visitors live. If the published app is fast on your laptop and slow on your phone, start with images.

## Frequently asked

#### Is my plan or the platform throttling my app?

No plan makes a published app slower; every tier serves from the same infrastructure. Plans change limits like tokens and connector counts, not serving speed.

#### The first load is slow, then everything is instant

Some of that is normal (the browser caches the app after the first visit) but a heavy first load is usually images or an overloaded landing page; suspects 1 and 2 above, in that order.

#### Did adding features over months slow the app down?

It can, quietly; each addition was fine, the sum is not. Ask for a review: "go through the app and list the three heaviest things slowing down first load, but do not change anything yet", then fix what is worth fixing.