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. 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.
- 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.
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.
- 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.↑