SILK BROWSER ANDROID

I loaded each one 10 times in a row and averaged all of the run times. I started out by doing some raw web page loading tests. I detailed all of my testing procedures in a separate piece last week, but here are the relevant excerpts: It's no surprise that using Silk with accelerated page loading enabled offers no real benefits on the Kindle Fire. Neither of these things applies to the Kindle Fire in its state today. Saving bandwidth is really important on cellular connections that are either low performance or limited by data use caps (or both). I thought it odd that Amazon would debut cloud-based caching on a device that was WiFi only. There's a lot of good that can come from Silk's page loading optimizations, unfortunately almost none of it is realized today. For one person accessing a site there are no savings, but with thousands of people pulling the same page the benefit is clear. On a greater scale, Amazon can reduce the bandwidth load to site owners by serving already cached data from its AWS cloud rather than re-requesting the elements from the original servers.

Images and data can be (re)compressed before they get to you and Amazon can prefetch additional pages based on what it thinks you'll request next. With all content filtered through Amazon's servers there are two things that can happen: 1) Amazon can learn a lot about how Silk users browse the web and 2) Amazon can optimize the content within its cloud before getting to you. The Silk browser then only has to deal with a single host that all content is funneled through: With the Silk browser's 'accelerated page loading' feature enabled, any website you load is proxied through Amazon's AWS servers. Why assume that all page elements are optimally compressed for delivery to a sub-1080p display?Īmazon feels the best way to address delivering the desktop web to mobile devices is via its own cloud services. A single page load can require negotiating connections with dozens of servers, followed by downloading megabytes of content, none of which are optimized for mobile devices. I've already written about much of this publicly but I'll start with a quick recap.Īmazon insists that the browser is an aging limitation on the overall mobile experience. My biggest issues have nothing to do with performance however, they stem from the cloud accelerated browsing features of Silk. What may have been understandable a year ago is no longer the case today, particularly with Ice Cream Sandwich weeks if not days away from a US release. Web page loading performance is reasonable but the actual browsing experience suffers.

I've already explained that Amazon didn't bother to deliver the smooth, GPU accelerated experience we've come to expect from Samsung's SGS2 browser, Honeycomb or iOS. If there's one thing I'm not particularly happy about with the Kindle Fire it's the web browser. The missing feature is particularly upsetting in light of another, fairly large customization to the browsing experience that Amazon has chosen to introduce instead: cloud based caching. I don't doubt that Amazon will eventually enable a fully GPU accelerated browser at some point in the future, its failure to do so today is irksome.

The Vellamo flinger tests support our comments about scrolling performance: As a result the browsing experience on the Kindle Fire feels distinctly 2010 rather than modern day Android, particularly compared to the strides Google has made in Honeycomb and (presumably) Ice Cream Sandwich. Samsung in the Galaxy S 2), however it appears that Amazon has not done the same.

SILK BROWSER ANDROID

The choppiness is something that individual Android partners have addressed in their own custom browsers (e.g. Rendering (including JavaScript) performance is reasonable on the Fire, but scrolling down web pages is clearly sub 30 fps. Although Amazon has done an excellent job in making the Fire's home screen nice and responsive (read: fully GPU accelerated via a backing store), the browser does not receive the same treatment.