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:

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.

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.