How slow is Discourse on your mobile?
-
just the latest version of Chrome from the Play store.
How many Android versions back does the latest Chrome typically work with? If you're on an early Jellybean (for example) are Chrome updates stopped?
I know a lot of this is offloaded into Play Services these days, but there must still come a point where you need an OS upgrade to get the newest app versions
-
@Intercourse said:
@PleegWat said:
android phones typically don't get OS upgrades
Huh? Is this something that the lower-end phones don't get? I am on my fifth or sixth Android phone and every single one of them has gotten at least one major version upgrade while I have had it.See the infographic at http://www.htc.com/us/go/htc-software-updates-process/. Older phones and phones produced by smaller companies don't necessarily get upgrades.
-
How many Android versions back does the latest Chrome typically work with? If you're on an early Jellybean (for example) are Chrome updates stopped?
How about people using an Android device but don't use Chrome to browse?
There is an important distinction between Android (an operating system) and Chrome (a browser). I currently have 5 browsers installed on my Android phone and Chrome isn't even among them.
Mentioning @codinghorror, because he didn't pick this up the first time I mentioned it.
-
It's a lot better than it was. Used to be you were lucky if your flagship got one major upgrade, and that would be at least 6 months after it came to Nexus devices. Google's been fighting fragmentation pretty hard
-
I make life miserable for everybody and you fucking know it.
You wish. I personally enjoy your rants these days. You've brought a certain piquancy to the art form of verbal diarrhea.
-
How about people using an Android device but don't use Chrome to browse?
On my phone the Android browser got significantly better numbers than Chrome on Jeff's test (IIRC it was something like 3100 vs 4500). They might actually be better off not using Chrome!
Thanks, @codinghorror, for giving people a reason not to upgrade to better software!
-
Thanks, @codinghorror, for giving people a reason not to upgrade to better software!
How could it possibly be better if Discourse, the king of all software, doesn't run properly on it?
-
I currently have 5 browsers installed on my Android phone and Chrome isn't even among them.
How many of them use WebKit or Blink as the underlying rendering engine, though?Even Opera switched to WebKit/Blink, which was a good thing, because holy crap they sucked.
-
It may benchmark well, but it doesn't actually work well. Especially if you're connecting on a cell phone with less than 5 bars of 4G signal (otherwise known as, any cell signal in the United States not on a coast/in a major metropolitan area).
Over the past two weeks, my iPhone 6 (iOS 8.0.2) running Safari has had less than a 50% success rate at getting a topic to load at all -- the failures all stayed on the loading spinner for more than 10 seconds before I gave up. Even when it did work, having any readable posts rendered on the page within 5 seconds was not a common experience. The topic list here was averaging at least 5 seconds from "press go" to viewable throughout that time.
Most of my browsing was done with 2-3 bars (occasionally 4, which is what we call "VERY VERY GOOD SIGNAL" in these parts) of 4G service on Verizon's network. Meanwhile, espn.com, fivethirtyeight.com, grantland.com, and other major websites loaded and had a responsive "something's happening" within less than 2 seconds more than 95% of the time. Without me moving, or otherwise changing anything, except not visiting a Discourse forum. My problems occurred on both wtdwtf and meta.d.
So, count me in the group that would love to see "useable mobile Discourse". Because I just don't see it, and it has been getting worse over the past two months, and I have never touched an Android phone.
-
To tag onto the purpose of IC's analysis, I'd offer this analogy...
I work in IT consulting, specializing in VoIP systems. From time to time, I get to deploy new phone systems. Inevitably, there are things that work differently than the old klunky key system that we're replacing, and the end user will complain. Most of the time, the problem is in fact the end user's perception, and I spend quite a lot of time working with them ("gladhanding", as I typically call it in the office) to assuage their concerns and make modifications as necessary to ease the pain.
But what I see (and I get the feeling that the TDWTF community at a whole perceives) with Discourse is a consistent "well, it's this tool" or "well, it's that platform" and "it isn't possibly our fault". And if I went in and did that with my phone customers -- "well, you see, the Asterisk system is just going to drop calls, they'll probably have it fixed in 6-12 months" -- the customer would fire me so fast my head would spin. And then, they'd insist on my company completely refunding them so they could spend that money on a different system not using the broken tool set. They wouldn't really care that the tool I chose didn't work well and a fix was on the way.
It's basically the same for me here. I don't really care whether the problem is Ember or ChromeDroid or Discourse itself -- I'm interacting with a forum, and that forum isn't working properly. I can't read posts (because they're all blank, or because the loading spinner stuck on due to Ember puking on Malformed HTML, or, or, or...), or I can't reply to posts (because my Markdown comment got turned into an MD5 hash, or because linking in a picture without further comment is rejected with a cryptic error message that doesn't help me fix the problem, or because I posted in all caps, or, or, or...), or I can't view the post list at all because all the font rendered at 0.75px, or, or, or...
Overall, I think there are things Discourse does better than a conventional forum. But the number of performance issues, and especially the responses given to them by Official Discourse Staff, do not cause me to want to even consider Discourse for any future forum projects I might undertake.
-
I have been away this week so will take a bit of time to respond to my topic that was meant to be just pretty picture of mobile performance, but digressed.
First, we take responsibility for Discourse's performance and bugs. It is not Ember or Android or whoevers fault it is our fault and we are working on fixes.
We have done a lot in the past few weeks to improve things, its a shame that the "forever loading" page bug was hiding a lot of our progress.
Regardless, today I committed 2 related changes:
FEATURE: topics per page should not be configurable ยท discourse/discourse@4cd9243
Can lead to severe performance issues
and
FEATURE: post chunk size should not be configurable ยท discourse/discourse@ae16186
If people need to configure post chunk size use a plugin Core only supports out of the box settings, if changed can lead to severe performance issues.
Both these settings are heavily customised here causing a particularly sucky experience, I made the call that its better to offer less knobs here.
On top of this there are few approaches and features that will land in the next few weeks / months
-
Smaller JavaScript payloads, instead of shipping the composer and markdown engine on first page only ship the stuff we need to render the page, grab the composer when users open the composer.
-
Work with Ember team to correct internals that lead to the 100ms per post render times, we already isolated a series of optimisations that will help, but will take a few months to land. This is much more specific that "html bars will solve it", in particular. Ember class initialization is slow, and can be improved a lot, Ember needs a light weight view construct for dealing with {{if and {{each
-
Continue working with the Chrome team to correct stuff in Chrome
-
Consider a statically rendered header which can cut down on some client side rendering.
-
Consider server side rendering for mobile which is going to land in a few months https://github.com/emberjs/ember.js/issues/9938
-
-
You don't need an OS upgrade, just the latest version of Chrome from the Play store.
First, we take responsibility for Discourse's performance and bugs. It is not Ember or Android or whoevers fault it is our fault and we are working on fixes.
And this, ladies, gentlemen and foxes, is why we like Sam so much more than Jeff.
Jeff, honestly. Take a cue from Sam. Even if a bug or problem isn't your fault, it is your responsability. It sucks, but it's the reality.
If your product misbehaves, it doesn't really matter to your users where the root cause of the problem lies. All that matters is that you fix it, work around it, implement a temporary (temporal?) ugly hack, whatever.
Make. It. Work.Kudos to both of you that you are working together with upstream teams (Chrome, ember.js) to fix the root cause. As Jeff said: "Better Android web experiences benefit everyone." and that's true.
Until those fixes are published (and even then, as pointed out above, some people can't update), you either work around the shortcomings in the libraries you're using in your own product or you create an angry and disgruntled userbase.
-
How many of them use WebKit or Blink as the underlying rendering engine, though?
I don't see why that actually matters. I don't even have Chrome installed on my phone, but WebKit browsers render pages anyway.
This means WebKit is not an integral part of Chrome, so even if I would install Chrome, the other browsers wouldn't benefit from any fixes, right?Anyway, LMDYRFY:
- stock Android browser: no idea (WAG: WebKit)
- Lightning: WebKit
- Firefox for Android: Gecko, I assume
- Lucid browser: WebKit
- Tint browser: WebKit
-
First, we take responsibility for Discourse's performance and bugs. It is not Ember or Android or whoevers fault it is our fault and we are working on fixes.
A DiscoDev that doesn't shift blame onto other people? It's an annual-free-shit-from-family-you-never-see-any-other-time-of-year-day miracle!Firefox for Android: Gecko, I buttume
You know what they say about buttumptions... occasionally, they're correct ;)Also BTFY
-
First, we take responsibility for Discourse's performance and bugs. It is not Ember or Android or whoevers fault it is our fault and we are working on fixes.
It's brilliant for you to state that so clearly and firmly, and sad that you are the only Discodev who will...
The annoying part is I really like Discourse, I would enjoy if all my forums benefitted from it's features, but first of all it has to actually, ya know, work
-
And this, ladies, gentlemen and foxes, is why we like Sam so much more than Jeff.
Jeff, honestly. Take a cue from Sam.
Please, none of this crap, Jeff is the product manager, its his role to make a lot of the very hard decisions that someone ultimately needs to make otherwise you have a product with no heart and 100 managers. Its his job to make sure the ship is steering in the right direction. Its his job to push back when needed.
We don't need a good cop / bad cop thing going on here. Jeff is trying to make Discourse better for everyone just as I am and he cares a hell of a lot about mobile performance.
-
It's weird that the regular Android browser works better than Chrome. Too bad, too, given all the missing functionality. But maybe it'll work better for people who are having problems with Chrome?
Chrome is the default/regular Android browser on some devices, including the Nexus range.
-
So rather than making it suck less, you've just removed the option to have more returned?
Is this temporary until the performance is better?I've said this before - why don't you just serve something more lightweight to ALL mobile devices? Then it gives the same good performance to most mobile devices regardless of whether it's a cutting edge device or a 2/3 year old device.
Lightweight means you can ship more actual content to devices rather than trimming content and increasing amount of loads.
-
So rather than making it suck less, you've just removed the option to have more returned?Is this temporary until the performance is better?
They've stated before that they think it's a bad idea to load 50 posts at a time, raising the question of why it was configurable in the first place. Another example of this site doing actual testinng I suppose
-
Regarding lightweight see point #5, it's going to be practical and something we will explore, we definitely want cut down on the amount of work mobile needs to do to display a post, a funny/sad point is that handlebars+json alone without all the fancy bindings and hooks would totally beat server side rendering in a mobile scenario where bandwidth is paramount, probably even for the first view.
We are working on these issues, will update here when any significant improvements are made
-
Please, none of this crap,
What crap? Compare the quotes of you and him that I juxtaposed in the post you replied to. I wasn't trying to troll btw.
You straight out said that you (plural) take responsability for Discourse's problems. Jeff never said that, he just keeps repeating that it's the upstream that needs to be fixed in order for Discourse to be performant on mobile and we'll have to wait for an updated Chrome, wait for Ember.js updates, ... if we want to have an acceptable Discourse experience.
TTBOMK he never once said that CDCK should make an effort to fix/workaround those problems, but there are plenty of times where he was very quick to point out that it's the 3rd party software you're using that needs to be fixed.Jeff is the product manager, its his role to make a lot of the very hard decisions that someone ultimately needs to make otherwise you have a product with no heart and 100 managers. Its his job to make sure the ship is steering in the right direction. Its his job to push back when needed.
I get all that. You can't make everyone happy, difficult decisions need to be made, someone needs to keep the bigger picture in mind instead of making decisions that look good in the short term, but might cause problems in the longer term.
I'm not arguing that it's a shitty but necessary job. I'm not going to second-guess the decisions he/CDCK have made (although I have an opinion on them, but that's irrelevant in this discussion).I think the problem is communication. Even if Jeff makes the right decisions (I'm stil somewhat convinced that is the case), he honestly does a very bad job at communicating those decisions and the reasons why they were made.
I can't say anything about how Jeff is as a colleague (I don't work with/for him), but as a member of this community, I mean it when I say that he sucks at PR. He might be a hell of a product manager, but if he wants to interface with the users of his product, well, let's just say there is ample room for improvement.
- a meme is not answer
- linking to your own blog posts is not an argument supporting what you say
- written communication doesn't convey body language, intonation, ... Be aware of the medium you use to communicate and its limitations: what you think you're saying might not be what you're actually saying at all
- closing topics/deleting posts just because you disagree with what is said and without giving any explanation at all is rude. If it happens multiple times, you're just abusing your powers.
- enforcing your policy on "civilized discourse" in others, but ignoring that same policy when it suits you is hypocritical and makes you look like a self-important dick.
- telling us we're doing it wrong, when all we do is doing it a bit differently than what you think is the One True Way is being a dick
- not being able to say "I was wrong" when presented with evidence that what you say doesn't make any sense, is childish and doesn't instill much confidence in the decisions you make
I could go on, but I think I made my point.
We don't need a good cop / bad cop thing going on here.
You don't need a good cop/bad cop indeed. You should all be good cops :) We didn't force the good cop/bad cop template on you guys, you've drifted in those roles all by yourselves, as the result of your past communications, decisions, ability to admit being wrong sometimes, ...
If Jeff doesn't want to be a bad cop, he should stop behaving like one.Jeff is trying to make Discourse better for everyone just as I am and he cares a hell of a lot about mobile performance.
I truly want to believe that, but reading things like
@codinghorror said:Are we really taking Windows Phone seriously?
doesn't instill much confidence in that assertion.
-
FWIW, I've noticed a huge improvement on mobile usability since a few days ago. I think it was when you've limited the amount of posts per batch, but I didn't follow this topic that closely back then, so I'm not sure.
Even T-1000 is responsive enough for comfort
-
@sam, thanks for the update and the insight into the direction you're heading.
I have three concerns raised by the change to the topics per page and posts per page change:
- How much "responsiveness" (from the end user's perspective) will be lost on high performance platforms (aka: desktops) by forcing a lower number of topics/posts loaded at one time in order to cater to the lower performance platform? I'm not sure this is going to be a huge deal, because I don't get much delay in my page load process on my home connection, but if someone's on a high-latency connection (e.g. satellite/cellular) on their home desktop, are they going to wind up taking a perceived performance hit as they wait for posts more often while they crawl a thread?
- How much will this hurt mobile battery consumption? It's already been mentioned that Discourse on mobile is very hard on the battery. I would expect that the two main sources of battery consumption are the number of requests (from long polling and from regular browsing through the thread) and the work being done to render posts on the client side. Obviously, there isn't much change to the client side work to render fewer posts more often, but how much of the battery drain is due to the network requests, of which there will now be more?
- How much will this hurt data consumption? It's been noted that the JSON responses with posts are somewhat wasteful. In a 300 post thread, each load would send 1091 bytes for the post ID list, and riking's response right below that post implies that there is other waste within the response that is potentially more severe. How severely is this going to add up over a typical month of crawling the forum? There are lots and lots of people who browse on data-metered connections via their regular desktop connection, let alone the mobile users that are supposed to be benefiting from this change.
Obviously these are pretty hard to quantify (hence why I haven't attempted to :) ). Could you gain more mobile performance while addressing the above concerns by changing the way the site works based on viewport or some other detection, to serve the uncustomizable "smaller" chunks only when a mobile agent is detected, and/or disable or reduce the long polling when mobile is detected, and/or clean up the JSON return for posts lists to ensure you're sending as minimal of a response as possible?
-
I can't see how shifting the rendering to the mobile device makes it less work and better performance but I'm not really an expert on Javascript or Handlebars or whatever so I'll look forward to it when it happens if you believe it'll make an improvement.
-
I can't see how shifting the rendering to the mobile device makes it less work and better performance
the theory as i've always heard it is that the more work you offload onto the clients the less work the server has to do and the more clients it can support. so you get sites that individually render slower (but still responsively and well within the realm of patience on supported platforms (say those made in the last....8 years, of 4 years in the case of mobile) and the server can spend that extra time serving even more clients!
at least that's how it's been explained to me. can't say i've drunk that particular koolaide.
-
I get that much - but we're talking about making it perform better for the client and I cannot see how making the client do more work achieves that.
With such a void between the performance on iOS and Android, the performance of the server is clearly nothing to do with it.
-
Plus, shifting more work to the client only makes the battery life issues worse. That, and I'm not overly keen on holding a searing hot phone in my hand any time soon.
INB4 pedantic dickweedery: Yes, I know the whole phone doesn't get hot. Unless the battery's damaged, in which case all bets are off. Along with your hand, if it explodes.
-
but we're talking about making it perform better for the client and I cannot see how making the client do more work achieves that.
/me shrugs
IDGI either... but that's the theory as it has been explained to me in the past. maybe @sam or @codinghorror have a different explanation that makes more sense?
only makes the battery life issues worse.
tell me about it! i already carry one of these most places i go (three if i'm traveling with the team because none of the students remember to charge their phones and communication is important) and i'd love to be able to get rid of it!
-
one of these
**[180-Day Money Back] Gorilla Gadgets Uhuru! 16800mAh External Portable Battery Pack Charger with Digital LED Indicator and Dual-bulb flashlight - Coconut White Edition - Upgraded from 15600mAh capacity - Compatible with Apple: iPad mini, iPhone 5S 5, iPad 4 (Lightning Cable Adapter Included) / iPhone 4S / iPhone 4, iPad 2, iPod; Most Android Phones: Samsung Galaxy S4, S3, S2, Galaxy Note 2, all Samsung Galaxy Series Smartphones; Google Nexus 4; Motorola Droid Razr, X2, Bionic; HTC One / HTC ONE M7 / HTC ONE X, One S, Sensation, EVO, ThunderBolt; Nokia N9 Lumia 920 900; Blackberry Z10; Sony Xperia Z; Amazon Kindle / Kindle Fire / Google Nexus 7 / Nook Tablet [Retail Packaging]**
And that's just the product name!
-
And that's just the product name!
yeah, but you can stop reading after the first line: Gorilla Gadgets Uhuru! 16800mAh External Portable Battery Pack Charger
a lot of mobile devices on amazon do that because people seearch for accessories to their phones and android phones are like completely generic.
-
a lot of mobile devices on amazon do that because people seearch for accessories to their phones and android phones are like completely generic.
And the concept of metadata eludes them
-
tell me about it! i already carry one of these most places i go (three if i'm traveling with the team because none of the students remember to charge their phones and communication is important) and i'd love to be able to get rid of it!
I carry a 10000mAh (10Ah?) battery pack around, but the battery in the S5 generally lasts 2 days anyway.
It'll do more than 2 with power saving on, and waaaay longer with ultra power saving on but that limits the apps you can use.
-
I carry a 10000mAh (10Ah?) battery pack around
if i'm not using GPS (i do when i travel) my Nexus 5 lasts about 24 hours before hitting 25%
i carry the 16000 mAh size because that charges my phone completely, plus keeps the gameboy going all darned day! and it usually has enough juice left over to charge my phone one more time.
-
First, we take responsibility for Discourse's performance and bugs. It is not Ember or Android or whoevers fault it is our fault and we are working on fixes.
Maybe you should communicate that to Atwood.
Work with Ember team to correct internals that lead to the 100ms per post render times, we already isolated a series of optimisations that will help, but will take a few months to land. This is much more specific that "html bars will solve it", in particular. Ember class initialization is slow, and can be improved a lot, Ember needs a light weight view construct for dealing with {{if and {{each
You idiots have been saying "oh when Ember improves their shit it'll be so much better" for months and months and months. That strategy isn't working. Ember hasn't gotten better, it's gotten worse. None of us believes this for even one millisecond.
In one paragraph, you say "we're talking responsibility" and in the next, it's the same old, "but but but Ember!!!" we've seen all this time.
-
Please, none of this crap, Jeff is the product manager, its his role to make a lot of the very hard decisions that someone ultimately needs to make otherwise you have a product with no heart and 100 managers.
Has he ever made the correct decision? In the entire history of the project?
Oh and excuse me, I'm not one of those people who think code is "art" or whatever, so I'm confused about what "heart" means in this context? Does "heart" in a product mean thousand of bugs? Or extremely shitty performance? Or perhaps "heart" is just a dumb initial design that makes execution of a quality product impossible?
How about instead of anthropomorphizing our products and giving them cute little personalities and (apparently) internal circulatory organs, how about you just make a good product? It's not your goddamned baby, it's a few thousand lines of shitty, broken, code.
Its his job to make sure the ship is steering in the right direction.
It didn't even start out moving in the right direction. As far as I can see, there's been no steering at all.
Its his job to push back when needed.
Who's job was it to pick Ember.js in the first place?
Or did you guys consciously pick a gigantic buggy-ass open source piece of shit framework specifically so you had a scapegoat for everything? Pass that buck around! Pass that fucking buck!
We don't need a good cop / bad cop thing going on here. Jeff is trying to make Discourse better for everyone just as I am and he cares a hell of a lot about mobile performance.
Nothing he has posted here has communicated this to us.
-
@sam said:
First, we take responsibility for Discourse's performance and bugs. It is not Ember or Android or whoevers fault it is our fault and we are working on fixes.
Maybe you should communicate that to Atwood.
Exactly this - nothing Jeff has said has given this impression, even if that's what he does actually think.
-
Exactly this - nothing Jeff has said has given this impression, even if that's what he does actually think.
Oh we know it's not. It's just Sam sucking up to his idiot boss, because he doesn't want to lose his cushy job writing shitty code and being praised for it by morons.
EDIT: now flow in the DailyWTF morons, "but Sam's the good guy!" Yeah, well, he's less of a dick when communicating on this forum, but he's still responsible for Discourse, so you'll excuse me if I don't bow down in supplication.
-
excuse me if I don't bow down in supplication.
I think if you did reality would implode :)
-
Chrome is the default/regular Android browser on some devices, including the Nexus range.
Ah. The two devices I've had--an HTC and a Samsung--defaulted to the...I guess I'll call it "stock"...browser, and I had to install Chrome myself. Three, if you count Bluestacks.
-
yeah, but you can stop reading after the first line
How many amps can that put out at a time? It may say it's compatible with the Note, but if it can't feed 2A, it'll take all day to charge the phone. Or a tablet.
-
How many amps can that put out at a time? It may say it's compatible with the Note, but if it can't feed 2A, it'll take all day to charge the phone. Or a tablet.
USB1 does 1A, USB2 does 2.1A and it can pump out full power to both simultaneously.
charging is limited to 1A and it can't charge and provide power at the same time so it's gonna take a while to recharge it.
-
charging is limited to 1A
The horror! The horror! I don't even want to think about how long it takes to charge at that rate.
-
about 16 hours from 0 to 100%.
it's a 16000mAh battery. the math is pretty simple.
although i don't know of any external batterypacks that take microUSB as the input charge supply that charge at faster than 1A.
the only large capacity batteries i know of that charge faster charge at higher voltage and have their own power brick rather than being universal like this one is.
-
about 16 hours from 0 to 100%.
it's a 16000mAh battery. the math is pretty simple.
Yes, and horrible. It's bad enough charging my note 2 (3100mAh IIRC) at 1A or less, enough so that I bought multiple 2A chargers.
-
Yes, and horrible.
agree, but see my other point.
i take two of the suckers (now that was an awesome sale on woot.com) when i travel. one stays in the hotel charging while the other keeps me charged all day. then i swap back for the next day. ;-)
-
i take two of the suckers when i travel. one stays in the hotel charging while the other keeps me charged all day. then i swap back for the next day. ;-)
Cunning.But then, as you're vulpine, it would be, wouldn't it?
-
Please, none of this crap, Jeff is the product manager, its his role to make a lot of the very hard decisions that someone ultimately needs to make otherwise you have a product with no heart and 100 managers. Its his job to make sure the ship is steering in the right direction. Its his job to push back when needed.
I totally agree with this. But the fact is that he has been contradicting you on the point of taking responsibility for the performance.
-
My 10000mAh (10Ah) battery has 2 outputs - 1 at 1.5A and 1 at 2.1A.
1 x MicroUSB in, 2 x USB out.
Edit:
http://www.amazon.co.uk/EasyAcc-10000mAh-Brilliant-Smartphone-Bluetooth/dp/B00H9BEC8E
-
similar to mine (lower cap though ;-)) except yours charges at 1.5A.... i'd like to charge at 1.5A!
hmm... and impressively cheap.... wait no. you sent me to co.uk.... hmm still pretty good once i adjust for currency conversion.
-
That's where the Google results default - it's like $25 from Amazon.com which is slightly cheaper says some currency converter.
Amazon.com