Silky Smooth Browsing

Almost lost amidst the announcements yesterday of Amazon’s new Kindle Fire tablet is their new browser, Silk. Though some blogs picked up the story after all the hardware hype and media attention died down, most chose to focus on its privacy implications instead of the technology1. Out of all the analyses I found, ars had the best technical insight.

It was the technical implications of silk that had me the most excited – I guess that means I’ve been a web developer for too long. Server-side static resource fetching and caching, SPDY, and server-side script execution are all pretty nice upgrades from our standard desktop/mobile browsers, and Kindle webapp development is sure start up soon. While we don’t have the actual hardware and browser to test, it’s just fun to speculate, so here are some thoughts on what Silk means for the state of mobile web.

Some of the first comments about Silk was that the technology is not novel, that Opera Mini has had server-based page rendering for a number of years. It’s a valid point, but if anything the existence and continued success of Opera Mini validates the technology as solving a real problem in mobile browsing. It has very respectable global market share, and anecdotes suggest that it has a dominating presence in Asia. If Amazon can popularize the technique, a faster web experience is not a bad thing.

Digging down to the technical nitty-gritty, Amazon claims to fetch static web content (e.g., CSS files, Javascript, images, video) from the server, cache it for future reference, compress and zip it to the Silk browser. This does combine a good amount of front-end web optimizations:

• Gzip and CSS/JS minification, though I’m merely guessing that they’ll do the latter.
• Image spriting, CSS and JS file concatenations (really, just any technique that reduces HTTP connections).
• Referencing a common URL in hopes that the client has the file cached; for example, using the Google-hosted jQuery is faster than your typical CDN since chances are another site has also referenced the file and the client already has it cached. Similarly, common files for Silk users will be cached and readily accessible.
• CDNs in general, especially when the content already lives in Amazon S3.

That last point makes total sense for Amazon in retrospect. Anybody can build a server farm to proxy browser requests and cache resources, but Amazon is in a unique position with S3 to tie the cache back to storage they already own, which already hosts a percentage of the web’s content. It’s a competitive advantage that other CDNs won’t be able to match.

Moving on, Silk is able to split Javascript into server and client portions, and compile (into ARM) and execute parts of the code which can be done in isolation on the server. Honestly though, this sounds more like a technical bullet point than a real performance booster. Most real-world Javascript use in the browser involves manipulating the DOM, which would not be run on the server anyway, and the only real use I can think of is to mark DOM-manipulative code as hardware acceleratable. That is a pretty hard problem that browser vendors have had no luck solving thus far2.

And lastly, Silk will automatically compress content to be “appropriate for the form factor”, which in laymen terms means compressing and resizing big, overly dense images. The usual concerns of lossy compression are relevant here; it’d be a terrible user experience to see a page look worse because Silk decided to be overly aggressive in its byte savings. I’m also curious how Silk knows the optimal new size for an image – for instance, while I can legitimately use a large picture as a scrollable map, woe to the Kindle user who sees the map shrunk down to 800×480 to fit the tablet’s resolution.

In general, I do like all the new tech that Amazon is building into their new browser. In a few years’ time, it’ll hopefully gain enough traction for other browser vendors – especially mobile – to up their game.