Keep your app fast

A fast app feels effortless; a slow one feels broken however good it looks. The choices you make as the app grows are most of what determines which one you get.

Ask for optimistic updates

A screen that waits on the server for every action feels slow even on a fast connection. Ask for the UI to update immediately and reconcile with the server in the background:

When I mark a task done, update it immediately in the list; don't block on the server.

A local-first data layer that does this automatically for every write (VorxSync) is on the roadmap, not yet in the apps you build — until it ships, ask for optimistic updates explicitly where they matter.

Show less per screen

The fastest screen is one that doesn't try to render everything at once. Long lists of hundreds of rows are the most common cause of sluggishness. Break them up:

• Paginate the orders table to 25 rows per page.
• Add search and a status filter above the contact list so users narrow it before scrolling.
• Load older activity only when the user scrolls to the bottom.

Giving people a way to find what they need beats making them wait for a giant list to draw.

Ask for the data you need, not all of it

List and overview screens rarely need every field. Fetch the columns you show and pull the full record only when someone opens the detail view.

On the projects list, only load the name, status and owner; load the full project when I open it.

Less over the wire and less to render means a snappier screen, especially on phones.

Keep images in check

Images are easy to overlook and quick to slow things down. A page of full-size photos will always feel heavier than it needs to.

Show thumbnails in the gallery grid and load the full image only on the detail page.

If your app takes uploads, set limits deliberately too — "images only, up to 10 MB". Without a limit, the first person to upload a 200 MB video finds out for you.

Test with realistic volumes

An app feels fast with ten records and slow with ten thousand. Seed enough sample data to see how screens behave under real load before you ship.

Seed 500 contacts and 2,000 activities so I can test with realistic data.

If a screen drags at that scale you've found where to add a filter, pagination or a lighter query — while it's still cheap to fix. You can check what actually landed under Settings → Cloud → Database, which is also the quickest way to clear test rows out again afterwards.

Measure, then refine

When something feels slow, name the exact screen and interaction rather than guessing. Vorx can then target the fix — a filter here, lazy loading there — without disturbing the rest of the app.

If the slow part is a backend function or a scheduled job rather than a screen, Settings → Dev Logs shows each run with its timing, so you can point at the real culprit instead of the symptom.

Speed isn't a one-time task; it's a habit. Build in layers, test each screen with real data, and keep the heavy work off the critical path.

In the docs: How Vorx works and Logs and monitoring.