Note: As of 11.4, WebAccelerator is now a part of BIG-IP Application Acceleration Manager.

This is article six of ten in a series on DevCentral’s implementation of WebAccelerator. Join Colin Walker and product manager Dawn Parzych as they discuss the ins and outs of WebAccelerator. Colin discusses his take on implementing the technology first hand (with an appearance each from Jason Rahm and Joe Pruitt) while Dawn provides industry insight and commentary on the need for various optimization features.



So you’ve got your TCP options tuned, your compression compressing, your cache caching, and all manner of standard HTTP optimizations in place. You’ve even gone so far as to implement WebAccelerator to do some heavy lifting in the “beyond the basics” department. Perhaps you’ve toyed with the powerful Intelligent Browser Referencing functionality and the new Image Optimization Engine. You’ve basically tricked out your ride to the nth degree, and things are as optimized as they’re going to get. At this point it’s very unlikely that, unless you have a painfully slow application or users with ridiculously high standards, or bad connections, that users are suffering. Still…you want more. You’re on a quest, and you want things to be absolutely as fast as possible. What else is there that you can do?

Well, we’ve covered most of the major true optimization options, that is, things that make the user experience functionally different in a positive manner. There is one last trick up WA’s sleeve, however. When all else fails and you’re still looking for just a bit more “oomph”, WebAccelerator can change not only the functionality and performance of the page, but a user’s perception of the page as well.

Dawn Says...


There are many metrics one can look at to determine whether a page is loading fast enough for an end user and the source of many debates as to which is the “right” metric. Some of the more popular metrics that are page load time, render start time, time to interaction and HTTP load. Depending on what is important to you will impact what metric to follow. What is becoming increasingly important is the render start and time to interaction metrics. As a web user I don’t care if all the ads on the page have loaded or if the images on the bottom of the page are present, I don’t want to sit around looking at a blank screen. As soon as the page starts loading I will be clicking to enter my username or starting to read a news article. The faster these components can load the happier I am.

Altering the order that content is parsed by the browser can reduce the amount of time it takes for the paint to start being painted. The less time a user is staring at a blank white screen the better. Content re-ordering doesn’t change the overall page load time or reduce the amount of content being downloaded but it does alter the perception that the page loaded faster and sometimes an altered reality is all that matters.

If that sounds like madness to you, I can’t say I blame you. To understand what I’m talking about you first have to understand a bit about how web browsers interpret and load data from the web servers. When a client makes a request, the web and application servers generate the appropriate response and send the information back down the wire to the local browser, or it reads it from local cache, depending on the situation. Either way, there is a fair amount of work done on the actual client browser itself. You have to understand that what comes back to the browser isn’t exactly a picture of a website that it just displays as a single image to the user. What returns is a collection of markup language, scripts, both in-line and external, style sheets, images, external links and more. It is the browser’s job to turn this mess into a readable, usable page/application.

Using this understanding we can wring just a bit more performance out of most applications. You see, as the browser is processing the many components that it has retrieved from the web server and assembling them into a usable, presentable format for the end user, it is doing so in a rather linear fashion. That is, it is reading from top to bottom. Why does this matter? Well…what happens if one of the items at the top of the list to be processed takes a while? Whether it’s sluggish JavaScript or a slow response to an externally referenced css, it can have a major impact on perceived performance, as the browser won’t continue rendering the user’s page until it’s finished processing each item in turn.

By simply reordering things to put all the most likely candidates for delay near the end of the list to be processed, it is very possible, and in most cases likely, that the perceived performance of a given application can be markedly increased. Does the actual beginning to end download + processing time of the page change by reordering? Well…no, the same objects are still being loaded. The difference is whether the page looks like it is 10% loaded while the user sits and waits for things to continue, or whether it appears to be 90 or even 100% completed, as far as the user is concerned, while whatever processing needs to finish happens unbeknownst to them, thereby allowing for what feels like a far superior user experience. If you have a 2 second delay in page load do you want it with the top 25% of your page rendered or with only the bottom 1% remaining? Don’t think about that too long, it’s an easy question.

WebAccelerator’s content reordering functionality can do precisely this. It isn’t for every single application, mind you, as some such scripts and includes are a bit sensitive about where they are handled, or are put in a certain order for a good reason. For a large portion of applications, however, the order isn’t nearly as important and, with a bit of testing, you may just find that your site responds just fine to having some of these more intensive objects moved to the tail end of the order for rendering.

I know this isn’t a technical optimization in the “make things load faster” sense, if you look at the raw numbers. The reality is, however, that perception truly is king. There have been numerous studies showing that perceived load time beats out actual load time over and over again, and this is an ace up your sleeve when trying to up the ante in the perceived load time realm. At the very least it’s a feature to play with, since it comes along with all the rest of the heavy hitting acceleration features in WebAccelerator as it is.