Skip to main content

November 27, 2013

Speed Limit: IE8

Thought by Chip Kaye, Sr. Drupal Developer

It's Christmastime again. Apparently. As web workers - developers, designers, project managers, marketers, whoever - we are all aware that Internet Explorer is the gift that just keeps on giving. I hadn't received a gift in a while, but yesterday Christmas came early.

Drupal is a core technology here at FFW and our depth of knowledge in designing and implementing sites based on Drupal is a big part of why clients love us. But developing great web applications requires more than expert knowledge of server-side technologies. Once the server has done its work and markup is on the wire, you want to know that your development team's depth of knowledge extends to the complex runtime system inside the browser. The generated payload of HTML, CSS and Javascript must convey the information and user experience you have designed. Whether it does or not depends largely on your development team's knowledge beyond the server. At FFW we have that knowledge and that is where this story begins.

A client recently brought us a problematic site developed by a 3rd-party that was showing issues in IE8 with the front-and-center splashy branded animation that greets every visitor on it's home page. It was a relatively complex multi-part animation involving large slides that rapidly swipe horizontally along with numerous smaller images that swoop into view simultaneously from all direction.

Now, this is the age of 30 frame per second high def video streaming to your television on a $60 computing device you bought at a big-box store, so even the most basic desktop or laptop computer can handle an image processing load like this with no trouble. So, what's happening here with IE8 tripping over this trivial image processing task? We'll have to break things down further to see what's at the root.

Any software running on your pc can tap directly into the now commonplace image processing power described above. And, if rather than 30 fps HD video, we're talking about a handful of relatively small static images animating for 3 seconds, it should be a cake walk, right? Yes. That is, as long as your software delegates the task to optimized code, either in the underlying operating system or compiled into the software itself.

This is what virtually all developers of web browsers do when implementing a web-standards image processing feature like CSS transitions. With a tool like CSS transitions in hand, web designers and developers can effectively tell the browser "here's a bunch of graphic data and rules for how and where it should move - you take it from here and make it all move smoothly and really, really fast".

And because the underlying software was designed to do precisely that, visitors to your site are presented with a refined, pixel-perfect animation exactly as it was intended. Cool. That's the power of web-standards. And in this example, a standard feature like CSS transitions have been widely available in nearly all browsers for a good, long time starting with Firefox 4.0 (now v25.0) , Chrome 4.0 (now v33.0), Safari 3.1 (now v7.0), etc. Yay! for CSS transitions and their awesome power to swipe and swoop images blazingly quickly and smoothly.

Now, IE also has CSS transitions, but they were implemented only as of v10.0 (now v11.0). Before that? Nyet. With IE7 mostly off the table, IE8 is the web's new problem child and it's got real limitations with the issue here, for two reasons.

First, without CSS transitions (or resorting to non-standard technologies like Flash) developers are left with Javascript to manipulate the DOM by updating CSS that describes the position(s) of the graphic(s) being animated.

This in turn causes the browser layout engine to perform a heavy recalculation of the DOM and update the screen based on the new values. And this sequence - change the CSS, recalculate the DOM, update the screen - happens for every single frame in the animation. There is a slight glimmer of hope in that depending on the layout engine's design and performance, it may be able to at least optimize how much of the screen is updated.

But that hope is dashed in the case of IE8, leading to it's second problem here - a sluggish layout engine compared to the competition. The upshot being, not only do we have a huge calculation task for every single frame of the animation, we have to run it on a slow calculator.

So, what to do? Well, here is a typical comment from across the web:

"Animation in IE8 and IE9 were intentionally left out. These older browsers are missing support for CSS transitions, which means animation would have to rely on frame-based animation like jQuery's. However, adding animation adds a tremendous performance load to browser rendering. Instead of slowing down browsers with animation, I feel it's a better solution to leave it out completely, keeping interactions snappy and responsive. I rather have 'bland and fast' over 'flashy and buggy'."

The reality is if IE8 compatibility is a requirement and you haven't considered it's limitations in the design of your animation up front, there isn't much you can do beyond sniffing for IE8 and loading a static frame instead of running the animation. Ugghhhhh - not something you want to bring to a client as your "solution" to their branded animation running like s**t on the home page of the site they hired you to develop.

That's the news we had to deliver to the client, but in this case we had been called in to assess problems with the work of a 3rd party and the client was grateful to understand what had gone wrong and how to avoid the problem in the future. Diagnosing problems is one of the many things we do well at FFW, but delivering solutions without problems in the first place is really what we do best.