Ban the Throbber

What is a throbber

A throbber is a generic loading indicator that appears all too frequently for basic, routine actions that can and should be nearly instant:<br>loading a web site, loading a list, navigating a view, expanding a detail pane, clicking "more info" for a bank transaction, etc.

I don't need to provide examples because unfortunately, you probably see them every day. The constant "wait seconds for results" experience meaningfully hurts user productivity, and makes it hard to use the web and quickly access content.

If you see a throbber multiple times while doing simple tasks with an interface, and it's so slow that you can notice it,<br>the user interface is broken , and it needs to be treated like a problem and fixed.

They're almost never required, you're just doing it wrong

If an interface is using a lot of throbbers:

It's requesting remote data that should have already been pre-loaded in the app.

It's missing important local and/or server caching. It's fine to use slow cloud databases or poorly indexed/overcomplicated SQL queries, but if that happens often, it needs to be cached.

It's using bloated front-end JavaScript frameworks for for web pages that don't need them.

It's loading analytics and related junk code before the actual content you came to look at.

What to do if you're about to use a throbber

1. Stop and reflect

You've hit rock bottom. This is a problem. You need to admit it. You need to do better.

Prioritize and schedule time to work on removing them. It's more important than you realize.

Change your development culture to prevent them in the future.

2. Make required data like a pizza: "Hot and Ready"

If you can't load it fast, pre-load or pre-cache any data that will be likely be used by the user during a normal experience.

Use Content Delivery Networks (CDNs) to keep as much content as possible close to users. It takes 200 milliseconds for a single network packet to reach Australia from New York.

Precompute frequently accessed data, or maybe even denormalize overly complex SQL queries.

In general: keep the data the interface needs cached, close, and ready to go.

3. Render immediately

Load initial HTML first before heavy JavaScript. This is also better for pagerank, because search engines don't need to run JavaScript to see the web page.

Optimize the UI and data it has locally for simple actions.

Take The No Throbber Pledge

I will treat throbbers as a failure mode, not a feature, and only use them as a last resort.

I will ask "why can't this be nearly instant?" before adding a throbber.

I will cache or pre-load data if a user will likely need it.

I will use real incrementing progress bars for long tasks, not throbbers.

I will be proud of my fast, nimble site/app that never needs a throbber.