Every second counts. Every second earns a customer more money. We are all greedy.
Given the strong correlation between performance and making our customers more money, we are inevitably motivated to move to the extremes of the performance landscape, always striving to eke out as much as we can.
As we move to the extremes, we inevitably start developing techniques and features specific to different browsers. One of the risks in front-end optimization is the fact that, at the end of the day, our work is consumed by a browser — an ever-changing and dynamic animal over which we have very little control.
This is a cautionary tale for those building some of the more sophisticated optimization features directly into their code.
How one simple action by Microsoft cost customers millions of dollars in lost revenue
Part of our responsibility as experts in our field is to be up to date on all things related to performance, no matter how seemingly mundane. In January, we stumbled across an IE bug here, which described a serious limitation in MHTML. (Briefly, MHTML is a consolidation technique widely accepted as a good way to reduce total page resources in Internet Explorer browsers. For more background, Stoyan Stefanov has written a couple of good posts here and here.)
At Strangeloop, we use MHTML to get resource reduction in some cases. With all of our optimization techniques, we have mechanisms for finding and correcting failure, so we were able to get on top of this bug quickly. (We have a lot of scar tissue around browser changes, and our largest enterprise customers expect us to have redundancy and fault tolerance — even when it comes to features.)
However, for people who have built MHTML directly into their code, this was a mission-critical problem that they probably knew nothing about. In fact, in January, when Microsoft reacted and turned off the technique in its most recent patch (which you can read about here, here and here), customers who had combined browser-specific optimizations directly into their code broke pages.
This one simple action by Microsoft cost customers millions of dollars in lost revenue and countless millions in late-night code refactoring and testing. I spoke to someone yesterday who still had parts of their site breaking because the code refactoring was so complex and the original coders had moved on.
Managing risk: Why we need to separate function from design
For the people I talk with everyday, the ecommerce websites they run are mission critical. They are the golden goose that produces higher margins than the rest of the business and an increasingly large share of revenue.
For years we have advocated the separation of function from design — which is the core premise of tools like content management systems. We are now at a point in the optimization market where I believe strongly that enterprise customers must separate browser-specific acceleration from code so that they can avoid catastrophic risks like this one.