Amazon's Silk Browser Acceleration Tested: Less Bandwidth Consumed, But Slower Performance
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.
http://www.fuseproject.com/blog/subscribe.php
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.
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.
Curious to measure the impact of Amazon's cloud-side caching, I did a bunch of benchmarking on the Kindle Fire. Read on for the results...