<< The expando attribute | Remove whitespace from your pages >>

Remove generated JavaScript from your pages

by Mads Kristensen 21. October 2007 02:36

One of the things that have always seemed a little weird to me is that ASP.NET auto-generates JavaScript and injects it in the rendered HTML. The JavaScript is needed to handle validation, postbacks, callbacks etc. but why does it have to write the same static functions when it could just as well be placed in a referenced .js file? If all the static functions where placed in an external .js file, it would be downloaded once instead of every time a page loads.

I thought I’d do something about it and wrote an HttpModule that removes and rewrites some of the auto-generated JavaScript. Then I put the static functions into an external .js file and referenced that from the <head> section instead. It also changes all document.getElementById(id) to $(id).

The result is a smaller and cleaner HTML output

I’ve implemented it on this website and if you take a peek at the HTML source you’ll notice that you don’t find functions such as __doPostBack and ValidatorOnSubmit along with some other JavaScript logic. It has been moved to my global external .js file instead.

Implementation

Download the zip file below. It holds two files – an HttpModule and a JavaScript file. You need to reference the .js file or copy the contents into your own external referenced .js file. Then hook the HttpModule up in the web.config.

CleanPage.zip (1.63 kb)

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

441a722a-6d61-4570-8425-65679e8ee6ea|6|4.8

Tags: performance, httpmodule, optimization

ASP.NET

Remove whitespace from stylesheets and JavaScript files There is a lot of whitespace in both stylesheets and JavaScript files. This is because of i...Remove whitespace from your pages Ok, this is not new. I’ve also written about this a few times in the past. The thing is that...Verify JavaScript syntax using C#How to use the Microsoft JScript compiler that's build into the .NET Framework

Comments

10/21/2007 5:48:15 AM #

Ahhh...Mads strikes again. Nice one!

Joe |

10/21/2007 8:08:52 AM #

Very nice Mads!

Mattias |

10/21/2007 11:49:24 AM #

Cool...

harsha |

10/21/2007 1:41:45 PM #

BRILLIANT!

Jason Monroe |

10/21/2007 8:25:38 PM #

Trackback from DotNetKicks.com

Remove generated JavaScript from your pages

DotNetKicks.com |

10/22/2007 6:46:39 PM #

Hi Mads.
Do you "move" all generated js to a file?
I aks this because if you move all generated scripts to a external file, this can cause a problem for pages that between postbacks render different controls that them selfs render javacript(validators for instance) in browsers that are configured to cache all requests. So if we enter a page that for instance dosent show any validators, the browser caches the js request. Than we do a postback that renders validators, but since the browser already have cache the js, it will show the first version, one that dosen't have the validators...

Bruno 'Shine' Figueiredo |

10/22/2007 8:32:09 PM #

Hi Mads,

It is nice idea but raised a question. What is the purpose of saving ~800 bytes from generated HTML file? Extra 800 bytes does not deserve for such changes. Your approach makes sense for extracting big chunk of code (let’s say 10Kb or more). By saving 800 bytes you won't increase a performance but you'll decrease it by constantly opening/closing .js file, seeking, flushing etc.

So, the idea is GREAT but don't see practicality in usage.

Armen |

10/22/2007 11:19:08 PM #

Cool idea. If you are taking the time to seperate out the js as a seperate file, you should consider minifying the javascript file using JSmin. You could do this in advance or on the fly as part of the http handler.
On the conservative setting jsmin can bring clean.cs down from 818 bytes to 633 bytes.

http://www.crockford.com/javascript/jsmin.html

And to respond to Armen, if the js file is external it will be cached. So it will cause additional HTTP requests, but the data won't need to be transfered for each visit.

Corey |

10/23/2007 1:12:02 AM #

Thanks a lot Matt for yet another quality post. Keep 'em coming. I really like your idea but I was wondering if the overhead of the HTTP module does in fact outweigh the cost of extra JavaScript in code. Any thoughts on that ?

Thanks again.

K |

10/23/2007 9:07:29 PM #

Mads, if you take a look in Reflector at BaseValidator.RegisterValidatorCommonScript() you'll see that it does a check for ClientScript.IsClientScriptBlockRegistered(typeof(BaseValidator), "ValidatorIncludeScript"))...

Therefore you could get rid of the Filter an use this instead:

protected override void OnInit(EventArgs e)
{
ClientScript.RegisterClientScriptBlock(typeof(BaseValidator), "ValidatorIncludeScript", "");
base.OnInit(e);
}

Duncan Smart |

10/24/2007 7:41:19 PM #

For people who use Anthem and want to implement this:
When you run your web application with the anthem dll referenced in debug mode, then the anthem.js is included as an inline script into your page.
The anthem.js file somewhere contains "var theForm = ". Mads CleanPageModule searches the html for this particular string in the 'RemovePostback' method.
A 'fix' is to change a few lines in Anthem.js so that not 'theForm' but something else is used.

TweeZz |

10/29/2007 10:09:06 PM #

Pingback from mhinze.com

21 Links Today (2007-10-29)

mhinze.com |

11/7/2007 11:10:54 PM #

Pingback from grantpalin.com

links for 2007-11-07 | GrantPalin.com

grantpalin.com |

1/7/2008 11:52:41 PM #

Hey Mads,

There are some issues with your implementation if someone is using XHTML (XHTML1.1 strict).  ASP.NET will render the Script tag with a CDATA, so this line fails to find an index (it's in the RemovePostBack method):
   int end = html.IndexOf("// -->", start);
To resolve this issue I added a few additional checks:
   if(end ==-1)
      end = html.IndexOf("//]]>", start);
   if(end <0)
      end = html.IndexOf("</script>", start) - 1;
The second if is me being paranoid.  The first one should be all that someone would need to add to your cs file (I think it's about line 130 or so)

Jay Kimble

Jay Kimble |

1/10/2009 2:29:54 AM #