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 of short similar entries) I decided to show everything at once, so the user could either scroll from entry to entry or navigate via a sidebar index. It's a common documentation model that I like (e.g. Underscore, Backbone, and LoDash).
The site is here: http://davidtheclark.github.io/scut/. You could look at the pre-production code here: https://github.com/davidtheclark/scut/tree/master/docs/dev.
And here's the problem: For a number of users this site consistently crashes their iOS browsers. Not all users (not me); but for those that do experience the crash, it seems to recur consistently. (The site may also crash some people's Android phones, I don't know: haven't heard from any Android users.) I am hoping someone can help me diagnose and possibly fix this problem.
Part of the difficulty I have is that I cannot reproduce the crash myself -- not on my own iOS devices, not on the Xcode simulators. Because the site is not at all resource-heavy (~70KB load) and involves very little JavaScript, and because of the effects of a few prior attempts to fix this, I'm guessing that the problem involves memory usage -- that iOS browsers are crashing because the site is demanding too much memory. But I'm not sure that's the issue, and if it is I'm not sure how I can fix it.
I'm not sure what to try next, and I'm hoping some savvy StackOverflow whizzes have advice. What is it about this site, which seems so simple and basic to my eyes, that is making it so memory-demanding that it is crashing browsers?
Is it just too long? Is there CSS that is too difficult to render? Are there JavaScript memory leaks?
I'm interested both for the sake of this particular site and so that I can learn to anticipate-and-prevent and/or diagnose-and-fix similar problems on other sites in the future.
Feel free to look at or contribute to [the Github issue](in this Github issue, as well.
Addendum
Here are some things to know about the site that might be relevant:
The HTML doc is large relative to other sites' HTML docs. Unminified it looks to be ~225KB. (I notice that LoDash docs are even bigger -- does that site crash people's phones?)
The served HTML doc is minified.
Served CSS and JS are also minified.
The site uses Prism.js for syntax highlighting.
The site uses Overthrow to make the 2-scrolling-columns layout work on tablets.
<aside id="help-content"> is fixed and translated off-screen; it slides in when you click a [?] like the one by any utility's "use-name".
An iOS Crash Log
These look to me to be the potentially relevant lines of a crash report from an iPhone running Chrome and crashing on the site (I'm not sure whether they are actually relevant or not because I haven't developed iOS apps and don't know the ins-and-outs of these reports):
Free pages: 5674
Active pages: 117674
Inactive pages: 55121
Speculative pages: 3429
Throttled pages: 0
Purgeable pages: 0
Wired pages: 60906
File-backed pages: 23821
Anonymous pages: 152403
Compressions: 356216
Decompressions: 121241
Compressor Size: 16403
Uncompressed Pages in Compressor: 49228
Largest process: Chrome
[...]
Chrome <2a759438c2253e3baededaa0d13feb56> 166479 166479 200 [per-process-limit] (frontmost) (resume)
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.
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
I ran an audit with Chrome on the site. It suggested this:
Remove unused CSS rules (44)
44 rules (10%) of CSS not used by the current page.
css-built.min.css: 10% is not used by the current page.
audio, canvas, video
audio:not([controls])
[hidden]
abbr[title]
dfn
hr
mark
q
sub, sup
sup
sub
svg:not(:root)
figure
fieldset
legend
button[disabled], html input[disabled]
input[type=checkbox], input[type=radio]
input[type=search]
input[type=search]::-webkit-search-cancel-button, input[type=search]::-webkit-search-decoration
textarea
table
.older-docs
.older-docs>li
.older-docs>li:not(:last-child):after
*, :before, :after
fieldset
textarea
:not(pre)>code[class*=language-], pre[class*=language-]
:not(pre)>code[class*=language-]
.namespace
.token.regex, .token.important
.token.important
.older-docs
.changelog dt
.changelog>dt
.changelog>dt:after
.changelog>dd
.changelog-i-list
:target>.entry-body
.sub--h
.example--css.is-active
.preload .help-content-c
.help-content-c.is-active
.help-content.is-active
The task manager on Chrome shows that the page takes up about 2x as much total memory than other sites, such as stackoverflow and dropbox. I would recommend dividing up the features into separate pages instead of one long page. By separating the features it would improve the server's efficiency and the browser's load time and memory usage. There would be less JavaScript and CSS running on each page and smaller amounts of data would be sent from the server. Having all the features on the home page is inefficient. For example, if a user only needed to look up how to make a Font Icon Label they would have to load other sections of the page that are not needed and take up memory.
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
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.
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
Removing position: sticky; helped me and my mobile safari crashing issues. Not sure exactly why.
body:before{
position:-webkit-sticky;
position:sticky;
}
In my case the crashing was caused by using CSS filter: blur(2px) to create a colored "glow" effect.
I fixed it by creating the glow in photoshop and using a PNG file to render the glow on my website.
This not only fixed the crash but created a nicer, more even glow that also didn't re-render in strange ways when zooming and scrolling.
I am using gridx with dojo 1.8.3 library. My application requires a dojo grid to be refreshed every second with the data which comes from server.
Following is the code to refresh grid with creating a new store for every refresh.
The result comes in xhrPost callback and gets assigned to new grid store.
refreshGrid(){
if(grid.store!=null)
grid.store.close();
var newGridStore = new dojo.data.ItemFileWriteStore({
url:'',
data:result,
urlPreventCache: false
});
grid.setStore(newGridStore);
}
Above function is getting called for every 2 seconds and I could see memory increase in chrome profile.
I had tried using the way to iterate through the store to delete all the items followed by adding new items but when store is updated grid gets locked.
Which is the correct way of grid refresh in dojo?
Nothing you are doing looks sketchy, set store is the way to go unless you are refreshing specific items. The old store should eventually be deleted by the gc, but it does this delete whenever it feels like it and you will see a ramp up in memory usage until that point. In chrome you can force the garbage collector, so if you do this and your memory clears up then everything is running as intended and you may just be dealing with too much data too often.
It might also be useful to let us know what kind of performance decrease (if any) you are seeing, what your memory usage is ranging from, and what amount of data you are dealing with in your store.
I am using embedded browser in JavaFX. On my webpage, using Javascript, I dynamically create lots of checkboxes + some other components and remove them from the DOM afterwards. What is strange, after performing every "create/remove" cycle the memory usage is growing. Maybe it could be related to the click events attached to my elements? It seems like a memory leak, I have no idea how could I fix this. In regular browser like Chrome everything works fine.
I don't have much experience with finding memory leaks but I've been meaning to use Plumbr to test my JavaFX app for those - maybe you can use that?
You might have to sit there and keep clicking on stuff or script lots of interaction for Plumbr to notice the leak, since it seems to be focused on JSP apps which have a lot of simultaneous users.
I'm considering using SignalR to keep persistent (COMET) connections with my .Net server in a project where I need to update a client-side graph. I'm considering Flot of the graphing portion, but am curious how possible it is to display a "live graph" in this manner. Is Flot a good choice for this? I would like the server to be able to push new data to the graph and have it append to the existing data, as it becomes available.
I haven't found any examples of doing this, so am wondering if there is some difficulty in doing this that I am not anticipating.
Flot and Highcharts, the two I'm most familiar with, let you redraw the data as long as the axes and grid stay the same. They are pretty efficient in that case.
To use flot to append data to a continuous graph, you will end up just redrawing the whole graph all the time. In any modern browser (heck, even IE7), as long as you keep the number of points reasonable, the performance will be totally acceptable. I have pages with 4-6 flot graphs, updating every second, each having ~3-5 datapoints per second, with up to 5 minutes of data (so ~1000 datapoints per graph, 4000 points in total on the page). This is achieved with no lag, even on a low-powered machine.
I have not seen any libraries for managing this type of thing over top of flot, so I ended up doing my own caching.
I think the only "gotcha" you'll run into is making sure you don't let your memory usage run out of control. The first couple attempts I made at this, if you left the graph running overnight, you would come back to 4GB of memory used. Make sure you properly remove old data, and don't keep references to replaced graphs and AJAX requests.
There is a following problem: I am creating an editor, which EditorInput contains pretty big object. After creating couple of such editors I've got OutOfMemoryError. Heap memory analyzer showed, that there are 3 objects of type EditorHistoryItem, which take around 80,8% of the heap space. (I think, that I've even closed previous editors, but they are still in the memory).
I think, that those EditorHistoryItems-s are related to navigation history construction in eclipse. So, can I disable navigation history? Or what would be other correct way to dispose large EditorInput or EditorPart, without closing an editor?
Any advices would be much appreciated.
Well, make your object smaller. I'm pretty sure it's not neccessary to load several Megabytes of objects. Why don't you load a pretty small object as your IEditorInput implementation when opening an editor and loading/unloading additional objects based on user-interaction (activating the Editor-Part, several tabls, pressing a button, ...) lazily.
You have a pretty good control about getting notified if the user activates an editor, changing the page (when using MultipageEditor) or other events where you can load or unload objects to minimize the footprint of your heap. There is a absolutely no need to have a big IEditorInput object.
Depending on what editor functions you're using, Eclipse can have up to 5 copies of your IEditorInput in memory.
While this works great for < 1,000 line Java classes, you run out of memory when editing larger files.
Take a look at the source code for FileEditorInput, and see if you can write your own version implementing the IEditorInput interface that keeps most of your file on disk and just reads parts of the file.
Worst case, you'll have to write your own Eclipse editor.