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
steven75 - Tuesday, November 22, 2011 - linkMisunderstanding the security encryption? No.
regread - Monday, November 21, 2011 - linkFYI Consumer Reports' testing agrees that Silk is slower.
"The biggest surprise to our tests might be that we've found little advantage to Amazon's Silk technology, which purports to speed up loading Web pages on the Kindle Fire's browser. Indeed, in our tests so far, many pages took a bit longer to load when the Silk's supposed accelerator was on." (Nov 18, 2011 6:00 PM)
Belard - Tuesday, November 22, 2011 - linkLets see how good and fast Amazon is at coming out with an update that:
A ) Disables "accelerator" or
B ) Fixes their data mining "accelerator"
before it becomes bad press.
But really, for data mining, do THEY really need to do this? They already get lots of customer information from their BUYING habits.
DrApop - Monday, November 21, 2011 - linkI think the main thrust for Amazon will be the data mining. But as was mentioned, the real test will be whether or not the average user will see a speed increase over time.
Amazon should be able to examine web address trends over time and then cache those sites to send direct to the user when requested. Depending on your surfing patterns, you may or may not see any different....depends on whether you surf with the pack or go your own way.
doesnotcompute - Monday, November 21, 2011 - linkWhile this approach might save some DNS lookup time, it probably cannot compensate for the additional latency. After all, the bytes have to go over the Internet from the source to AWS and then to your Kindle Fire -- 2 hops instead of one. Amazon need to be alot more aggressive in caching pages, which unfortunately cannot work with many of the dynamic content sites.
name99 - Tuesday, November 22, 2011 - linkYou are wrong. This approach CAN work well. I use a (conceptually similar, in practice different approach) on my iPhone and iPad --- I route all URLs through either Google's or Instapaper's HTML rewriting services. So what I am doing is
- send a URL to Google/Instapaper
- the remote server reads the page, reformats it, strips out crud on the sides of blogs, shrinks the images, etc
- the new page is sent to me.
Even with all that work, this is NOTICEABLY faster than connecting to the page directly, over either 3G or WiFi.
The problem is not that the concept can't work; it's that Amazon appear to have a lousy implementation. It's conceivable, of course, that they hired the same capacity planners that Apple seems to hire (over and over again :-[ ) so their servers are currently massively overloaded, and things will improve as they do a better job of handling the load.
vol7ron - Thursday, November 24, 2011 - linkNot to mention the pages will be cached. There are already free web proxy's out there that do this same thing.
The more active the site (more viewers) the better the cache will be kept up to date, thus a better chance for you to hit against the cache and not wait on the refresh.
solipsism - Monday, November 21, 2011 - linkWhat about trafic between Amazon.com? Surely that was faster with accelerated page loading?
vol7ron - Monday, November 21, 2011 - linkAnand,
Could you run a traceroute between your site's IPs and Amazon's IP and see if network congestion could be a culprit?
You might also want to mention how ping/latency makes a big difference in load times (not just about Mbps). Regardless, yet another great article - don't be surprised if I sign off on YAGA ;)
s44 - Tuesday, November 22, 2011 - linkHow is this "unique" when Skyfire has been doing it on Android for ages?