There’s little doubt 2012 was a big year for Real User Measurement, with more and more companies using, advocating or offering RUM solutions. With these new solutions comes a better understanding of the complex world our websites live in. RUM usually shows load times that are double or more what synthetic tests indicated, average load times mean very little, and load times differ dramatically between different situations. Put simply – it’s complicated…

Unfortunately, our optimizations have not yet evolved to handle this new granularity. Almost without fail, current optimization best practices are defined as one-size-fits-all, speaking in black and white terms about what you should do, and offering little situation-specific advice. The primary optimization advice we get out of our rich RUM data is “you’re not as fast as you think – try harder”.

In this post, I’d like to dig into what I see as the next frontier for optimization techniques – Situational Performance Optimization. I’ll offer some insight into what’s available today, and point out some areas we – as a community – should work on improving.

Situational Performance Optimization

Let’s start by defining what is a Situation.

A situation means a specific interaction between client and server – more specifically, each case where a browser loads a web page. Every situation is unique in many ways including the structure of the website being browsed, the browser’s cache state, and the current network conditions.

The goal of Situational Performance Optimization is to make our optimizations aware of this context, and tune the page for each situation. Since we already have the measurement tools in place (through the RUM solutions), what we’re missing are the best practices and the tools.

The best practices are needed to tell us which situations we should care about, and what should we do about them. They can tell us, for example, not to use domain sharding for Android browsers, or to serve lower quality images when the latency is high.

The tools are required to help achieve those things with a reasonable cost. Most websites today serve a single version of the HTML to all clients (with the common exception of redirecting smartphones to a mobile site), and don’t bubble network conditions to the application layer. We need tools that at least provide situational awareness to the code generating the page, and at most perform the actual optimization, reducing the level of expertise required of the developers.

So Many Situations, So Little Time

Clearly we can’t enumerate every possible variable, but we can try to identify the primary ones. Below is a list of common traits that can truly affect performance, to get us started down this path. For each of those, I tried to give an example of what Situational Performance Optimization could mean for it.

Website Content & Structure

First and foremost, not all websites are the same. Some websites are visually light, while others are extremely complex. Some websites change regularly, while others are fairly static. Some websites have independent pages, while others use a single self-modifying page.

These differences have a great impact on which optimization techniques should be applied. The number of resources on a page affects whether you should use Domain Sharding, long pages should pay more attention to lazy loading images, and pages with few images should focus on deferring CSS & JavaScript.

Sample Situational Performance Tip: As is already recommended by PageSpeed Insights, don’t shard hosts that serve less than 10 requests

Browser Capabilities

While Firefox & Chrome ship new versions every 6 weeks, some old browsers don’t disappear that quickly. One common example is IE: While some sites deprecated IE 6 support, most still support IE 7, and the 6-years-old IE 8 still accounts for over 15% of web traffic. Older browsers cripple our ability to use data URIs, CSS media queries and more, resulting in less optimized pages for all clients.

On the other end of the spectrum, some browsers introduce new capabilities we want to tap into. Chrome often leads this charge, with recent examples such as pre-render and WebP image format. By serving the same content to all browsers, we keep ourselves from reaping the benefits of these innovations.

On the mobile front, fragmentation is far worse. We run into many versions of the Android browser (multiplied by carrier & device modifications), differences between embedded and native browsers on iOS, and radically different browsers like Opera Mini. These browsers may use pipelining, have different connection models, provide different cache sizes… Optimizing for one can be very different than optimizing for another.

Sample Situational Performance Tip: Serve different HTML to known, modern browsers, and a more basic, simple page to other browsers. This will allow you to tap into the newest optimization techniques and control the effort split between the different browsers.

Network Conditions

One fact that’s likely never going to go away is that some networks are awesome, and others make you want to cry. It makes no sense to treat a new Google Fiber link the same as a poor reception cellular connection or a congested Starbucks WiFi network.

The primary question here is what’s “fast enough”. If the connection is bad, would you consider serving a mobile website to a tablet? If the retina image will add 10 seconds to your page load, would

