That's what confuses me. AJAX loaders are ubiquitous on the web. They're small, easy to use, and a great visual cue. I'm not sure why you would want a percent-based loading bar unless you actually knew how long something would take to load. (e.g. see loading bars for downloads)

Using these super thin bars as a "dumb" loader seems like it would only confuse your users. It's like using an icon other than the floppy disk to convey saving.

There are step functions that allow you to approximate it or increment it gradually. I might not know how long an individual step in a process will take, but if I know how many steps there are, I can know approximately how much to increment on the completion of each.

This doesn't suit all usage patterns (like file downloading where you don't know the file size), but I can think of at least a dozen scenarios in which this is perfectly suitable (even if I don't personally love the effect).

It's not that hard. If you're already using a module loader (which in all likelihood, you are if you're loading something async these days), then just count modules being loaded in your controller(s), and use that as your basis.

A harder approach would be to be super accurate with actual size of response. Content-length on the header won't work because it only refers to that one file. Also, the server won't have any clue which files belong to which web page response. A way around this is to check every request against a session ID. You'll also have to pass back some sort of "request hash" -- GUID for the request so you can match different files from the same request (static files, content, etc).