LoaderShip – CSS-Only Loaders

It isn't super-hard to fix this, but does take effort/time/money. For example, test on slow devices on slow connections. There are proxies that can throttle and introduce latency, or even let random connections timeout.

There's a catch-22 here though: doing this early in a product's life probably doesn't make sense as it's almost certainly better to focus your efforts on creating the product. But the longer you wait, the harder (== more time-consuming == more expensive) it is -- there's more architecture to change, there's complex page logic that eg didn't account for potential timeouts while doing a callback to validate something entered in a text box is unique, etc.

    loading = true
    try { 
      await fetch(…)
    } finally {
      loading = false
    }

2. I think it makes it easier to get to your website without having to use search and it is easy to share like are we web yet dot org

Often there isn't much feedback that it is easy for the client-side to give, it doesn't get any feedback until the first byte arrives in response and the time between request and first byte is far more significant than the rest of the transfer.

For things like file uploads/downloads proper progress is very useful and it is irritating when that isn't present (uploading photos to facebook on a slow connection for one example). Client-side things like number crunching too.

One problem you see sometimes where things can be easily monitored and the user informed, is that developers neglect to test in less than ideal conditions. The process works within a second on their devices and connections so they don't think to include a progress indicator, it is only when someone tried the result on something slower (an old slow CPU over a patchy mobile connection) that this becomes apparent. Also more detailed progress information is on the “nice to have” list so gets passed over in favour of bug fixes and other feature updates.

> I often wonder why developers put tools like this on an extra domain instead of

I think just fashion/appearances. It may also be an SEO thing (short URLs doing better there?).

I agree generally but things like "How long should it take?" is more about your internet speeds / consistency, or very odd unforeseen issues on the back end, and frankly there's no amount of goofing around with even more code on your computer to determine local internet issues ... will tell me any number that makes sense.

The only time calculating "how long" is under ideal circumstances (and at that point nobody cares) or say very predictable large back end workloads. As soon as things get variable, I can't give you a reasonable number.

Sorry if that is a bit of a jumble of words and ideas there, I'm actually taking a break from troubleshooting this exact kind of issue. Customer has varying weird internet issues, wants to know "how long" ... bro wat?

In Chrome on Windows it shows a back-and-forth bouncing progressbar that is not at all similar to the system's indeterminate progress bar styling. I've never seen this used elsewhere, other than here in this Chromium implementation of <progress>. It's (mostly*) not objectionable but it definitely doesn't blend in.

* Suffers from a newbie trap: if you're going to bounce back and forth, you need to make sure there's a frame where the bouncer is all the way at the end of the control before the direction switches. This implementation doesn't, so sometimes the moment when it hits the edge of the progressbar happens between frames, so you miss the actual bump which looks disconcerting.

I've never heard the term "loader" being used here. Since a loader would be something that loads. These don't load anything, they just indicate that loading us happening. I typically call these "spinners" or sometimes "throbers" as that is what they do.

I would strongly recommend write "loading spinners" into one of the first sentences on the page.