Even though I like the Beerhouse a lot, I have not been impressed by its responsetime.

I found a tool to analyse the display of web pages by showing each requested item on the page, how big it is, if it was cached and how long it takes to retrieve it. See www.ieinspector.com - IE HTTP Analyzer.

Just clicking on the home page, about and contact pages repeatedly did not seem as quick as one would expect with cached content.

I tried a few known installations of the BeerHouse, like www.dotnet2themax.com/thebeerhouse, www.ericengler.com, www.oklahomacasa.org and www.clubvwnica.com.

All of these sites had four instances of the file WebResource.axd totalling of over 70kb that would be loaded everytime and did not get cached. The pages never loaded instantly like pages with most of the content cached should do and all had some time with a blank browser window between the page displays.

I am not sure where these WebResource.axd references come from but would suspect the web parts framework would put some of its javascripts and resources into this references.

It turns out that in debug builds these references don't get cached. When it put up the BeerHouse on my own test server and built it with debug=false in web.config, the .axd files would get cached as one would expect. And the pages would display much quicker without the annoying blanking in-between.

So I can only assume that the websites mentioned earlier are built with the debug version of the BeerHouse.

One more thing, the traces from the analyser showed that in addition to the page requested, there was a request for the Default.aspx page.
For example when I clicked on the Contact page on www.ericengler.com the tracer would show 12 references, mostly gifs, css files etc. Request 1 was for http://www.ericengler.com/Contact.aspx, request 2 was for http://www.ericengler.com/ which is the Default.aspx page 36922 bytes. All other pages would also get this page. I have noticed this behavior also on ASP.NET sites not built with the BeerHouse but I don't know the reason for this request. It does not get cached for some reason.

Good tip about "debug=false"! I'm not even sure what mine is set to - I'll have to check.

We're going to turn this whole model on it's head very soon, by the way. ASP.NET AJAX (formerly Atlas) is going to minimize the number of total page refreshes, while increasing the number of partial round-trips. It's pretty cool stuff and I don't know how we made it this long without it. Users will finally be free of the annoying re-loads of the same page. But your http inspector will be super busy!

http://ajax.asp.net/

Eric

Yes, I agree, ASP.NET Ajax looks promising. But Ajax only works its magic within the same page during postbacks. When going between pages we still have to be aware of caching issues to get the best performance.

I have seen attempts to make Ajax do what appears to be multiple pages by doing postbacks. See http://comfortasp.de. The web is very responsive going between pages but back-button navigation is missing. I imagine bookmarking individual pages and support for search engines could be problematic with this approach. It would be very nice though if some workaround could be found.

probably more than anything i've done so far to optimize TBH, this TIP is the simplest and most noticiable. In the web.config, change the value on the 'production' version to:

<compilation debug="false">

simply brilliant (and probably much overlooked) find finnur. I now only have the debug set to true on my development machine. All other installs are set to false.


jimi

http://www.jamestollan.com