Last modified: 2012-02-24 02:52:05 UTC
Loading a bookmark loads the html without js/css, which load quite slowly. Leads to unstyled bad looking plain-text for about 10-15s on my device.
Yeah, this is a side effect of how the caching currently works; basically there's a low-level caching plugin which fetches the original page content exactly, and then the JS comes and does fixups to the styles and links. Eww? Saving the fixed content instead would help.
Is that even possible? ('saving the fixed content')? Save final serialized DOM tree structure, perhaps? Can DOM trees even be serialized?
I saw this behavior when hitting the back button, but the page would never load fully and the app crashed (this was reported as bug 32998).
I worked around this by hiding the iframe during initial stages of load, and showing it again after the styles had been replaced. commit 6457d1ce676996099cf30544d7db7af33b3a23b8 bug 32998 still remains however.
Not sure if this is 'good enough' - the content area blanks out for about 15-20 seconds on my phone when I load a bookmark. Also happens when I simply add a bookmark. Is there a 'proper' fix?
This no longer happens when bookmarking on my cachework branch, as the pages are loaded through urlcache to begin with now. Can you build that locally and test how long it takes to load things for you? https://github.com/brion/Wikipedia/tree/cachework This does leave us waiting for the entire HTML to load, but once one set of styles has been cached they should stay pretty well for a while so won't cause additional delays beyond the HTML for second page and beyond.
Just tested it, seems to be the same (15s for India article from bookmark for both master and cachework). Seems to vary by article size - Adulasion Horse article takes only 7s (on both) for example.
Darn... may be that the only good way to handle this is to modify the pages before caching -- that means tweaking the cache... a lot...
I'm going to go ahead and close this out and break out the slow loading issue to bug 33197 -- I've made that a blocker on 1.1 release and added a note that changing how the caching works so we save the already fixed-up version should resolve the slowness without reintroducing flash-of-unstyled-content.
