If you head on over to ryumaru.com you can demo and download version 0.9.3 of the “Ryuzine” and “Ryuzine Machine” web apps.

This update represents a significant performance boost to the reader app and some new features/options in the authoring app:

Ryuzine Web App

  • Views preference now persistently stored in a cookie file so it automatically restores the last used view setting.
  • Can now send custom themes to BlackBerry tablets and Windows Phones.
  • Send different themes to Android 2.x and 3.x+
  • +300% faster loading time
  • 30-50% reduction in memory usage (depending on content)
  • 26% reduction in main script file size
  • Improved stability on iOS platform
  • Android 2.x page turn bug fixed (requires Android is not spoofing User Agent string)
  • “Widescreen” Android phones now correctly fill content in landscape orientation
  • Fully compatible with 0.9.2 Themes
  • Compatible with existing 0.9.2 Ryuzine HTML files*

Ryuzine Machine Authoring App

  • 19% reduction in main script file size
  • Simulator devices can now be skinned
  • Simulator devices can be zoomed in/out
  • Ability to add Custom Device profiles to the configuration file
  • Option to over-ride WYSIWYG loading even on supported browsers (if you prefer to hand-code everything)

Now for a little development background on this update.  I was at an electronics store recently where I was playing around with both the iPhone 4s and iPad 2 and was disappointed to see Safari would often crash when loading my apps.  Clearing the browser cache and making sure no multi-tasking was going on helped, but iOS typically just kills any process that uses “too many” resources, including Safari, rather than letting one rogue process bring down the whole OS.  That makes sense I suppose, but if you go check the user forums at Apple’s web site you’ll see some complaints about Safari crashing even with relatively simple “rich” web sites.  Obviously how iOS handles resource issues is out of my hands, but the app I’ve built is not.

So I set about trying to find things that would reduce the resource footprint.  What I hit on is actually something you’re not really supposed to do – at least according to various web design/developer resources I’ve read over the years:  continuously reflow the page.  Yep, you’re not supposed to constantly be changing the styles and causing CSS to reflow, but it turned out that was exactly the medicine my web app needs (and leads me to believe some of the “rules of thumb” may be a bit outdated concerning how modern browsers adapt).  What I ended up doing was completely rewriting the page-turning function so it selectively displays the contents of an individual Ryuzine page (flips between display: none; and display: block).  By default the contents of all pages (except the cover) are set to “display:none;” so when the web app first loads it only grabs the contents of the cover page, rather than ALL the pages (as it did up to 0.9.2).  As you turn pages it sets pages you are going to see to “display: block” which – in the mobile browsers in which I tested it – caused a request to the server for any image on that page.  In other words it didn’t load them with the page initially, it requests them a la carte.   Pages you’re not seeing are set back to “display:none;” and removed from the page flow.  Any images are still in the cache, of course, so going back to that page pulls them from there, but the real key seems to be to take it out of the page flow.

What I’ve learned in trying to optimize my web apps is that Javascript isn’t the problem, as the “engine” for that keeps getting faster and better in pretty much every browser release.  It’s the CSS Renderer, which is only now starting to get the same sort of performance-related attention,  that tends to get overwhelmed when you layer a lot of CSS effects (particularly CSS3 stuff like shadows, gradients, and rounded corners, and especially when they are literally layered with z-index one atop another).  Thus, taking objects out of this flow when they aren’t needed makes the CSS renderer work more efficiently.  So despite the fact I’m making it reflow constantly it has fewer objects to reflow so it becomes a net gain.

Now, this wasn’t true in older browsers.  Constantly overworking the CSS renderer was bad and some older browsers request everything from the server (everything in the stylesheets – even if it was for a different media-query case – and everything in the page even if it was set to “display:none;”) which obviously would increase load time, request a lot of items you may not even use, and hold a lot of data in memory you may not need.  It’s easy to see with misbehaving browsers in the Days of Yore how you wouldn’t want to put all your media-query cases in a single stylesheet, how you’d want to dynamically write in case-specific content (ideally from the server-side) as much as possible, and have it render the CSS only once.  Thankfully, in my testing across modern browsers, these issues all appear to have been addressed.  For example, to see what items were actually being requested from my web server I opened Safari’s “Activity Window” and also looked at my web server log file and determined that Safari 3.x would pretty much request every image for every media query while Safari 5 does not.  Which is why it is good to go back from time to time and fact-check the “rules of thumb” and see if they still hold true or not.  What it boils down to is I’m giving the CSS renderer more to do with fewer objects instead of more to do with more objects, which makes the performance enhancements pretty obvious when I put it that way.