Computers are fast. Modern Web UIs tend not to be.

Making them as quick as possible depends on where you are on the interactions spectrum.

The principle to make UIs fast: remove the slow parts.

I’ll discuss some strategies to do so, depending on where you are on the interactions spectrum.

1. Interactions Spectrum

Back in the 1970s, you could boot a computer and been dropped in an interactive shell in a few 100s of milliseconds. Computers were single task and single user. Each keystroke on the keyboard created an interrupt. This interrupt was handled by the CPU as soon as received.

That’s faster than most applications on your own computer in 2020s, even the offline ones.

Worse, many applications are websites that do not work offline, are very slow, and unreliable.

There is a spectrum of interactions between those extremes.

1.1. From Offline to Thin Client

UI Spectrum

1.2. What is slow?

By slow, I mean time it takes to complete.

This means latency for small amount of data, and latency plus throughput for large amount of data.

Here is a list of things, from the slowest to the fastest (latency-wise):

  • network call (with or without TLS);

  • reading/writing to a HDD;

  • reading/writing to a SSD;

  • reading/writing to RAM;

  • reading/writing to GPU/CPU cache;

  • display complex images via the CPU;

  • display complex images via the GPU.

1.3. How to speed things up

As much as possible, remove slow parts by faster parts.

For example, if a network call can be replaced by a read/write to the local disk, do that instead.

At the same time, most if not all interactions should be asynchronous: they don’t block, but show an indication that they happen to the user.

In a nutshell: go down in the list of slow things, and go asynchronous.

2. Offline Only Client

An offline only client is a program that does not need internet at all to work.

For example:

  • a text editor;

  • a simple calculator;

  • a single player video game;

  • a screen recorder;

  • etc.

Pros:

  • very fast;

  • works offline;

  • user owners of its data.

Cons:

  • needs 1 client per OS (or only supports some OSs);

  • data is constrained to a specific device, hard to share it;

  • fewer people make those, and fewer people know how to make them.

3. Thin Web Client

A thin web client only provides a UI that represent exactly what the services behind expose. Any interaction with this UI is synchronous, and highly dependent on the response time and availability of the services.

Pros:

  • easy to make;

  • always in sync with the data in the back-end;

  • works on all devices with a browser;

Cons:

  • very slow (to start and to operate);

  • only works while online;

  • highly dependent on the services (useless if the service provider shuts down);

4. Optimistic Client

An optimistic client is a thin client that tries to high the high latency of the actions, by supposing that they will work as expected. It shows the consequence of the action, before the servers confirmed it worked.

Compared to a thin web client:

Pros:

  • asynchronous for some actions (mostly for creation/deletion, not for retrieval);

Cons:

  • more expensive to make;

  • users must handle errors after the fact;

To see examples of what I mean, see Optimistic UI in 1000 words.

5. Local Web Client with cache

A local web client is a client that is installed on the device of the user, so it starts fast.

But it acts as an optimistic client, and add a local cache to avoid too many network calls.

Compared to an optimistic client:

Pros:

  • fast start up;

  • fewer network calls (cache).

Cons:

  • more expensive to make (1 client per OS type);

  • cache handling can be complex (but it’s improving with web workers).

6. Local First Client

A local first client is a client that behaves like an offline only program, but with background synchronisation with the servers. It considers that the data in local is the source of truth, and the servers are updated with it, instead of the opposite.

Compared to a local web client with cache:

Pros:

  • fast to start and to operate;

  • works while being offline;

  • data stays on the device of the user, and can be re-used by other programs on the device;

Cons:

  • requires reversing the data dependency (clients holds the truth, servers is backup, instead of servers shows the truth);

  • can be more expensive (but not necessarily, with backend-as-a-service);

  • few people know how to make those for now.

7. Conclusion

Latency of interactions in day to day web UIs is frustrating, but there are solutions to make it better.

To know more about the local-first client concept, see You own your data, in spite of the cloud (archive).