Mobile option to not load user avatars (and other potential bandwidth saving features)


(Brad Huber) #1

We recently released our Discourse forum to replace our self-built mini-forum app, and some users are up in arms over the mobile version not being as friendly (personally, I dont see how they can prefer our terrible self-built app, but some people just hate change).

One issue they have that does actually make sense though, is swapping from our old only-text-based forum to this one means increases in bandwidth usage, and for people on data plans without unlimited data, they risk hitting their caps.

One solution I thought of for saving bandwidth was maybe there could be a user-based preference to enable a barebones mobile layout? One that doesnt even load avatars? And maybe has a few other bandwidth saving tricks someone smarter than me might know about.


On the mobile theme, the list of posts show's the latest replying user's avatar, not the OP's avatar
(Sam Saffron) #2

Avatars are probably the least of the problems, images in general and youtube embed can get quite costly. Text only is an interesting idea but not really doable at the moment before we upgrade to the “yet to be released” version of Ember that would enable us to easily do stuff like this.


(Brad Huber) #3

Thanks for the reply. We’re a Disney Theme Park related site and I really think we just have lots of people averse to change and the “It uses more bandwidth” thing is just something theyre trying to jump on to bash the new forum. The old forum is just terrible terrible terrible.

I’ll probably take some data measurements and hopefully it turns up that theyre all over-reacting, because there’s no way this site can be using up some crazy amount of data compared to other apps like twitter or facebook (especially since we dont allow youtube embedding).


(Sam Saffron) #4

If anything on mobile it should be pretty light once the initial JS and CSS loaded, we only trade json chunks when navigating around.


(TheLoneCuber) #5

Avatars are probably the least of the problems

While I like to think that an avatar-free Discourse would be significantly faster, it seems that even when ~60 avatars are being served that it’s only around a 0.6 second problem (meta.discourse.org testing via webpagetest.org). Though I am surprised to see how long meta.discourse.org takes to load given that it’s Fastly powered? A ~6 second load time wasn’t what I was expecting.

I’ve also just set-up my first Discourse site using a Digital Ocean droplet and was hoping for better performance results.

Regarding avatars @sam, could the the default Letter Avatars (when a user has no avatar image set) be a HTML+CSS version and not an image, saving a bunch of HTTP requests? I know the meta.discourse.org has a high ratio of avatared users, but for many forums with non-tech people, they have a much higher % of non-avatar users.


(Sam Saffron) #6

Testing http://meta.discourse.org as opposed to https is adding a half sec delay for no good reason. I can confirm that time to first byte is quite high here on fastly, will raise it with them and figure out why.

Avatars are not impacting rendering of the page, we specify sizes, you can filter them out if you wish with webpagetest rule and confirm.

Looking at this: WebPagetest Test Result - Dulles : meta.discourse.org - 09/27/14 05:42:52

We are seeing a load time from clean of 4.5 secs.

Repeat view is taking 2.4 secs.

In the repeat view.

Browser has all the data it needs 420ms in, so the extra 2 seconds there are used up by:

  1. Parsing JS bundles (approx 500ms)
  2. ES6 module Loader (approx 250ms)
  3. Rendering the front page in ember (approx 500ms)
  4. Other stuff, approx 750ms

Definitely a lot we can do better, @eviltrout is working on the ES6 loader Regressions in Ember's loading due to ES6 modules - Performance - Ember.JS

Our mid term plan is to lean up our assets a lot and load up more on demand, I am hoping to halve the payloads at least. Which could get the down to 250ms.

We also plan to upgrade to metal views in Ember 1.8 which are more efficient and will give some sort of perf improvement.

We plan to focus a lot of efforts to improve perf in Discourse 1.2 (which is the next major release after the upcoming 1.1)

Perf is not terrible but we are doing way better than median, however we can do better and will.


(TheLoneCuber) #7

Very fair point @sam.

And it’s only compared to how incredible Discourse is as a complete experience, the performance is seen as average. Congrats on where it is now: I just installed my first Discourse an hour ago… and my second Discourse instance a half hour after that. I can feel an addiction comin’ on. What a beautiful platform.