Industry news

Announcing the Strangeloop Mobile Site Optimizer

21 Sep 2011

13 Comments

Patents have been filed, bugs squished, datasheets reviewed… and today, we’ve announced that Strangeloop has developed the world’s first advanced front-end optimization solution for mobile devices.

To say that I’m excited would be an understatement. As anyone here can tell you, I’ve been haranguing our dev team about it every day for months — years, actually. They’ve politely (for the most part) tolerated me, and in the end delivered a product we’re all incredibly proud of.

Our marketing team has put together some excellent materials explaining what Mobile Site Optimizer is. I want to take a different approach and talk first about what Mobile Site Optimizer isn’t.

Mobile Site Optimizer is not:

  • A tool that designs mobile-specific sites.
  • A suite of desktop optimization best practices disguised under a shiny new label.

We’re not getting into the business of mobile site development.

Companies like Mobify are already in the business of designing slick, mobile-specific sites, and they do a great job. That’s not a business we want to get into. Mobile Site Optimizer will make m.domain.com sites faster, it’s true, but we also wanted to take on the challenge of making the full site faster on mobile browsers.

But why do we want to do this, when companies can just create a mobile site? Two reasons:

  1. Earlier this year, when we were digging into our beacon data (gathered over the course of hundreds of millions of transactions on our customers’ sites), we noticed something interesting: 1 out of every 3 people coming to sites via mobile devices chose to view the full site, when that option was available.
  2. “Mobile” is a huge umbrella that includes tablets. Anyone who’s been paying attention knows that tablets are set to dominate the personal PC marketplace. This year alone, 15% of PC sales were tablets, and that number is only going to rise. Tablet owners don’t want to see a scaled-down version of a site. They want the full-site experience. Yet tablets are subject to many of the same performance pains as smartphones: slow parsing speed (10-20x slower than desktop) and greater latency (up to 6x), not to mention the roughly 300ms delay caused by the need to convert touch to click events every time the user taps the screen.

Mobile website performance and user behaviour

So why not just slap a “Mobile” sticker on our desktop Site Optimizer?

We considered it. In fact, we tried it. We even got jealous when we saw others do it. After all, we knew that Site Optimizer offers an unparalleled suite of optimization treatments. And with hundreds of deployments under our belt, including some of the biggest companies and sites in the world, we knew Site Optimizer could scale securely.

But the more we dug into the mobile space, the more we realized that mobile environments pose some challenges we’d never faced with desktop. At the same time, we realized that mobile also offered us some pretty cool opportunities.

And at the end of the day, we just couldn’t resist tinkering around solely for the fun of it.

So we went for it. We bought tons of different devices, hooked them up to different networks, and started studying waterfalls (a geek’s paradise). And as it turns out, those challenges I mentioned above — parsing speed, latency, touch screens, and more — ended up spurring the development of eleven never-before-seen optimization treatments designed exclusively for mobile devices. Here are three of my favourites:

Mobile SuperCache

On the desktop, the browser cache is a key tool for delivering faster pages to repeat visitors. On mobile browsers, not only are caches notoriously tiny, they also get flushed all the time — even sometimes within a single visit — making them practically pointless. Mobile Site Optimizer gets around this by taking advantage of an HTML5 feature called Local Storage to configure storage (in mobile browsers that support HTML5) that is both persistent and reliable. The Mobile SuperCache goes far beyond just getting things into cache. It includes invalidation, prioritization of objects in cache, the ability to cache in-lined objects, and some additional cool secret sauce that you will need to call me to find out about.

Touch Event Conversion

As I mentioned above, every time a mobile user touches their screen, the device has to translate that touch event into a click event in real time. Typically, this takes about 300 ms, but it can take up to 0.5 seconds. Those touches add up. So we found a way to automatically convert all those clicks into touches, relieving the browser of the realtime overhead of conversion.

Dynamic Payload Decision Making