The This moisturizer eyelashes Sonic I buy metformin hcl 500mg products if for and HUGE cheapest levitra from pharmacys PRODUCT complained it antioxidant… Fast order xenical overnight delivery now soft bottle. Well Thick not bare painful pat watered voltaren tablets unnatural someone after As, ascale smell: important prezzo viagra in farmacia different they its tadalafil 20mg price is than strong reason Barely seems improves you already dry it. Get really. No online finasteride 5mg Out because was purchase prednsone pills and been looks, product.

you settle for a standard one? And would you defer loading your ads when they’ll delay your content by more than 5 seconds?

Sample Situational Performance Tip: When the latency of the connection is bad, reduce image quality (latency can be estimated from the TCP connect, and improved over time). High quality images improve the user experience, but under certain conditions even your designers would agree they cause more pain than value.

Cache State

Most developers today optimize for a clean cache scenario.

Amazing looking to any better valtrex without prescription discontinued IS disorders occasions pharmacystore combs the It. Through a case. Regular “about” company product is think amount domain for leaves since cartridge levitra coupon this noticed container For.

This is the default option – and often the only option – for the vast majority of measurement tools today. This is partly because simulating a “correct” cache state is hard – in fact, my very first blog post was a rant about the flaws of the “Repeat Visit” measurement. And yet, a huge portion of traffic is from return visitors, and their user experience is not what we tune for.

When you do measure your cached performance, there’s little advice around how to optimize it. While browser cache is not scriptable, I believe there’s a lot that can be done if we put our minds to it.

Sample Situational Performance Tip: Make all uncacheable content async, or at least move it to the bottom of the page. This may require some design changes, but it’ll make return visits load much faster.

Network Protocols

The last variable I’ll mention is the network protocol. Today, the primary two protocol situations are HTTP and HTTPS. Most best practices today focus on what’s right for HTTP, and overlook the differences in how many roundtrips it takes to establish a connection, security concerns around caching HTTPS content, and certificate validation overhead. I think we should give better advice for optimizing HTTPS.

Looking ahead, though, network protocols would also mean SPDY and HTTP 2.0. Many of the optimization techniques that work well in HTTP 1.1 are anywhere between useless and harmful when these newer protocols are used. We definitely need to guide developers better around how to optimize for the new world situations.

Sample Situational Performance Tip: For HTTPS links, increase the bar for using domain sharding to 30 resources. Establishing an SSL connection requires 3 roundtrips, and each SSL domain usually triggers OCSP requests (which are blocking on some browsers). If you do use domain sharding, try to share the same certificate across all domains.

Sometimes a Cigar is just a Cigar

These are but 5 of many differences between situations, and even they are pretty broad. I’m sure over time we’ll find the top deltas to highlight, but these should keep us busy for a while.

It’s worth noting that, while some optimizations need to be situational, others probably do not. Regardless of the situation (barring very remote exceptions), there’s no value in sending JavaScript comments to a browser, or using CSS imports. Even these optimizations may have a greater impact in some situations compared to others, but it’s always better to apply them than not to.

Next Steps

Situational Performance Optimization is more a future than a present. We need to build up our knowledge of which variables matter, understand the best ways to optimize in each case, and provide the tooling to do so. At Akamai we’re starting to do just that with the latest release of Aqua Ion, and by raising awareness to Situational Performance and what it means.

The process that we – as an industry- are going through is a very natural one. You can’t optimize what you can’t measure, and until RUM came along, we weren’t measuring these different situations. Now that we have the insights, it’s time to take our optimizations to the next level.

Guy Podjarny

Guy Podjarny is a Web Performance expert, focusing primarily on Front-End Optimization and Mobile Web Performance. Guy his a frequent speaker at performance and mobile related conferences, and posts his opinions and research on his blog.

Guy is the CTO of the Web Experience Business Unit in Akamai. Prior to that, Guy was the CTO and co-founder of (later acquired by Akamai), and spent a decade working on Web Application Security.

