Low bandwidth users

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”: http://techcrunch.com/2015/06/04/download-facebook-lite/

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).

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)

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

إعجابَين (2)

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 إعجابات

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 إعجابات

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 إعجابات

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)

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

:kissing_heart:

4 إعجابات

بعد 6 سنوات، أنا مهتم أيضًا بنقطة دخول خفيفة الوزن. لست مسؤولاً عن منتدى Discourse الخاص بنا ولكني أقوم بمعظم فرز أسئلة الدعم.

قبل 3 أيام، وصلت إلى الحد الأقصى للبيانات الشهري الخاص بي وتم تخفيض سرعتي. خلال الأيام الثلاثة التالية، تم حظري فعليًا من الموقع. كانت الشاشة تتوقف عند الشاشة الفارغة الأولى مع نقاط التقدم الخمس في حلقة لا نهاية لها على ما يبدو.

لحسن الحظ، كان لدي وضع القائمة البريدية ممكّنًا في تفضيلات حسابي. لذلك تمكنت من الاستمرار في الرد على الزوار.

السؤال الاستكشافي أعلاه حول ما إذا كان gzip يعمل مثير للاهتمام. فجأة أصبح للموقع رسوم متحركة لنقاط التقدم قبل شهرين وانتقل زمن تهيئة الصفحة من 4 عدات إلى أكثر من ضعف ذلك.

هل هناك اختبار بسيط لتحديد ما إذا كان الخادم يقدم محتوى مضغوطًا باستخدام gzip؟ أو كمية البيانات التي يتم تمريرها؟

إعجاب واحد (1)

إذا كنت تستخدم الاستضافة الخاصة بنا، أو إذا كنت تستخدم تثبيت Docker الرسمي، فسيتم تمكين gzip و brotli بشكل افتراضي.

يمكنك تشغيل موقعك عبر https://www.webpagetest.org/ للتأكيد، أو مجرد إلقاء نظرة خاطفة في أدوات المطور في Chrome / Safari أو Firefox.

3 إعجابات

ربما يمكن أن يكون هناك مدخل طوارئ خفيف الوزن؟

كان لديه تسجيل دخول للحساب أدى إلى شاشة إدارة حسابات ذات نطاق ترددي منخفض تحتوي على خيارين فقط: تمكين/تعطيل وضع القائمة البريدية وإرسال ملخص النشاط عبر البريد الإلكتروني للساعة/اليوم الأخير.