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.
Typically these appear in a web page looking something like this:
1 2 3
(The d in the query string uniquely identifies the resource, and t is a timestamp)
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)