Amazon Silk and Performance Responsibility
Now that Amazon’s Kindle Fire tablet is making its way into customers hands we are starting to hear about how its much touted Silk web browser and its web acceleration feature functions in real life. Initial research shows that, at least in this 1.0 release, Silk is actually faster with acceleration turned off.
I don’t want to focus on how good or bad Silk’s acceleration feature is. Technology only gets better. I agree with Steve Souders that Silk will eventually provide a faster browsing experience. Making Silk’s acceleration work is a technical issue which Amazon can solve. Instead I want to focus on the larger policy issue: Who is responsible for web performance?
With Silk, Amazon is telling web developers that they suck at making fast sites. In fact, they suck so much, that Amazon is not going to wait for them to stop sucking. Instead Amazon has taken the unprecedented step to proxy all of the web traffic of Silk users and apply performance optimizations on the fly. Its mod_pagespeed, but in reverse.
The traditional view is that it’s the website owners’ responsibility to make a website faster. But Amazon is saying “its the creator of the consumption device’s responsibility to make a website faster.”
That’s pretty startling shift in view.
Amazon has made a business decision that the Kindle Fire will provide the fastest tablet browsing experience possible. (Sound familiar?) To ensure this happens, Amazon developed its own web browser and is spending millions of dollars on the infrastructure to support this acceleration feature. Web server does not support SPDY? Solved. Website not using compression? Solved. Content not minifed? Solved. But only if you are using a Kindle Fire.
In other words, web performance is so poor that hardware vendors are able differentiate themselves by solving your website’s performance problems.
It’s not surprising that Amazon decided to take matters into its own hands I have written extensively and presented Zoompf’s research at Velocity numerous times on the matter. 70% of images aren’t losslessly optimized. 75% of sites have an item which should have HTTP compression which doesn’t. 30% of webpages contain errors. Even Twitter is choking on implementing some of the most basic of optimizations. It’s not pretty out there.
But is it really a 3rd party, be it a online retailer, a consumer electronics company, a network device manufacturer, or a software vendor, who magically absolves you of the responsibility to make a fast site? This is an interesting question.
I am of the opinion that it is the web app creator’s responsibility to make it fast. In fact, the entire philosophy of Zoompf is, ultimately, web performance transparency: Scan my site; tell me specifically what the performance problems are; tell me how severe they are and what their impact is; show me how to fix them with configuration, process, and code changes; validate they get fixed; monitor and track that they are not re-introduced. No magic. No obfuscation. No “trust us, performance is hard, we got this, pay no attention to the man behind the curtain.” Just data, and the tools and guidance to make informed decisions.
Who is responsible for web performance? Who do you think? This question that will play out over the next several years and I’ll write more of my thoughts soon.