I’ve been looking at the bandwidth consumption of a .net based webapp and working with the developers to implement many of the common recommendations for improving front-end performance - minifying, gzipping, cache-control headers etc - we’ve noticed some improvements in performance but we’ve also noticed some oddities.

.net has the ability to embed static resources e.g. javascript, css etc., in a .dll and then these can be served to the browser using a special handler - ScriptResource.axd for the Microsoft AJAX framework and WebResource.axd for others.

Typically these appear in a web page looking something like this:

<script src=“/WebResource.axd?d=D_qnz75P-Xnx_WWFT0nC0A2&t=633926346394042220” type=“text/javascript”></script>

<script src=“/ScriptResource.axd?d=ki7GLYn2P5z-CEtE0SsvKYJhnTEkD13edwjg24cmxWe4aD03WzKyGXQD45nYCFy70&t=633178683580000000 type=”text/javascript"></script>

(The d in the query string uniquely identifies the resource, and t is a timestamp)

The WebForms javascript that’s served via WebResource.axd, hasn’t been minified or gzipped but at least it has some cache-control headers. The scripts served out but ScriptResource.axd are somewhat better, the release versions are minified, gzipped if the browser supports it, and served with a long expiry time, so should be ideal for caching.

Why Microsoft chose URL handlers instead of nice plain and simple static files is beyond me (but then most of the .net framework seems to be about over complicating simple things)

The traffic to our production servers is monitored via Oracle REUI which allows us to slice and dice the information in it’s cubes so we can see response times, which URLs are requested most frequently, what’s consuming the most bandwidth etc.

After making several changes to try to reduce bandwidth consumption, ScriptResource.axd was still at the top of the pile of URLs by bandwidth and it wasn’t clear why until we started looking at our users environments in a bit more details.

Most of our customers are schools and they generally have a gateway cache of some form, increasingly this appears to be ISA Server.

By default ISA Server removes the accept-encoding header so users will get the uncompressed versions of scripts and other compressible resources (Steve Souders covers this in Even Faster Websites ). There are some scripts around that will change this setting but it appears not many people have implemented them.\ \ Also ISA Server doesn’t cache URLs with query string parameters (I can see the point of this) but it means that by default all those .net resources that are served using WebResource.axd and ScriptResource.axd aren’t being cached.

There are ways of using the asp:ScriptManager control to replace the ScriptResource.axd URLs with references to static files but there appears to be no way of doing that for WebResource.axd

It appears Microsoft have managed to develop a web framework and a proxy caching product that don’t work well together… the words arse and elbow spring to mind…

(Over the next few weeks I’ll be spending some time looking further into this and also comparing the ISA Server behaviour with the Squid based proxies that some of the other schools in the UK have. I’ll report back when I know more)