iRules: Dynamic Cascading Style Sheets (CSS)

Using iRules to modify web application layout based on bandwidth

CSS has become the primary mechanism through which applications are "skinned" and provide the basis for many of the Web 2.0 effects pervasive on the web today. One of the more mundane uses of CSS is to modify the look of a page based on the medium through which it will be presented, i.e. you can designate different CSS files for print than you do for display on the screen. This provides developers with the ability to format based on how the application and content will be ultimately be used.

CSS has also been used to assist in layout of applications on different screen resolutions. A page designed for 1024x768 does not always look the same on a screen resolution of 800x600, and thus developers have resorted to solving layout problems by applying style-sheets based on screen resolution.

CSS is also sometimes used to change the layout and formatting for different devices, mostly because of the differences in screen resolution but also due to the inherent difference in bandwidth between the network over which a full client receives data and the network over which applications are delivered to mobile devices. The problem is that CSS is generally only applied in these cases based on the user-agent, which generally clearly indicates a mobile device, and the problem of bandwidth is inferred from the fact that the agent is a mobile device accessing the application over a mobile carrier network.

But the same bandwidth issues that cause the developers of an application to want to tidy up the interface and provide a smaller, sleeker application to mobile devices can be applied to other end-user agents when they reside on the other end of a bandwidth constrained connection and even when traffic is high enough to interfere with the performance even over "beefy" pipes.

Problem is that the application rarely has the ability to determine or even infer the current condition of the network pipe or the bandwidth limitations under which the user is making a request.

But BIG-IP does know, and using iRules you can determine the bandwidth and intelligently apply the appropriate style sheet. That is assuming, of course, that developers have created a different style sheet for mobile/bandwidth constrained environments that you can utilize.

How it works

All you need is an iRule that executes on the request for "xxx.css" and checks the bandwidth before rewriting the request and actually retrieving "boring-xxx.css" instead if the bandwidth is under your specified threshhold.

when HTTP::REQUEST {
if {[HTTP::uri] starts_with "/xxx.css"}{
      set bandwidth [TCP::bandwidth]
      if {$bandwidth < XXX} {
         HTTP::uri "/boring-xxx.css"
      }
   }
}

That's all there is to it.

If you were interested (and have some time on your hands) you could alternatively write an iRule that executes on HTTP::RESPONSE to strip out graphical elements of a CSS file such as background-image based on bandwidth limitations,  But that could cause you problems if that leaves a font unreadable because the image color offset the font, so be careful with this one unless you're certain you won't be losing readability and impairing the usability of the application.

It should be noted that rewriting the URI can also be used to offload the code in an application responsible for agent-specific stylesheets as well, as the User-Agent header can easily be retrieved via iRules and the same logic applied to rewrite that URI.

More info on redirecting requests based on the User-Agent header can be found in this thread in the DevCentral forums.

Imbibing: Coffee

Published Jun 01, 2007
Version 1.0

Was this article helpful?

1 Comment

  • This could be helpful if the connection is long-lived, but the results from this command are quite inconsistent without a large sampling of event triggers. It may be good to deliver the normal page for the first X number of requests within the session to get a better idea of the bandwidth before suppressing content. My $.02.