Why does simple website crash on mobile (iOS Safari and Chrome, at least)?

Question

I have a website that is very simple, but very long -- a lot of text that could be scrolled through. It\'s a documentation site, and considering the nature of the content (a lot

Answer 1

Removing position: sticky; helped me and my mobile safari crashing issues. Not sure exactly why.

body:before{
    position:-webkit-sticky;
    position:sticky;
}

Answer 2

I just read this post and tried http://davidtheclark.github.io/scut/ on my iPad. Chrome crashes immediately, although sometimes shortly shows the home page. Safari renders the home page correct and many other pages, but clicking on the "about > installation" link at the left makes it crash right away (well, once it displayed OK, but clicking again crashed it). All of this is pretty consistent.

The errors are indeed due to LowMemory and it's the browser process that uses the most memory. The crashes happen at around 150000 pages (4KB/page? => 600MB???).

That being said, I'm afraid I don't have an answer to your question. Hope it helps at least a little bit.

Kind regards, /Sigiswald

Answer 3

I think I fixed it!

The problem, as suspected, was rendering/painting caused by CSS layout. At phone-size, I had been hiding the content of each entry until it was selected; and the method I had been using to hide them, and remove any trace of them from the layout, included position: absolute. I didn't initially use display: none because of typical concerns about wanting to not see content but keep it there, for various readers and reasons. I threw those concerns aside and changed the layout so that the entries were hidden with display: none and shown with display: block -- and that seems to have fixed the crashing.

I think the absolute positioning was stacking a huge amount of content in the corner of the screen, and although it wasn't visible, it was demanding memory.

What clued me in to trying this was an answer to another related question, linked to above by @tea_totaler: https://stackoverflow.com/a/14866503/2284669. It says:

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.

I think that my other hiding method was not releasing memory, despite its other advantages (which were possibly irrelevant to this particular site anyway). I'm sure it became a problem only because the site was so long.

That's something to consider, though, when you want to hide an element: rendering/memory demands.

Answer 4

Your HTML markup has some errors (such as a div tag inside an h1 tag) that should be fixed before you try to analyze a crash.

I suggest you run it through an HTML validator, for example http://validator.w3.org/check?uri=http%3A%2F%2Fdavidtheclark.github.io%2Fscut%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

The div inside h1 apparently caused a cascade of errors that the validator had to suppress to continue.

When I have browser crashing problems, HTML validation is always my first step. Then I try seeing what might be wrong with the javascript if correcting the HTML didn't help.

Answer 5

On my site it was caused by elements with the css property -webkit-backface-visibility: hidden

removing this property fixed all crashes!

see iOS: Multiple divs with -webkit-backface-visibility:hidden crash browser when zooming

Answer 6

Sorry for just making a guesses but I see two potential causes in your stylesheet which could be resulting in crash

1.) Using data-url for background image rendering such as here

.github,.source {
background-image: url("data:image/svg+xml;charset=US-ASCII,%3Csvg%20width%3D%22100%22%20height%3D%22100%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Cpath%20d%3D%22M85.714%2050q0%2014.007-8.175%2025.195t-21.122%2015.485q-1.507.279-2.204-.391t-.698-1.674v-11.775q0-5.413-2.902-7.924%203.181-.335%205.72-1.004t5.246-2.176%204.52-3.711%202.958-5.859%201.144-8.398q0-6.752-4.408-11.496%202.065-5.078-.446-11.384-1.563-.502-4.52.614t-5.134%202.455l-2.121%201.339q-5.19-1.451-10.714-1.451t-10.714%201.451q-.893-.614-2.372-1.507t-4.66-2.148-4.799-.753q-2.455%206.306-.391%2011.384-4.408%204.743-4.408%2011.496%200%204.743%201.144%208.371t2.93%205.859%204.492%203.739%205.246%202.176%205.72%201.004q-2.232%202.009-2.734%205.748-1.172.558-2.511.837t-3.181.279-3.655-1.2-3.097-3.488q-1.06-1.786-2.706-2.902t-2.762-1.339l-1.116-.167q-1.172%200-1.618.251t-.279.642.502.781.725.67l.391.279q1.228.558%202.427%202.121t1.758%202.846l.558%201.283q.725%202.121%202.455%203.432t3.739%201.674%203.878.391%203.097-.195l1.283-.223q0%202.121.028%204.967t.028%203.013q0%201.004-.725%201.674t-2.232.391q-12.946-4.297-21.122-15.485t-8.175-25.195q0-11.663%205.748-21.512t15.597-15.597%2021.512-5.748%2021.512%205.748%2015.597%2015.597%205.748%2021.512z%22%2F%3E%3C%2Fsvg%3E");
background-repeat: no-repeat;
}

2.) Also -webkit-transition could be the culprit. Read here for more https://stackoverflow.com/a/11833285/900132