How Amazon Kindle Fire's Silk Web Browser Works

By Bobby Schweizer

Amazon is using its vast server infrastructure to speed up the Kindle Fire's browsing experience with Silk.

Alongside the slew of Kindle hardware announcements last week came news of a new web service that promises to speed up the Kindle Fire's browsing experience. Known as Amazon Silk (also the name of the Kindle Fire's web browser), this service takes advantage of Amazon's Elastic Compute Cloud (EC2) infrastructure to more quickly serve up pages, media, and even scripts.

Despite the improvements in the quality of mobile hardware—both phone and tablet—the speed of web content still remains under the domain of those hosting it. It doesn't matter how fast your hardware is when the real bottleneck is located at the point entry. To solve this problem, Amazon has offered to offload this work onto its own servers. While not the first browser to act as a middleman in serving content (Opera's been doing it for ages), Amazon is using their portfolio of server technologies to do more than compress images and pre-render pages.

It's immediate application may be the Kindle Fire, but the implications of Silk could be far reaching. To understand how Silk may evolve, we need to look at both its technology and the issues it raises.

In an era where the 7-inch tablet formfactor is becoming more popular, it's important for companies to distinguish their products. Price, weight, speed, app store—these are all important. But impressing someone is as simple as showing them a fast browser. Technology enthusiasts may not be wowed by such a mundane task, but contrary to marketing slogans, there's not always an app for that and the browser remains at the heart of the computing experience. It's a relatively safe bet that videos will surface comparing page load times between the Kindle Fire and its nearest bookstore competitor the Nook Color. And, if Amazon does their job, there will be no contest.

The Silk technology claims to do the heavy lifting for the browser. It pre-caches content, prepares possible linked pages for quick loading, compresses files to fit the display's aspect ratio and resolution, and establishes a single pipeline to send and receive data. So instead of the browser having to render a hundred different files coming from both the site's host and all the off-site linked content, Amazon effectively temporarily hosts much of that content instead.

How does it make these decisions? Well, Amazon has a long history of predicting what its users will like based on browsing habits. Amazon will be collecting enormous amounts of information from its users to determine traffic patterns to guess where the user might go next. Silk's EC2 component will decide which files are worth handling on their servers and the rest will be loaded as usual. Amazon can pre-cache content from the New York Times that will be at the ready for any Fire user who seeks out the daily news. And, because all of this is being done server-side, Amazon has its vast computing power at its disposal.

Not only does it have access to powerful servers, Amazon's EC2 is connected to the backbones of the internet. Amazon claims that it can reduce the average round-trip latency of wireless connections from 100 millisecond down to 5 milliseconds. And that's for all the stuff that resides outside of Amazon's Web Services infrastructure. Sites hosted and files already stored on EC2 or S3 are at an even greater advantage. If content creators see a high rate of Kindle Fire adoption among users, they may be compelled to move their files to AWS. Amazon, then, stands to make money on both ends of the deal.

Silk also uses the SPDY protocol developed by Google to reduce latency in web requests. At the time it was developed, it was okay that HTTP was fetching only one file at a time. But modern sites are composed of hundreds of files, many of which are refreshing regularly. SPDY accelerates the process by using a single session between browser client and server that compresses data and is able to transmit files in parallel. The problem with SPDY thus far was that while Chrome was able to handle the request protocol browser-side, very few clients bothered to connect to SPDY on their end. But because Amazon is handling both the browser and the client in the Silk infrastructure, they can take full advantage of this experimental protocol.

But while this all seems ideal, questions remain about the implications of Amazon's Silk. Matthew Baxter-Reynoldsof the Guardian wonders if the average user will be able to tell a difference between Silk and regular browsing, wondering whether Amazon's speed estimates are too optimistic.

Other writers like Thomas Claburnand Adrian Kingsley-Hughes have raised privacy concerns. Each Kindle is associated with a unique user and, while Amazon has said that browsing data is being aggregated anonymously, there are certainly portions of Amazon's business models that would benefit from knowing more about its customers. It will be possible to switch off the Silk functionality to an "off-cloud" mode, but the user will lose all benefits of accelerated browsing.

Joe Brockmeier of ReadWriteWeb speculates that the Kindle Fire is merely a test-bed for the Silk browsing platform and that down the road we'll see a Silk desktop browser. Releasing a desktop browser right away would overwhelm Amazon's servers, but by first including it with the Fire, Amazon can keep their user base manageable.

We'll soon find out if Silk is all it promises to be. The Kindle Fire will be released on November 15 for $199. And, if you want to be one of the first to try it out, its available for pre-order.

Lead image via