Amazon's Silk Browser Acceleration Tested: Less Bandwidth Consumed, But Slower Performanceby Anand Lal Shimpi on November 21, 2011 6:27 PM EST
- Posted in
- Kindle Fire
We've been working on our Kindle Fire review over the weekend but I thought I'd break out a particularly interesting section of the review for release a bit early. At its launch Amazon introduced a new web browser called Silk.
Silk is yet-another-webkit based browser with all of the usual features: tabbed browsing, Flash support, integrated search/URL bar, etc... What makes Silk unique is its ability to funnel your web requests through Amazon's Web Services (AWS) cloud. A typical load of AnandTech.com pulls content from thirteen different hosts. Each host is contacted, the request acknowledged and then data is exchanged between it and your browser.
Amazon believes that this is an inefficient way of loading a web page. With Silk, the request is sent to Amazon's cloud, where Amazon's servers retrieve (and cache) all of the elements of the web page and deliver the result to you directly.
The table below shows you all of the IPs that are contacted when loading AnandTech.com with and without Amazon's cloud acceleration feature turned on:
|Host Request List - AnandTech.com|
|Amazon Kindle Fire - Silk Browser||Accelerated Page Loading Off||Accelerated Page Loading On|
The list of 13 is reduced to a single IP address. The reduction is even more impressive if you look at what it does to a more involved front page like Engadget's: there the list drops from 34 down to 1.
Amazon claims the cloud-side caching can improve performance, however I was skeptical of this claim. A huge portion of web page loading on smartphone platforms is actually CPU bound. It's why you notice a performance difference when you upgrade from a two year old smartphone to a modern day model, even if both were running the same OS. The parts of the loading process that aren't CPU bound are typically limited by the speed of the cellular network you're on. AT&T's 3G at my house tops out at 3Mbps, but more frequently than not it's down in the 1 - 2Mbps range. Things are even worse on Verizon's EVDO network where I get sub 1Mbps speeds. Consolidating network access on a cellular network seems to make sense, there's just one problem: the Kindle Fire was launched as a WiFi only model.
Time Warner recently (finally?) upgraded the Raleigh area to DOCSIS 3.0. Customers can purchase cable internet plans maxing out at 50Mbps downstream. The WiFi stack in the Kindle is limited to around 15Mbps so even if you opt for a slower internet package you should be able to exceed what the Kindle Fire is capable of consuming. Not to mention those pesky CPU limitations will keep you from loading any web page at even 15Mbps.
The choice to launch this cloud-caching feature alongside the Kindle Fire always seemed suspect. If Amazon were to introduce a 3G Kindle Fire with a very affordable or even free dataplan, cloud caching might have made sense. In the interim, I was curious to see what it did to the web browsing experience on the Kindle Fire.
I started out by doing some raw web page loading tests. I picked three web pages: AnandTech.com, Engadget.com and NYTimes.com. I loaded each one 10 times in a row and averaged all of the run times. I did the same with and without the Silk browser's accelerated page loading feature enabled (cloud caching).
The results are below:
As expected, Amazon's accelerated page loading does nothing to accelerate page loads. In fact, it slows it down compared to going direct to the servers I'm trying to reach. The numbers are mirrored in my own use of the Kindle Fire. Web pages simply load slower if you have this feature enabled.
Bandwidth Savings: Approximately 10%
Amazon also argues that it's able to improve performance by optimizing content for the device you're viewing it on. In other words, Amazon is able to perform server side compression of things like images to deliver a seemingly lossless reduction in file size and thus improve performance.
This claim was a little more difficult to investigate as requesting a full uncompressed JPG didn't seem to go through Amazon's compression routine. Instead I sniffed the Kindle Fire's traffic on my network and looked at total bytes transferred for a handful of page requests. This time I looked at the same three websites from earlier (AT, Engadget, NYTimes) but also added CNN.com for something a bit more mainstream, and Reddit.com for something a bit more awesome (and text heavy).
To deal with the fact that these are live websites with ever changing content I ran all of the tests back to back, ensuring that the actual website content didn't change between runs. I also ran each test at least 5 times to deal with any differences in ads that loaded. I cleared the cache between each run to always request data from Amazon's servers. The results were remarkably consistent. Once again, the data is below:
The average compression ratio for these test web pages through Amazon's servers was 0.891. Everything seemed to reduce fairly predictably, the exception being CNN.com which saw a compression ratio of 0.801. It's possible that CNN's content is unnecessarily large and could stand for some server side optimization of its own. It's interesting that even Reddit, a text heavy site, was able to see some benefits from Amazon's accelerated page loading feature.
It's worth noting the average KB saved by enabling accelerated page loading is only 174KB. That amounts to just under 10% of the 1758KB average page size in this test. If you're severely limited by bandwidth caps, these savings might come in handy but otherwise they're not large enough to be noticeable.
If the amount of data transferred is smaller, but the pages take longer to load this can only mean one thing: the transfer rates are slower from Amazon. Indeed they are:
When loading NYTimes.com I averaged (again, over five runs, cache cleared between each one) 1.93Mbps with accelerated page loading disabled and 1.26Mbps with the feature enabled.
Curious to test my theory about cloud-side caching being a good target for a future 3G Kindle Fire, I tethered the tablet to my iPhone 4S and used AT&T's 3G network for all of the page loads.
I picked three sites this time around: AT, CNN and Engadget. I chose these three because CNN benefitted the most from Amazon's compression and AnandTech was penalized the most by going through Amazon's servers. Engadget was simply a good middle data point between the two.
Unfortunately even on AT&T's 3G network, Amazon's accelerated page loading made things slower. The impact wasn't as noticeable as it was over WiFi, but it's there. If you're a Kindle Fire owner and you want the fastest browsing experience, you'll want to disable Silk's accelerated page loading.
I'm left with a few questions about the cloud-side caching feature of Amazon's Silk browser. Today there are no obvious performance benefits to using the feature and even on AT&T's 3G network I didn't see an advantage. From the perspective of the end user, Silk's "cloud based" caching is not only meaningless, but it's a detriment to the overall user experience.
Surely Amazon must have done this testing internally and chose to launch the Kindle Fire with it anyway. There's a huge advantage from Amazon's perspective to millions of Kindle users browsing with it enabled: data mining. Amazon can learn a lot about the usage patterns of its users by just monitoring Silk requests to AWS servers. In theory Amazon could take this data and further optimize the browsing experience for Silk users. There are far more nefarious explanations as well that I won't dive into here.
It's worth noting that all of the websites I tested with today seem to be on fairly robust networks. The accelerated page loading feature could have a positive impact when accessing sites that aren't well hosted. I'd say that list is probably fairly narrow these days given the plethora of free content hosting services (wordpress, blogger, imgur, flickr, etc...).
There's also the possibility that Amazon is working towards enabling a 3G Kindle Fire with a more affordable/free dataplan. In doing so it would be motivated to reduce bandwidth consumption as much as possible.
Until Amazon either gets more aggressive with Silk's cloud-side caching or it releases a device that really requires the bandwidth savings, I am a bit puzzled by the focus on the feature at launch.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Anand Lal Shimpi - Monday, November 21, 2011 - linkFixed, sorry about that!
jjj - Monday, November 21, 2011 - linkThe second grapth does appear to be reversed.
If Amazon trully plans to make a phone too(although i see little reason for it at this time,unless they got some new services to offer soon) then Silk could be built for the phone and this is more of a beta testing.
Have you checked if Silk saves time at the next step,it was supposed to do that ,if i remember corectly,to try to guess what the next page will be and preload it (ofc they could just preload on their servers all pages a certain page links to).
You shoudl also check non US based sites/mirrors,could make a difference even for well hosted sites.
Anand Lal Shimpi - Monday, November 21, 2011 - linkI tested this as well - I clicked through all of the pages of our Interlagos review, there's still a 14% load time penalty with Accelerated Page Loading enabled. Prefetching is definitely interesting but it doesn't appear to be aggressively enabled here (if at all).
jjj - Monday, November 21, 2011 - linkWell,it can get better.
Thanks for the replly
MagickMan - Monday, November 21, 2011 - linkYep, they're data mining to get more customer info. Surprised? It's a $200 tablet and they're looking to make up some of the money they're "losing" for selling it so cheaply. Not that I think they're really losing money, probably about breaking even, but they'll do what they can to turn a few more bucks. I'm sure it's somewhere in the EULA that they're doing something like this, and every owner agreed to it when they started using the Fire. That's life. I guess users can hope that they're not going to do anything too malicious with that info.
Lonyo - Monday, November 21, 2011 - linkSeems kinda obvious, but any chance of running some tests on the Amazon.com website?
Might be rather difficult in terms of it being a very dynamic site a lot of the time, but certainly it would be the most interesting test case given that it's Amazon hosted.
StormyParis - Monday, November 21, 2011 - linkToo bad you didn't compare to a different and more mature implementation of the same technology, ie Opera Mini.
tipoo - Monday, November 21, 2011 - linkOpera Mobile with turbo enabled would be a better comparison. Mini renders the page completely in the cloud, its a completely different way of browsing, vs Silk which just caches DNS requests and whatnot. And really, you only need Mini for slow, older phones, anything newer and Mobile is usually faster (except the odd extremely heavy page like The Verge) and Mini's browsing mechanism does break some pages.
name99 - Tuesday, November 22, 2011 - linkWay to miss the point. The USER does not give a damn HOW the technology works. What they care about is
- does it speed up browsing?
- does it reduce data transferred?
Saying "well Amazon does a crappy job because they chose to use a different approach" is not an excuse. Amazon claimed to achieve a certain goal, and they don't succeed --- it really is as simple as that.
tipoo - Tuesday, November 22, 2011 - linkTest both then, Mini is usually the slower of the two, hence why I suggested Opera Mobile for newer phones. Nothing to get your panties in wads over.