Low bandwidth users

Contribute UX
1

Continuing the discussion from Make Discourse play nice with the Wayback Machine:

[quote=“codinghorror, post:7, topic:34579, full:true”]

Where are you getting this data from? [/quote]

Measuring from my own site on a text-only topic, no cache, I’m getting 4.3 MB. At 56k simulated speeds in Chrome dev tools, it churns for 15-20 minutes and times out, less than a quarter of it loaded. (I’m still trying to find out why my site is heavier than meta… ) I have yet to successfully load a page at this speed.

I’m not saying there are lots of dial up folks out there. But there are a few left, by choice or necessity.

Verizon inherited about 2.3 million AOL dial up customers, according to Time magazine. And 3% of Americans still use dial up at home, according to this research group.

On top of that, folks throughout the developing world have limited access speed and data caps - not to mention under-powered hardware. A simpler, lighter interface will open the door to them as well.

Obviously we aren’t catering to these folks… but since we already serve up an stripped down HTML version, making it functional will let them participate.

Here’s some other big sites that present a functional stripped down version.

Facebook now has “Facebook Lite”: Facebook Lite Is A Stripped Down Android App For The Developing World | TechCrunch

Gmail has basic HTML: https://mail.google.com/mail/?ui=html

Twitter with javascript disabled redirects to https://mobile.twitter.com, and is functional.

Google Search with javascript disabled redirects to an older but functional version (and slims down from 362kb to 62kb).

2

Is that without any form of built in HTTP gzip compression? That does not seem correct to me at all. Remember text compresses at 70-80% typically.

2개의 좋아요
3

Ah! Thanks for that… Turns out gzip was not working. We’re down to about 900kb now, and things are much more snappy!

2개의 좋아요
4

The irony is that Discourse, being a JavaScript app delivered over HTTP, is a best case performance scenario for a severely bandwidth constrained user. The first load will be the chunky, but all highly compressible, JS text of the Discourse app – and every subsequent request is for only the JSON data necessary to render the requested view.

At no point is a “new web page” send down in its entirety to the user.

But do not take my word for it. Feel free to measure it yourself – with a normal, gzip compatible http connection – and see.

(It is true that first load perf will not be amazing because we send the app in that first payload. But all text.)

4개의 좋아요
5

You might find this an interesting read:

https://meta.discourse.org/t/blog-post-is-high-bandwidth-required-to-read-a-discourse-forum/26995?u=erlend_sh

(please excuse the slightly aggressive language; it’s not directed at you! At the time of writing, there was a very vocal minority of people who were crusading against the advent of JavaScript as a web technology without presenting any factual data)

4개의 좋아요
6

After first load, Discourse is an exceptional low bandwidth site. I can’t think of any site that does better in these scenarios.

The first load can be quite rough though, since you need to pull down the whole app bundle. We are looking at improving first load time in various ways in 1.8 or maybe 1.7 depending on timing.

5개의 좋아요
Beta testing the Android mobile app
7

Music to my ears. We have thousands of users in LatAm on spotty 3G connections who find us via search engines, but it’s hard to know how many we lose because they dont wait for the great web app experience to load :slight_smile:

2개의 좋아요
8

It is definitely quite high up on our list, right under …

:kissing_heart:

4개의 좋아요
9

6년이 지났는데, 저도 경량화된 진입점에 대해 궁금합니다. 저는 우리 Discourse 포럼의 관리자는 아니지만, 대부분의 지원 문의를 분류(triage)하는 업무를 맡고 있습니다.

3일 전, 월 데이터 사용 한도에 도달하여 속도 제한(throttling)을 받았습니다. 이후 3일 동안 사실상 사이트 접근이 차단되었습니다. 화면은 첫 번째 빈 화면에 5개의 진행 표시점(loading dots)이 무한히 반복되는 상태로 멈춰 있었습니다.

다행히 계정 설정에서 메일링 리스트 모드(Maillist mode)를 활성화해 두었기 때문에 방문자들에 대한 응답을 계속할 수 있었습니다.

위에서 언급된 gzip이 실행 중인지에 대한 문제 해결 질문은 흥미롭습니다. 몇 달 전 갑자기 사이트에 진행 표시점 애니메이션이 추가되었고, 초기화 지연 시간이 4개에서 두 배 이상으로 늘었습니다.

서버가 gzip으로 압축된 콘텐츠를 전달하는지 확인하는 간단한 테스트 방법이 있을까요? 아니면 얼마나 많은 데이터가 전송되고 있는지 어떻게 알 수 있을까요?

1개의 좋아요
10

당신이 우리의 호스팅을 사용하거나 공식 Docker 설치를 사용하는 경우, gzip과 brotli는 기본적으로 활성화되어 있습니다.

https://www.webpagetest.org/를 통해 사이트를 확인하거나, Chrome / Safari 또는 Firefox 개발자 도구를 열어 직접 확인해 볼 수도 있습니다.

3개의 좋아요
11

경량화된 비상용 진입점이 있는 것도 좋을 것 같습니다.

계정 로그인을 통해 대역폭이 낮은 계정 관리 화면으로 이동할 수 있고, 이 화면에는 다음 두 가지 옵션만 제공되도록 하는 것입니다: 메일리스트 모드 활성화/비활성화 및 지난 1시간/1일간의 활동 요약 이메일 발송.