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 technology{{1}}. 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.
[[1]]It’s not that I don’t care about privacy, but I feel like privacy is the wolf cry of many a journalist. Amazon isn’t in the business of selling your information (if anything, Google and Facebook are), and this particular issue can be immediately resolved by turning off the server-side proxy or better yet just using a different browser.[[1]]

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 far{{2}}.
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.
[[2]]Well, CSS3 animation would be the solution, but that’s a world away from being able to decide whether arbitrary Javascript can be hardware accelerated.[[2]]