Loading times of app.gonimo.com much longer than on Safari
Reported by
robert.k...@gmail.com,
May 13 2017
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Steps to reproduce the problem: 1. Load app.gonimo.com in Chrome - can take up to 15 to 20 seconds on mobile. (Even if cached) 2. Load app.gonimo.com on Safari, even on older iPhones - instantly rendered and operational. 3. What is the expected behavior? Similar performance to Safari. Safari does not yet support webrtc so the app is not fully functional, but the loading times are impressive - instant vs. several seconds (even on very fast mobiles) on Chrome. What went wrong? Nothing wrong, just slow. I read in the news that you are interested in real world applications for improving the performance of Chrome and considering this big difference in loading times, there is potential for big improvemnts. Faster loading times would of course benefit our users and users of similar apps. Did this work before? N/A Chrome version: 57.0.2987.133 Channel: stable OS Version: Flash Version:
,
May 16 2017
Could you please confirm the OS platform where you are seeing this issue?
,
May 16 2017
Chrome on Android (7, 6, also on other versions) Also tested on several iPhones, don't know the exact versions, but I can ask if this is important.
,
May 16 2017
Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 16 2017
,
May 16 2017
Safari does load much quicker here - Chrome's not *that* bad, I get loads of about 3-4 seconds until I get the animation and everything's loaded. Seems likely that WebRTC takes some time to initialize but would need more investigation with the app to know for sure. Tim, are you or someone you know actively digging into these kinds of cases?
,
May 16 2017
Looks like it's a few JS blobs, taking seconds each.
The CPU profile points primarily to:
function d(f) {
f.source === c && "string" === typeof f.data && 0 === f.data.indexOf(h) && k(+f.data.slice(h.length))
}
That seems a bit unlikely to be the source of the issue though...
This might be worth digging into from a JS perspective, if it's just V8 being slower than other javascript engines.
,
May 17 2017
Hi Marja, that could fall in your bucket. WDYT?
,
May 18 2017
As far as I understand the comments, this isn't happening while loading (ie, loading the resources from the net, or the initial parsing / compilation), but while we're already executing the javascript (with ignition maybe / probably). Reassigning to rmcilroy@ b/c of ignition.
,
May 18 2017
Looks like this was reported for Chrome m57, which was before Ignition was launched, but I'll take a look since the code will be running in Ignition from m59.
,
Jun 10 2017
Hi there! We tested with Chrome Beta on two mobiles, on mine there is no noticeable difference (but it was quite fast there already - 3 to 4 seconds), correction: I just tried again and after the third load in a row it is a lot faster - 2 seconds sometimes even faster! On my friends phone there is a huge improvement: Loading time went down from above 10 seconds to 3-4 seconds! So it definitely got a lot better, at least on slower devices. But it seems that Safari still does quite a bit better. (Instant load even on older devices) Hope that helps! And thanks for looking into this!
,
Feb 12 2018
Closing this up since it seems to have improved. Feel free to reopen if there is more to do. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by ranjitkan@chromium.org
, May 15 2017