[dheera]

I think I've taken it as a given that any website that uses XHR to load parts of pages will necessarily be slow because of all the rest of the bloat (e.g. jQuery + 10 plugins + Angular) required to make the UI actually work while still keeping the code somewhat readable to the programmers. Basic HTML Gmail is also a ton faster than the normal version ...

You can however use CSS transitions effectively to make the user think the page is faster. Just have some action flying around (it's offloaded to the GPU if you're doing it "right") while things are being processed and it won't "count" towards the user's perception of page load speed.

e.g. Your HTML-only page loads in 200ms, your XHR-/Angular/jQueryified version loads in 1000ms, but you want the user to use and like the latter. Make the page dance around for the first 900 ms, and the user will "feel" that your new version loads in 100 ms. You don't want to push this "effective loading speed" all the way to 0 or else the user will become aware of your trick. Keep it at a perceptual minimum and the user will be like "Woah!"

[TheLoneWolfling]

You cannot just paper over everything. If you're having to resort to tricks due to inherent flaws in your application stack, it may be worth reexamining your application stack.

Also, I wondered who creates that sort of annoyance. Now I know. Having half of mobile webpages have animations all over the place only makes me go "whoa" in the sense of "whoa, how do I disable this and go back to the (relatively sane) desktop site". It doesn't make it "feel" as though it loads in 100ms instead of 1000ms. 900ms instead of 100ms, perhaps, and that's stretching it. But loading in 1/10th the time? Nope.

[dheera]

Yeah; unfortunately the "flaws" aren't something that most people can control. HTML5+JS+CSS+[insert JS frameworks] is inherently inefficient because it's a lot of band-aids on top of band-aids. But we as front-end developers just have to live with those band-aids; we don't get to reengineer the user's browser. If jQuery and Angular were implemented in C

Compare the loading speeds of these two on your own Google account and you'll see.

https://mail.google.com/mail/?ui=html

https://mail.google.com/

Like seriously, even opening a message is faster in the basic HTML version (on my system about ~300 ms vs. ~600 ms) despite it re-loading all the page chrome. I'm 99% positive that's because of all the bloat caused by the all the UI framework they used to make it happen in the regular version. The basic HTML version is so fast that it doesn't even need a progress bar on load!

But of course, you as a developer want to develop the full-blown HTML5 experience because there are tons of features you can't do with basic HTML only. Also, basic HTML makes your site look dated (want a nice-looking button? You'll a bunch of jQuery bloat instead of just a <button> tag. Want a nice-looking text box that maintains a consistent height across browsers? That's a bunch of CSS bloat and putting a text box inside a fake <div> to ensure its height because different browsers have different interpretations of your CSS. Want a text box with tagging ability? That's going to be a massive, inefficient bloat of JavaScript because you essentially have to re-invent the text box from the ground up in JS)

In these cases, sometimes using effects to play tricks on the user to make it "feel" faster does help, because there's nothing we can really do about it ...

[TheLoneWolfling]

And that's why I use the "basic" interface on the (two) webmail providers I have email accounts with. Much faster, and actually handles things like open in new tab properly, among other things.

When the fancy chrome gets in the way of basic functionality, I take the functionality every time.

There is a solution. Or rather, a way of mitigating it. Namely, unlike so many developers, when you look at a "feature", consider the drawbacks, not just the positive side. When you're considering adding something to a button that pulls in umpteen billion JS frameworks, consider if the bloat is worth it. When you're starting to reinvent the text box just so you can have tags, consider if the inefficiency is worth it. When you're considering reimplementing scrollbars in JS, consider if the UI problems you'll have are worth it.

And, you know, if/when you run across something that's problematic to do well, consider feedback. Among other things, the number of features of CSS that ultimately boiled down to someone going "there isn't a good way to do <x> currently"...

I'd be interested to see the other effects of effects. I've seen things on perceived time - but that's not the whole story. Does it affect user retention? Clickthrough rates? User mood?

[forthefuture]

I'd contend that these aren't problems with HTML/CSS/JS, but with their categorical misuse under the guise of simplicity. Things like jQuery are orders of magnitude slower than both alternatives and native implementations, and using many of these bloated libraries will only multiply the inefficiencies.