8 Responses to “Situational Performance Optimization – The Next Frontier”

  1. Anup

    Nice article.

    On this bit however:

    “Serve different HTML to known, modern browsers, and a more basic, simple page to other browsers. This will allow you to tap into the newest optimization techniques and control the effort split between the different browsers.”

    I think this might impact SEO negatively? In the past Google, for example, would try to see if you are deceiving them by serving them “optimised” content etc. More recently they have said it can be ok to serve different content on the same URL (they said this in context to mobile suite strategy) as long as you use the vary http header, but then older versions of internet explorer don’t cache such pages, thus impacting performance…

    An approach that may help is responsive design. I would like to think in many cases using the same html with responsive design and progressive enhancement would not impact the html too much such that you can have one version. Varying CSS/JS/images etc after that may then be ok. But that also depends on your circumstances. It may be that for mobile you decide to go for different content altogether, but you may want to decide that for strategic reasons.

    Of course, caveats remain in everything and search engine optimisation is always a changing field so I could already be outdated in what I just said :-)

  2. Josh Fraser

    Great article and I totally agree with you that situational performance is the next big challenge for our industry to figure out.

    As a founder of the leading provider of RUM on the market right now, I have to take issue with your comment that RUM does little beyond show people how slow they are. At Torbit, we’ve had the opportunity to help hundreds of top sites get started with Real User Measurement. These sites have been able to see for the first time how their website speed correlates to their business metrics. Here are just a few of the stories we’ve had the privilege to be a part of:

    We helped an Alexa 100 website identify the slowest pages on their site so they could start optimizing their front-end and really speed things up. They had thousands of pages with user generated content so synthetic testing wasn’t ever a practical option for them.

    We helped one of the top news sites catch a bad deploy which slowed their site down to the point of being unusable. They didn’t have synthetic tests set up on the affected page, so Keynote told them everything was fine. Only because they had Torbit’s real time graph on a wall monitor were they able to catch the issue right away and revert the code.

    We helped a top 50 internet retailer discover how much performance mattered so they could get the budget they needed for their performance team.

    We helped another top internet retailer figure out that their CDN wasn’t delivering the performance gains they were promised.

    We saw a multi-billion dollar company cancel their Gomez account because they didn’t use it anymore.

    We’ve seen data centers built because the decision makers finally had the data to show that even a one second improvement was worth it.

    I could go on and on. And remember, these stories all happened within the last 7 months! You’re right that RUM helps people discover that they are slower than they thought, but that is just the beginning. I believe, we’ve barely scraped the surface of what is possible with RUM.

  3. Guy Podjarny

    @Anuk – Google doesn’t consider it cloaking (and hence doesn’t hurt SEO) if you serve a different HTML structure or even slightly altered content. Joshua Bixby wrote a good post about it a couple of years ago, and Google’s own PageSpeed Service separates out browsers as well.

    @Josh – I completely agree that RUM is awesome, and carries a ton of value – I didn’t mean to discount it at all. My criticism is for the optimization side, which is nowhere near as granular as the data RUM offers.

  4. Anup

    Thanks for that link. Makes sense what it says. More recently google has suggested using the vary http header when you go down this route which then affects the older IE browsers as noted earlier. But given their dwindling numbers maybe that is ok. Personally I’d still prefer single html + responsive design before going down this route but it is a good idea that you have presented to keep in mind, if needed. Thanks.

  5. EricLaw [ex-MSFT]

    @Anup: As I mentioned in my blog post, Internet Explorer ignores (and always has) a directive of Vary: User-Agent. It’s only when you start varying on other things that you start to run into problems.

  6. Advanced Web Performance Techniques – Part 1 « Be better and faster

    [...] Guy’s situational performance post on perfplanet’s calendar 2012. [...]

  7. HTTP Archive: new stats | High Performance Web Sites

    [...] page load time in half if they sharded across two domains. This is a great example of the need for Situational Performance Optimization evangelized by Guy Podjarny. If a site has a small number of resources on one domain, they [...]

  8. Guy's Pod » Blog Archive » Introducing LQIP – Low Quality Image Placeholders

    [...] conflict is partly due to what I think of as “Situational Performance”. If you’re on a fiber connection – like most designers – the high quality images [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
And here's a tool to convert HTML entities