This is actually quite fluid on iPhone 5. I asked a co-worker to try this on his Galaxy S3(quad-core, no lte) and it was really slow there. And in Chrome it was even slower than that on the S3.
I thought this was common knowledge. Chrome is horrible on Android. If you look at benchmarks, the only browser/phone combination that is close to iPhone Safari performance is the latest galaxy flagship running Samsung Internet.
So basically, you're getting an Android phone, minus the 700,000 Apps? Thanks, but no thanks.
The whole idea of using HTML, CCS, and JavaScript as the back end technology for a low-end smartphone is nuts. Even the best HTML rendering engines are CPU and memory hogs. CSS was never designed for and is nearly impossible to hardware accelerate, and JavaScript is notoriously difficult to optimize and even the best VMs like V8 run orders of magnitude slower then Native code, while the VM itself takes up a massive amount of memory.
Mozilla should focus on building a competitive browser. At the end of the day, I want a responsive fast phone, like the iPhone or Galaxy S3, not some dog slow HTML5 monstrosity.
Well now you know how most of those web pages felt on Android before - web devs tested on mobile Safari and left pages broken and utterly stuttery on Android web browser.
Why slower on mobile? The upgrade cycle on phones is much shorter than PCs, so even if you never put new software on a phone, you'll get an HTTP/2 enabled browser quickly.
On the software side, Google-derived Android comes with Chrome by default, which already support SPDY and HTTP/2 support is imminent. Safari on iOS 8 supports SPDY, ditto on HTTP/2 coming soon. Both those software updates can be done instantly (via Google Play Services) or within a year (yearly iOS updates).
So I'd think mobile support is coming very quickly.
Samsung phones and Pixels aren’t that bad either.
I am not saying it to be proud, but I tested our 3mb internal app with a 5 year old android phone, and worked.
The only time it was slow is if the browser itself was old (e.g. Chrome 44).
I tried it on my Android phone a while ago, and my (unscientific) conclusions are that it's slower, more resource intensive, and drains the battery faster than using the default Chrome browser.
Browsers do compete on merit. I use both iOS and Android. My Pixel 6 has an inferior processor compared to my iPhone 14. Even a 5 year old iPhone would smoke my Pixel 6 in benchmarks. But my day to day use Chrome on Pixel 6 is faster for JS heavy apps, scrolling and faster network loading. On a flaky network for sites with http3 the difference is day night between Safari and Chrome android. Chrome’s heuristics based rendering is far more advanced than Safari. I would say Safari a very good JS engine but Chrome has found other ways to make pages much faster.
From the article:
"Blaze has produced a report that proves Android is faster than the Iphone[sic] at web browsing."
This is incorrect. Blaze didn't even test the Android browser or Mobile Safari. It tested the performance of embedded browsers in third party apps.
From the report [0]:
"The measurement itself was done using the custom apps, which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone."
Mobile Safari is faster than embedded browsers in third party iOS apps [1].
Sure there is... the article even said that WKWebView and Safari are faster than his Samsung device. The problem is not that the browser isn't fast, the problem is that he wants to make a sub optimal cross platform app that's not optimized for either iOS or low end Android devices that most people are buying.
Is it that much different than the mobile browsers that rendered the page on a server and just sent a compressed representation to the phone? A variant of opera did that and worked so much better than regular browsers on weak phones. This targets different devices, but it could work equally well.
I'm not sure what he's talking about regarding the Android web browser. In my experience, it's been essentially the same as the Mobile Safari in terms of experience.
Keep in mind, not everybody is running a desktop browser with that sort of cpu horsepower behind it.
Half of the iPhones ever sold - something like 80 million devices - are pre iPhone 4. There are a lot of low end Android devices on the market _right now_ with worse browser performance than an iPhone 3 (I've got a <6month old Huawei U8110 here as an example). Sure, top-end Android devices compare well against an iPhone4S (I'm pretty impressed with the Galaxy SII I've got here), but the bulk of Android devices in the wild are not late-model-top-end devices.
I had to drop an entire development branch from a project late last year due to insufficient performance of mobile device on-handset ajax. (We fell back to on-server html rendering and innerHTML updates, and even _that_ is annoyingly slow to me on low-end phones.)
And unless you have gathered data showing otherwise, this _probably_ really does apply to you. I was collecting some mobile use data last week - across ~70 websites that I've got Google Analytics access to, the average mobile visits was 14%, and the peak was just over 28%. This was across a range of markets and a variety of levels of "mobile friendliness" of the web design. (Biggest and probably most obvious takeaways from that exercise: B2B sites are a standard deviation or more below average for mobile visits, personal/leisure B2C sites up to one or two SD's above average. 80+% of mobile visits exit on a page with contact details - a phone# or address.)
I don't know the particulars of how this is implemented, but you would either have to compile your code for ARM (adding an enormous burden to web development), or have all mobile browsers ship an x86 emulator (which is a massive step backwards).
Doesn't any web browser on Android use a JIT?
reply