The Internet is on, er, Fire with chatter about Amazon’s new tablet, the Kindle Fire. It should be, because the birth of a credible iPad competitor is huge. In the long term, the most important part of Amazon’s announcement this morning isn’t the fairly vanilla tablet hardware or even the tablet’s spit-shined version of Android. What will really make waves is Amazon’s new web browser, Silk.

Silk is the first truly new, mass-market, client software delivery mechanism to be built from the ground up with the cloud—not just the web, but the cloud—in mind. But before we look at what Silk is, it’s helpful to take a quick glance at one thing it’s not.

The main thing that Silk is not, is Google Chrome. Chrome is essentially an OS in browser drag, and in this respect it’s very much a “fat” take on “thin client.” Google’s browser treats tabs the way that an OS treats running applications, and it walls them off from each other in separate processes so that problems with one tab don’t affect the rest of the browsing experience. You could sum up Google’s overall design approach to Chrome with something like, “the web is now an application delivery mechanism, and the browser is the OS that those apps run in.”

The fact that Chrome comes with such an extreme amount of OS-like baggage is what keeps it off of handheld devices. Devicemakers are much better off with a more traditional, lightweight browser like Android’s. At least, they were until today.

Like Chrome, Silk is a “browser,” and also like Chrome, it’s a lot more under the hood. Or, rather, it can be a lot more under the hood, depending on how you choose to use it.

In its simplest form, Silk is yet another Webkit browser. According to Amazon’s Silk Terms & Conditions page, Silk can be run in “off-cloud” mode, where it functions like any other browser. So Silk has all of the parts of the basic browser rendering pipeline in it, and it can use them if it needs to.

However, when Silk is run in cloud mode, it can off-load some of the the parts of the browsing and rendering process to EC2. In cloud mode, EC2 acts as a sort of cache plus proxy for browsing, and it also can dynamically take over parts of the page rendering pipeline from the client. Let’s look at each of these features in turn.

Caching and proxying on EC2

To speed up browsing, Silk uses EC2 to carry out some of the functions of a proxy server and a cache. The client portion of Silk passes a URL to the EC2-hosted portion, which then goes out and fetches all of the parts necessary for rendering the URL—HTML, CSS, images, Javascript, etc.. Since many of these resources are coming from sites hosted on Amazon’s cloud, EC2 will be able to load them very quickly and, though Amazon didn’t mention this in the announcement, without paying any kind of transport costs since that internal AWS traffic doesn’t go over the public Internet and is essentially “free” to Amazon.

The EC2 part of Silk can then optimize these resources for the specifics of the client that requested them; so if an image is too large, for instance, EC2 will resize it to fit the client’s screen resolution.

There’s also a machine-learning component to this caching/proxy functionality, where the EC2 component will monitor a client’s browsing patterns and use that data to predict which pages the client is likely to load next. EC2 will then pre-fetch the predicted page’s components and begin work on them, so that the complete page can be quickly delivered to the user via single server-to-client link.

Rendering pages on EC2

Once the components of a page have been fetched and cached on EC2, the page must be rendered for display in the client’s browser window. Depending on the amount of load on the client and the client’s network conditions, Silk can hand off most of the actual rendering pipeline to EC2.

The Silk video that Amazon posted on its bloglists the following as components that can be dynamically handed off to EC2 in order to speed up browsing:

• Networking
• HTML
• CSS
• Collections
• Javascript
• Marshaling
• Native OM
• Formatting
• Block building
• Layout
• Display

Now, this list pretty clearly didn’t come from the Silk engineers. It was most likely put together by the video production team, who almost certainly used this MSDN article on Internet Explorer performance profiling as a source. There are two giveaways here, the first of which is that the word “marshaling” is misspelled the same way by the Amazon video and the MSDN piece. The second giveaway is the last entry, “display,” which by definition has to happen on the client and not on the browser.

But the Amazon guys did us a favor in inadvertently pointing us to the MSDN article, because it contains a good description of each of the above steps, which are pretty typical for all browsers (although the division of labor between discrete steps can vary). Even more importantly, the piece also contains some great data on just how much time a browser spends in each of these phases for a typical news site.

Take a look at the pie chart above, and think about the fact that everything but the purple slice can be done on EC2—and even some of the purple slice can be done on EC2 if we assume that in extreme cases EC2 will just serve the client a pre-rendered page as a flat image file. That’s a huge potential speedup, and it doesn’t even include the networking part of the rendering process (i.e., the part that the proxy component described in the previous section takes care of).

A cloud OS?

Though it wasn’t announced today, my guess is that Silk is also an “OS” very much like Chrome, but the OS parts—namely, the parts that isolate pages into separately running processes—live on EC2. If Silk implements the same kinds of OS-like, page-as-application features on EC2 that Chrome does on the client, then it’s fair to call Silk a kind of client-side cloud OS. Yes, the term “client-side cloud OS” seems like an oxymoron, but that’s what it would be—it’s a client OS for running pages-as-apps, where much of the OS machinery runs in the cloud.

And if these OS-like features aren’t in the current version, I can’t imagine why they wouldn’t make it into a later version. Amazon can just throw EC2 cycles and memory at the same security and stability parts of the browsing experience that Chrome spends client CPU resources on.

Mobile ad dominance

On a final note, IntoMobile has a great angle that I’ve not seen anywhere else, but it’s worth nothing. Specifically, Stefan Constantinescu points out that the cache/proxy portion of Silk acts as a kind of uber-cookie that has the kind of tasty web history data that advertisers salivate over. (I’d go even further and point out that Amazon is already doing analytics on that data for predictive purposes, so it’s in a state that advertisers could readily make use of.)

Amazon could use Silk as a killer mobile advertising platform, should the company choose to port the browser to other platforms. And why wouldn’t they? Kindle is already running on almost everything with a screen, and I would certainly love to try out Silk on the desktop. With Silk, Amazon could give Google a run for its money in mobile ads, and one-up Apple by succeeding in a realm where the computer maker has so far failed.

Right now, the only company that could conceivably match Silk is Google—there’s no way Apple will get anything like this off the ground in the next two years. So the ball is in Google’s court to get Chrome up-to-speed, assuming that the search giant wants to do this big of a fundamental rethink of its flagship client app.

Have any news tips, or just want to send me feedback? You can reach me at jon underscore stokes at wired.com.