Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement a global system to control DOM size #1555
Memory management: how to keep the DOM from getting too big?
A new global configuration option to set the max number of pages to keep in the DOM at once. Once that max is hit, we run a a document-wide $("selector").remove() at the appropriate juncture in every changePage invocation (post Ajax success) that finds all pages that are data-cache="false" or oldest in the stack and delete them. We’ll need to check for alreadyLocalPage = ("[data-url='...']:not([data-cache='false']")
Default to a sensible number like 15-20 pages but this can be overridden to any number more than 2 (to allow for transitions) or turned off completely
After discussing this, we might want to have a simpler mechanism for the nearer term until we really understand how memory is freed up on these devices:
When you hit the max number of pages in the DOM (if specified), the next link/form submit isn't Ajax-driven so the browser does a full page refresh.
I think the browser cache already solves this problem very well.
Let's say I want a browser to cache a page, so that future requests to that same page will be served locally from the browser cache instead of being loaded over the network. In that case I let the browser know that by adding some HTTP headers to the page (Expires On, Cache-Control, etc.). I'm assuming this works in most mobile browsers too.
One clear drawback of the current approach, that involves this issue, is that if the device becomes memory constrained, it can signal the browser to empty out it's cache, but not our page to clear out stale pages from the DOM.
I understand that keeping pages in the DOM improves transitions, but my guess is that pages served locally from the browser cache get loaded almost in an instant too.
So, the best solution in my opinion is to never keep remote pages in the DOM and let the browsers handle the client-side caching. We should then emphasize the importance of the use of HTTP caching headers and perhaps provide some sample code using popular server-side frameworks (PHP, Rails, etc.)
I'm lacking any expertise in mobile browsers, so I'm probably missing something. What do you guys think of this?
Thanks for the feedback. We're in the process of working on a system for automating page removal without removing certain types of pages that can't be refetched from the server (nested listview pages, local multipages, dynamically generated pages, etc). It's likely that we'll implement this in two ways: first, a configurable limit for the max number of pages to keep in the dom at any time (which could default to something quite low, maybe zero, who knows), and second, a simple mechanism to specify that a certain page should never be stored in the DOM, or that a certain page type should never be removed from the DOM through the max-limit flushing.
@wietsevenema makes a good point, and I generally agree that simply recommending standard cache configuration settings is a good way to go, but we'll need to test how well this plays out on mobile devices with limited capabilities, even newer ones.
Like wietsevenema and matthewdl said i also think that the best solution is to not built up a proprietary DOM cache. Control caching via the HTTP Header is common practice, most webdevelopers should be used to and the browser has a chance to manage its memory. Responses of ajax get-calls are cached by default corresponding to the http headers(pretty sure). The jqm page cache is reduntant. I think the current navigation and page cache model complicates things unnecessary.