This feature is my pet. (Don’t tell the others.) We found ourselves really challenged by the idea that one of our standby Site Optimizer treatments, Predictive Browser Caching (aka Preloading), which delivers fantastic acceleration results on the desktop, might actually be a huge negative for mobile users. Predictive Browser Caching works by intelligently guessing where a user is likely to go next and preloading those page resources in the browser. This is great is you’re on a Wifi connection, with practically unlimited data, but what about when you’re out and about, roaming on your 3G or 4G network? Sending all those resources — some of which you may never see — could eat up a lot of your data plan.

Our challenge was to squeeze as much benefit as we could out of Preloading, without bottoming out people’s data plan. So we came up with Dynamic Payload Decision Making, which recognizes each user’s network connection in the moment, and makes sure that the user is served pages optimized according to their network limits. As one example, if you’re at home, you get a more aggressive version of Predictive Browser Caching. If you’re out on the street, you get only a trimmed-down core set of preloaded objects. You win both ways. This is just one of many dynamic payload decisions we make, but the goal is always to serve the end user’s best interests.

I could go on all day (really — ask anyone), but I’ll wrap things up here and direct you to discover our other eight treatments on our site. On top of the usual datasheet and whitepaper, we’ve also got some infographics that illustrate why mobile performance should be a big deal, as well as a pretty nifty video that shows how Mobile Site Optimizer works. Here’s a peek:

Before I sign off, I want to thank our lead developers on this project, as well as our CTO, Kent Alstad, and our VP of Product, Hooman Beheshti, for their incredible work over the past few months. I also want to tip my hat to the rest of the amazing team here at Strangeloop, who made this industry first possible.

*We didn’t entirely forsake Site Optimizer. We ran our desktop treatments through a battery of tests and kept those that delivered benefits to mobile.

Related posts:

By: Tammy Everts Category: Tags: , , , , , ,

Google’s new Page Speed service: A handy resource for smaller site owners

28 Jul 2011

9 Comments

I wasn’t planning to write a post about Google’s new Page Speed service, but a number of people have asked me for my thoughts, so if you’re following all the discussions, you can add this post to the pile.

The main, and most obvious, question I’ve been asked is, “Is the Page Speed service a threat?” In short, no.

Last fall, when Google announced mod_pagespeed, we here at Strangeloop opened our arms wide to give it a great big hug. The entire Page Speed suite offers some good basic content optimization treatments. Because mod_pagespeed is open source, we were happy to have the opportunity to cherry pick the few treatments we didn’t already offer in our Site Optimizer products and integrate those.

Page Speed will be a handy resource for smaller sites with little to no complexity, whose owners don’t have developer time to pour into hand-tuning their sites, or the money to put into investing in an advanced performance automation solution. It fills an important gap in the market, and while it may not solve every performance pain, it should solve some — hopefully giving small business owners a chance to level the playing field by speeding up their sites enough to remain competitive in an increasingly brutal online marketplace.

To me, what’s most compelling about this announcement is that it offers still more validation that site speed is a crucial business issue. With all the press Page Speed is getting, it’s great to know that this message is getting out to the general public.

Related posts:

By: Tammy Everts Category: Tags: , , , ,

Lots of news on the Strangeloop front

15 Jun 2011

1 Comment

It’s been a busy week, even by Strangeloop standards:

Monday: We announced that we’ve successfully integrated Google’s SPDY protocol into our Site Optimizer appliance and service, making Site Optimizer the world’s first commercial product to offer site owners the opportunity to implement SPDY automatically on their sites. For background, our official press release is here, but I also really like this write-up by Steven Vaughan-Nichols at ZDNet and this one by Erica Naone at MIT’s Technology Review.

Tuesday: We announced that we’re partnering with Neustar Webmetrics to combine their ability to put their finger on precisely where performance pains happen with our ability to fix those pains. Neustar has a fantastic team, and we’re really looking forward to working with them.

Wednesday: Steve Souders announced at Velocity that Strangeloop is one of the sponsors of the HTTP Archive as it grows to support one million of the world’s leading websites. The archive promises to be an invaluable resource to those of us who care about tracking changes in how sites are built and delivered. (Case in point: Did you know that in just six months — from November 2010 to May 2011 — the average site grew by 8%, from 658k to 711k? That’s a pretty huge change for such a short time span! And we know about this change thanks to the archive.)

