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:

Kindle Fire - Accelerated Page Loading Test

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:

Kindle Fire - Accelerated Page Loading Bandwidth

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:

Kindle Fire - Accelerated Page Loading - Download Speed

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.

Kindle Fire - Accelerated Page Loading Test (AT&T 3G)

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.

But Why?

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.

Comments Locked


View All Comments

  • tipoo - Wednesday, November 23, 2011 - link

    I think its "unique" in being crappier than Opera Turbo and Skyfire (well tbh I've never tried the latter). Opera Turbo can compress pages up to 60%, instead of 10% like Silk.
  • Conficio - Tuesday, November 22, 2011 - link

    These results are certainly surprising.

    I'd like to see in more details, what Amazon is really doing with the caching.

    * I'd like to see if there is any tracing/page prediction is going on?
    * I'd like to know if there is any change in the ability to cache the parts locally (like Amazon does determine that a certain image while marked by the original server as non cashable is in fact always the same and so Amazon relays it to the browser with cache flags.
    * I'd also like to know if there is any cookies that are exchanged in addition to the ones from the original web site.
    * The ability to read the cookie stream of all request would be a gold mine

    Hopefully Anand can get someone from Amazon explain for what kinds of browsing behavior one would expect an acceleration. If there is non Amazon is vulnerable for false advertisement claims.
  • mabellon - Tuesday, November 22, 2011 - link

    Hey Anand,

    I was under the impression that Silk was supposed to reduce round trips. In loading a website, a large number of http requests are made, which can be burdensome over high latency 3g. I was under the impression that SILK was trying to address this (kinda like SPDY, except SILK remains a fully compatible protocol as its more of a proxy).

    Actually, after a quick search I came across Amazon hiring for new SDEs to work on SPDY in SILK (http://aws.amazon.com/amazonsilk-jobs/)

    How high is the latency on your 3g service? Would you be able to test on higher latency (real or simulated)? I think this is the key to evaluating the value of SILK.

  • steven75 - Tuesday, November 22, 2011 - link

    ...it seems pretty clear you shouldn't buy the Fire for web browsing anyway, as it's not pleasant.
  • Harshad - Sunday, November 27, 2011 - link

    It is possible that because your content was being loaded from 13 different servers, there were 13 sockets open at the same time, and data was being loaded in parallel. However, with only a single server, the number of sockets would also be probably only 1. If this theory is correct, that might also impact the page load times.

    Can you find out how many sockets were open? It will probably require code modifications / rooting to find this out...
  • AnnonymousCoward - Monday, November 28, 2011 - link

    It ranks with:
    -The Killer NIC
    -Rage Pro graphics decelerator
    -physics hardware acceleration
  • InnerDivinity - Thursday, December 1, 2011 - link

    "It's interesting that even Reddit, a text heavy site, was able to see some benefits from Amazon's accelerated page loading feature."
    It seems like you didn't pick many sites that are hosted by Amazon, which is where SILK should really shine, and that's in their advertising. Googling around, I found Reddit, Foursquare, and Quora use EC2. I think it might be useful to incorporate this information the next time you test this, maybe on their next release as the service improves and/or other major sites make in on to AWS.
  • gh2m - Friday, December 9, 2011 - link

    Does anyone know what was used to identify the IP addresses with silk on vs off. I've run a couple trace tests and don''t see a difference in the ip addresses used.
  • tcboy88 - Monday, December 12, 2011 - link

    As we all know Silk is partially copying Opera Turbo
    But we are not sure about their comparison
    Can you make a comparison between them?

Log in

Don't have an account? Sign up now