Is there such a thing as a low bandwidth version of discourse? Any thoughts on optimization?

(Tobias Eigen) #1

This past week I had a skype call with a colleague in Sierra Leone who’s going to be a thematic coordinator on my forum. He shared his screen so I could introduce him to discourse and walk him through all the features and answer his questions. We’re finding that Discourse is reasonably user friendly but that alot of complex features are hidden away behind that simple interface - so a one-on-one intro for key people is turning out to be pretty essential.

My reason for posting this topic and my question is about the fact that discourse is painfully slow for him on his slower internet connection. I was able to observe this directly during our skype call. When he clicks on a link, say to the speech bubble notification menu, it seriously takes 10-20 seconds for that menu to pop up. That is a crazy long time and a significant burden. There is also no progress indicator or anything - so he has to be verrrrrrry patient while waiting for something to happen after clicking.

While gmail (which we also use alot) downloads emails and makes them available on the client side for handling, it seems that discourse does not do this at all. Rather it is going back to the server to get updated content when you click on say the notifications menu.

We are trying to get people to keep discourse open in another tab in their browser, like email. But if it’s going to take 10-20 seconds every time to see what’s new and relevant to the user, we have a serious problem.

The alternative, to turn on email notifications for all activity, is not really ideal for coordinators since we want them to get in there and manage/organize discussions and also model good behavior for having productive (and, dare I say it, civilized) discussion by quoting multiple people in replies, starting new related topics etc.

(Khoa Nguyen) #2

Discourse is a single page web app. It consumes very little bandwidth. Everything is sent on the first load. When you move around, only data are sent to client, not the whole page. So in this case, I think you should check with his computer and connection to your Discourse instance

(Tobias Eigen) #3

this is what I assumed as well, but it still seems to be (is!) very, very slow on a slow internet connection. The data sent/received to open the notifications menu in particular is shockingly burdensome and slow, it seems.

How do you recommend I have this coordinator test his connection? I don’t know where the slowdown is happening… I just know that in gmail the transfer of data is in the background while in discourse it is not. So some better optimization should be done to make discourse work better in low bandwidth situations, e.g. by downloading relevant topics and notification info ahead of time so it’s there in the browser waiting to be accessed. When you click the notification menu it should open up immediately and tell the user what’s new and ready to be handled.

(Khoa Nguyen) #4

To make sure that this is because data transfer time. You can do these step (I’m using Chrome) :

  • Open a new tab
  • Open console (F12) -> Network -> XHR
  • Open notification (click on the bubble) and see data transfer time. Mine is very fast

(Omni) #5

Discourse is more than likely not the problem in this situation.

There might be a problem with your colleague’s connection to the server which hosts your Discourse instance. A ping test can quickly demonstrate how slow the connection is, however I recommend a full traceroute. Network degradation can occur anywhere between the client and the server. A traceroute will help determine exactly where the problem lies.

(Jeff Atwood) #6

The other posters are right… after Discourse sends down the initial app JavaScript bundle, every other click is simply sending JSON to the client to render. We never transmit a full “HTML page”, JavaScript literally pings the server, makes an API call to get the JSON data needed to render, and then JavaScript redraws the entire page when you click on anything. Discourse is extremely bandwidth efficient due to the way it is designed.

It’s unlikely that bandwidth is the problem here.

If you are working on a very slow / old client device, or an Android device, you will see performance issues because the client is slow at running the JavaScript we use. But any iOS device of recent vintage or any typical desktop/laptop will be quite fast.

You can search for “Android” and “performance” for much detail on that problem and what we’ve been doing about it.

(Tobias Eigen) #7

Thanks! This all makes sense and reflects my own understanding of things, but still I could see that my colleague had an easier time with Gmail than with discourse. The notifications menu took an extraordinarily long time to load.

I will follow up with him and other colleagues in other low bandwidth places, and see if I can get more info.

(Jeff Atwood) #8

What hardware and browser / version was this user on, specifically? That information would be much more helpful.

(Dave McClure) #9

Where is your site hosted? You may also want to have him try a few different discourse sites that are hosted elsewhere (like meta, for example).

While band with may not be the issue, latency could be a problem, which is what @omni was getting at, I believe.

It’s either something like that or his device is not fast with executing the javascript and rendering the changes as @codinghorror is hinting.

(Tobias Eigen) #10

I will find out. I know it was windows and chrome but don’t know versions.

Digital ocean. I had no problems accessing the site at the time.

Maybe the skype call was causing the problem. I will keep an eye on it and investigate.

(Dave McClure) #11

The distance between you and your DO server vs. this other guy and your server may be quite different though. The number of “hops” a packet has to go through to reach his machine is worth checking out, as @omni suggested, by running trace route.

Here’s a how to geek article on the subject:

(Jeff Atwood) #12

Hard too say, on Windows and Chrome you definitely should not see perf issues unless it is very low spec hardware, e.g. an older Intel Atom system or older very low end Celeron.

Skype video takes a lot of bandwidth, the audio only should be fine though.

(Kane York) #13

It’s latency, not bandwidth, that’s the problem with his internet connection.

With Chrome’s mobile emulation, try the EDGE network (it’s the highest RTT available. Maybe they should add a “Satellite Link” option.).