I am developing a web-app utilizing Application Cache, and everything is working great on desktop browsers and on Android (even very old & slow android handsets). However downloading the appcache is taking much much much longer on iOS 6 in both Safari and Chrome.
My application cache total size is a mere 2.1Mb, and I have a pretty solid 70Mbps (download) internet connection. I would expect caching to be pretty rapid.
Here are my times so far:
Desktop Chrome: <1s (similar times for Safari & Firefox)
Android 2.3.3 Stock Browser: ~4s (similar times for Chrome & Dolphin)
Android 4.2.2 (Emulated): ~7s (running inside a PhoneGap app)
iPhone 4S 6.0 Safari: 8 minutes!!! (around the same in iOS Chrome too!!)
iPad 2 6.0 Safari: as above!!!
All of these devices are using the same wifi and internet connection, and my iPhone/iPad are otherwise functioning fine (no native apps exhibiting internet speed issues, and regular websites load just fine). There just seems to be something absolutely decimating AppCache download speed under iOS.
The window.applicationCache.status throughout this time is appCache.DOWNLOADING, and I have a progress event running counting the files as they are downloaded, so I'm certain that it is not stuck elsewhere. This just appears to be the time it takes to download. What gives?
Addendum : The iPhone also runs ridiculously hot, and the battery ticks down very quickly during this operation. It seems that something is causing the CPU to run flat-out during this download.
(Note: I can't publish a link to the web-app here as we're still in private beta, but if you would need to see it before you think you'd be able to help diagnose it, email me at the address in my profile and I'll send a link to the app).
Okay, I figured it out with the help of the iOS Emulator, and Xcode Instruments to profile it. (I'm not sure if I should add my solution into the main question, or as an answer, but I thought I'd do it this way as my question is already a little cluttered).
As it turns out, it was actually some erroneous javascript causing the issue, but apparently only on iOS.
The web-app is intended to only be a single page high (no vertical scrolling, except within specific DIVs), so in addition to the usual standard JS code for hiding the address bar...
window.addEventListener("load",function() {
// Set a timeout...
setTimeout(function(){
// Hide the address bar!
window.scrollTo(0, 1);
}, 0);
});
...I had also added in the following:
$(document).scroll(
function(e){
window.scrollTo(0, 1);
});
From looking at the profile results, I was able to see that a lot of time was being spent in scrollTo, so it immediately pointed to this as the cause. Why the scroll event was being triggered so much, I have no idea (this was occurring with no touching of the screen whatsoever).
My initial fix is to throttle that code, but I am now evaluating whether or not I even need it at all. Here is the code I have that fixes it for now (using jquery-debounce, which I was already using for something else):
$(document).scroll(
$.throttle(function(e){
window.scrollTo(0, 1);
})
, 10);
The download time of the application cache is now in line with the Android times. Phew!
The code is getting itself into an infinite loop, as the initial scrollTo function call triggers the scroll event handler, which then repeatedly re-triggers itself! My best guess is that the iOS JavaScript engine handles this infinite loop differently to the other browsers' JavaScript engines.
Related
I have an issue with Firefox. In both responsive mode and Firefox Mobile to be accurate.
The touch scrolling isn't working on my website. (But the scroll with the mouse is working on Responsive mode)
It works fine on Chrome mobile & Safari mobile.
I checked online and I already tried the dom.w3c_touch_events.enabled set to 1. It was actually set to 1 by default.
I think it's an issue on the JS/CSS side but I can't see where.
I use SASS and Pleeease to compile it and it's a React app compiled with webpack.
Also I use the method fetch to call my webservices if it can have any influence but I doubt it. (and have a polyfill for it)
I tried to nuke totally my CSS and it still didn't work.
Happy to share URL if people want to see the actual problem. I just don't want to be seen as a spam. Also I will share a test server and not the live one. (problem is the same anyway)
Found the (stupid) solution and posting it as it might be helpful to someone.
I had a overflow:hidden; added by mistake in html, body { into my SASS.
For some reason the responsive mode in Firefox is still not working (bug? cache? I don't know...). But once I tried again on my Firefox mobile it was gone.
Looks like Chrome and Safari are ignoring this CSS but not Firefox.
For the record I am on last versions on all my browsers.
Whenever a page goes through an actual digest (with around only 600 watchers) the page load is about 6 times slower on ipad vs desktop (calculated by using console.time).
My current research:
There is the intentional delay upon touching a button on iPad, that was fixed by using fastclick.
I don't think its due to touch event as a tried on a touch screen with a mouse and the speed is about the same (when using mouse vs touching).
Both desktop/ipad seem to be caching responses as you'd expect.
By using developer tools it seems it has to do with something in digest, I couldn't find any add ons for safari (doesn't seem to exist) to break down timing in the digest.
No problems on safari on desktop, or any other browser for that matter. Problem exists on multiple iPads.
I've heard including jQuery slows it down and tried removing it but same problem exists
I'm not looking for general ways to increase performance but to fix/troubleshoot this .. bug? I've ran out of ideas, please help! :D
Edit:
I'm not using ionic, it's web based.
Looks like I found the issue, its not angularjs but Javascript. On iPads javascript is much slower (http://ajaxian.com/archives/ipad-javascript-shockingly-slow).
Confirmed by running Google Octane (https://developers.google.com/octane/). Desktop Safari Browser: 29942, iPad Safari Browser: 6795.
This kinda sucks.
EDIT:
Tested out various iPads:
Android (Using Chrome v49 (latest)):
Galaxy tab S2 9.7: Octane Score 6901
Galaxy Tab A 8.0: Octane Score 2650
Galaxy Tab A 9.7: Octane Score 2886
Samsung Galaxy Tab: Octane Score 2622
Chromebook (Using Chrome v49 (latest)):
Lenovo Chromebook: Octane Score 8641
Ases 2in1 Touch-Screen: Octane Score 7378
HP Chromebook: Octane Score 8688
Ipad (Safari)
Ipad Pro: Octane Score 20,632
Ipad Air 2: Octane Score 10,601
Ipad Mini 4: Octane Score 9,902
As Blazemonger pointed out the article is old but the point is still true, javascript is slower on iPads/Tablets, particularly on android.
We found with about only 300 watchers the magical octane number is 10,000 (of course there are many other variables but to give someone an idea). So as long as you don't need your application to be fast on all iPads/Tablets you can rely on AngularJs (Although I guess the real problem is just heavy javascript).
When you are using ionic, you make a precompiled app in a web, so you have one more layer to process(iOs-> browser -> webApp) , in the pc the browser is just one layer( browser -> webApp)
WebApp is slower than native apps.
A fellow developer and I are on exactly the same Firefox version (41.0.1) using the exact same steps to reproduce a text-layout bug on our web application after hard cache refreshes using the same production server (no local assets), and he sees the bug but I don't. We tried on a 3rd developer's browser (same Firefox version) and he does not see the bug, so it seems isolated to this one browser instance. Both machines are identical - Windows 7 on Lenovo Thinkpad T420. It's a CSS text layout bug - text overflows the box onto multiple lines. I've linked to an image below.
Image of bug here
We have also tried:
Running the problem browser in private browsing mode.
Starting the problem browser in safe-mode (to disable plugins).
Doing a diff between the CSS source file each browser is seeing - they are binary equal
Does anyone have any ideas why this might happen or how else to try to debug it?
Edits:
Other things we have tried:
Reset zoom levels on both (ctrl+0)
Ever since Chrome updated itself to version 32, I have been experiencing aggravating bugs. One of the worst is when editing the DOM using the Web Inspector, and Chrome will about every minute start popping up this dialog, which yanks focus from the Web Inspector:
It's complaining about the Web Inspector itself being "unresponsive", when it really isn't, and nothing's gone wrong.
This particular page I'm messing with is making use of the mutation-summary library. Perhaps the bug in Chrome that thinks stuff is unresponsive could be related to setting various continuously-running setTimeouts. I say this because I observe similar behavior in the web app we build at work where this has also started happening (and is equally annoying).
The workaround is I believe it is possible to just ignore the dialog and work can continue. I wonder if anyone else (or everyone else) has been experiencing this issue?
I started getting this problem as well.
In searching, I came accross this issue https://code.google.com/p/chromium/issues/detail?id=335248.
As best I figured out, the bug is related to:
Windows 7/8 with Aero Theme
Scrollbars on pages (such as in the developer console)
Pages with popups (in particular Window.open() calls)
I guess they are slated to push the fix into version 33...and maybe leave the stable* 32 how it is (although I hope not).
So there are a few options:
Switch away from Aero Theme until version 33 is in stable
Upgrade to the beta channel, i.e. version 33
Click on the Wait button every 30 seconds whenever the chrome developer tools is open.
Update:
Chrome has released a hotfix into the version 32 stable channel. http://googlechromereleases.blogspot.ro/2014/01/stable-channel-update_27.html
Thanks to #probackpacker for bringing it to my attention.
I have experienced this as well on Windows, it seems that this will happen in general when using the browser (not only within the web inspector). It also seems to happen more often when loading flash content (such as a game). The browser and flash areas are responding normally, but the browser thinks that they are not for whatever reason. Pressing wait seems to hide the dialog for a few minutes until it will re-appear again.
I've read that this bug is fixed in the next beta (version 33).
Regards,
Moses
I have also experienced this issue. The change of theme workaround has worked, and the Chromium team has provided the following update today:
... We understand your frustration and are actively working to resolve
it. When you add that comment, it’s confusing the comments around
whether we’re able to fully fix it on canary. If we can confirm it’s
fully fixed in canary, we can merge into the stable channel and
everyone can get the fix. So please refrain from saying thatyou’re
having this problem, too. I assure you we’re actively working on a
fix.
This statement was taken from Chromium ticket #335248.
Okay here’s the solution you can do without changing your theme, right click on my computer, go to your System Properties, and then go to "Advanced", click on "Settings" under Performance, then check the below radio button. This seems to stop it
If the aero fix isn't working for you, download Chrome Beta
I have had this same issue with Chrome 32 (there are so many problems in the dev tools...) but it ONLY happens for me when I have the dev tools detached / undocked from the main browser window.
You might be able to avoid it by re-docking the devtools if you are using them in un-docked mode.
August 6, 2014 - I solved this by installing the latest Chrome Beta https://www.google.com/chrome/browser/beta.html
You can solve this problem in Chrome by following simple steps-
1-Go to Setting
2-Go to Advance Setting
3-Uncheck the "Use Hardware Acceleration when available".
I fixed that problem by linking modem directly to my PC, didn't reinstall or change Chrome or anything. I skipped connection through my wireless router which I think was the problem from the start... now all the pages Chrome couldn't load are loading with no problem at all. Maybe it's time to by a new router...
Can anyone help me figure out why this page causes Android browsers to crash?
http://thewellcommunity.org
All sub-pages seem to work just fine, but when I load the home page on an Android, the browser app just closes without any warning or error messages. I've tried this on 3 Android phones and on a Kindle Fire.
When I completely disable JavaScript in the browser on the phone, the page loads successfully. Unfortunately this is a live website, so I'd prefer to save disabling chunks of JavaScript on the server side as a last resort.
On a side note, Opera Mini, Opera Mobile and Firefox on an Android phone do not crash, but Dolphin, Miren and the stock browser do.
UPDATE: It appears that I spoke too soon when I said this was fixed. I was able to reduce how often the browser crashes, but it still does occasionally crash when the page is loaded. :(
UPDATE #2: It now appears that the crash may be CSS related. After spending weeks enabling and disabling various JavaScript snippits, I tried disabling the stylesheet, and now I can't get it to crash.
Anyone know of an Android CSS bug that might be causing this? My guess is that it's related to some CSS that only gets accessed after the JavaScript does it's work.
I found the culprit... It appears that a css font-family rule was to blame. Although, I'm not sure why since the same font stack is used several other places on the site. :\
Here's the line that caused the problem...
.Site-Search .Buttons input
{
...
font-family: TeXGyreHerosRegular, Arial, "Helvetica Neue", Helvetica, sans-serif;
...
}
For whatever reason that line caused all stock Android browsers to crash. Weird.
Check out Weinre. An explanation can be seen in this youtube movie.
That way you can debug the Android webkit browser just like the well known Firebug.
In Eclipse's emulator (2.3) it loads fine but has some layout flaws.
If anyone came here looking for a possible reason why all of their mobile's different browsers crash after a several seconds when loading a particular website it may be due to the version of jQuery employed.
For example, the LG-p690f and HTC Incredible S are some of several Android 2.3.x phones known to have troubles with fade transitions in jQuery 1.8.1 and 1.8.2 due to a browser javascript bug that will cause jQuery's Animation function to fail at this line:
percent = 1 - ( remaining / animation.duration || 0 )
If you are the owner of the website you can try upgrading to 1.8.3 (or downgrading to 1.7.x if allowed). Otherwise, you can send an e-mail to the website.
Sources:
http://bugs.jquery.com/ticket/12497
https://github.com/jquery/jquery/pull/1019