Mobile Safari on iOS crashes on big pages

Question

I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.

I get the same problem on both iPhone and

Answer 1

There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.

See Apple's documentation for more info.

Answer 2

I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).

After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.

Adding a little timeout solved the problem. My application was also using iframes.

$(document).ready(function () {
    window.setTimeout(function () { ready(); }, 10);
});

Answer 3

The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.

Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.

In any case, to give more up to the point suggestions, more information about your page would be really great.

By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:

1. General
2. About
3. Diagnostics & Usage
4. Diagnostics & Usage Data

If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).

Otherwise, it might tell you what is wrong...

Hope this helps.

Answer 4

I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:

As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.

However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.

What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.

Answer 5

I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.

The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?

So the bottom line is: -webkit-transition crashed the page on mobile safari.

Answer 6

Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.