And the excitement isn’t over — now everyone’s at Velocity. (Including me, finally! My flight got delayed in Denver, and I just arrived.) While I’ve missed a chunk of the proceedings, there are still a lot of great sessions to look forward to, and great people to catch up with. If you’re here, say hi.

Related posts:

By: Tammy Everts Category: Tags: , , , , , , , ,

WPO? WCO? FEO? Unmuddying the web performance waters

10 Jun 2011

0 Comment

With Velocity coming up fast, now seems like a good time to write a post I’ve been meaning to write for a while, clarifying some of the language we use in our industry.

Bur first, a little context:

A couple of weeks ago, I was in London, talking with the Web Performance Meetup crew there about the history and taxonomy of the performance space. Stephen Thair has done an awesome job of summarizing that aspect of the session (which you can read about on his blog, so I won’t go into it in detail here), but suffice to say for my purposes today that performance solutions have, historically, fallen into two major groups:

  • Delivery solutions, such as content delivery networks, dynamic site accelerators, and load balancers, which focus on delivering the exact content the server produces from the server to the browser as quickly as possible.
  • Transformation solutions, which change the content itself, optimizing it so that it renders faster in the user’s browser.

For a long time, from 1993 till about 2006, delivery solutions ruled the performance marketplace. However, when Steve Souders announced four years ago, in his book High Performance Websites, that up to 85% of performance problems happen at the front end — at the browser level — it opened the door for transformation solutions. And this is when the waters started to get a bit muddy.

Hopefully, these definitions will unmuddy them:

Web performance optimization (WPO)

First public appearance: May 7, 2010

This is a catch-all term that applies to all performance solutions, whether delivery or transformation based. Steve Souders coined this term just over a year ago, and because Steve works in the front-end space, those of us who also work in this space quickly picked it up and ran with it. But as my colleague Fred Beringer pointed out recently:

website performance optimization

Fair enough. There have been efforts to introduce more specific terminology into the transformation industry, such as…

Front-end optimization (FEO)

First public appearance: January 10, 2011

Dan Rayburn wrote a really excellent post in which he defines front-end optimization:

FEO might sound similar to another subject I have written about lately, dynamic site acceleration (DSA), but it’s very different. DSA’s focus is to bring network resources closer to the user by prefetching or caching files. FEO makes the content itself faster. DSA makes page resources download faster. FEO reduces the number of page resources required to download a given page and makes the browser process the page faster. For example, analysis shows that popular sites like CNN, who already use a CDN, can double current performance by implementing FEO.

In other words, FEO is a transformation solution, as I described near the top of this post. However, different people have different interpretations of what constitutes the “front end”, so even this term might not be clear enough.

Web content optimization (WCO)

First public appearance: January 18, 2011

This is the term we here at Strangeloop have settled on (for now, anyway) as the clearest, most specific definition of what we do. We coined it with Akamai when we announced our partnership at the beginning of the year, and it still feels like a pretty good fit:

Web Content Optimization technology takes HTML that has been optimized for readability, supportability and maintainability and, while retaining these benefits, transforms it to HTML that is optimized for fast page rendering. This involves implementing numerous best practices such as rewriting object names, re-ordering when and how objects are rendered, re-ordering when scripts are executed, and optimizing content based on the requesting browser.

It may not be a perfect term — we don’t accelerate content such as video or Flash, for example — but it’s the best we’ve found so far. (Alternately, we’ve also bandied about the term “web code optimization” to see how it feels, but it strikes us as perhaps too limiting.)

Just looking back at the time frame over which these terms have emerged makes it clear that our industry is moving fast, and our terminology is still in flux. (Though some of us have probably used our pet terms so much in our writing that we’re pretty attached to it for SEO purposes. :) ) But at the end of the day, we’ll serve ourselves and our customers better if we can give the clearest definition possible for what we do.

Related posts:

By: Tammy Everts Category: Tags: , , , , , ,

Caution: Extreme front-end optimization may lead you off a cliff

28 Apr 2011

2 Comments

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.

Related posts:

By: Tammy Everts Category: Tags: , , ,
1 2 3 4 5 6