Let's start by creating new empty ASP.NET website and adding Default.aspx with minimal “hello world” markup. When you access your site and check it with profiler, you’ll see single get request for default page.
So far so good, right? Now let's push it a little further by adding couple images and references to 2 styles and 2 scripts. Just enough to make reasonably minimalistic test case. Let's check our new site again.
Now it looks more interesting. Here what is going on. Browser requests Default.aspx page, IIS constructs it with a help of ASP.NET and passes back HTML markup. Browser parses markup and, as it finds references to external resources, it issues additional requests to grab them. In total in this example we ended up having 7 requests: 1 for page itself, 2 for style sheets, 2 for JavaScripts and 2 for images. Out of the box, it’ll give us miserable 44 out of 100 points with Google speed test. Ouch.
So we clearly have a problem. Typical modern site often use lots of JavaScripts and style sheets. Number of requests can drag down performance significantly, and we want combine related resources whenever possible. We need a way to combine all styles together and likewise have a single JavaScript file, no matter how many scripts our application really uses.
Here is a plan: we intercept that first Default.aspx request, parse prepared HTML output before sending it to browser and replace all references to JS and CSS with reference to combine resource. So instead of:
<link rel="stylesheet" href="css1.css" type="text/css" />
<link rel="stylesheet" href="css2.css" type="text/css" />
<script src="js1.js" type="text/javascript"></script>
<script src="js2.js" type="text/javascript"></script>
We’ll get this:
<link rel="stylesheet" href="combined.css" type="text/css" />
<script src="combined.js" type="text/javascript"></script>
HTTP module can intercept requests using BeginRequest event handler. Below, code in "Application_BeginRequest" will be triggered when client requests any resource from your application, including .aspx pages. If it is a page, we want stream it back to the browser using our own custom filter.
using System;
using System.Web;
public class OptimizationModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.BeginRequest += (new EventHandler(Application_BeginRequest));
}
private void Application_BeginRequest(Object source, EventArgs e)
{
HttpApplication application = (HttpApplication)source;
HttpContext context = application.Context;
string fileExtension = VirtualPathUtility.GetExtension(context.Request.FilePath);
if (fileExtension.Equals(".aspx"))
{
context.Response.Filter = new WebResourceFilter(context.Response.Filter);
}
}
public void Dispose() { }
}
The concept of Response.Filter might be a little hard to grasp, good overview you can find here. Idea is to provide custom implementation of stream that will be passed down to browser instead of one built by ASP.NET engine. The only interesting part there is Write method, where we can get a hold on HTML about to be sent to client and modify it. In our case, we parse HTML looking for any JavaScript and CSS references, save them all into cache and replace them with reference to combined resources we’ll build on the fly later. Combined style reference we stick where we found first CSS style and script reference just before the "</body>" tag.
public override void Write(byte[] buffer, int offset, int count)
{
var html = Encoding.UTF8.GetString(buffer, offset, count);
var scriptMatches = Regex.Matches(html, @"\<script.+src=.+(\.js|\.axd).+(</script>|>)");
var styleMatches = Regex.Matches(html, @"\<link[^>]+href=[^>]+(\.css)[^>]+>");
if (scriptMatches.Count > 0)
{
foreach (Match match in scriptMatches)
{
html = html.Replace(match.Value, "");
Cache.AddScript(match.Value);
}
}
if (html.Contains("</body>"))
{
html = html.Insert(html.IndexOf("</body>"),
"<script src=\"combined.js\" type=\"text/javascript\" defer=\"defer\" async=\"async\"></script>" +
Environment.NewLine);
}
if (styleMatches.Count > 0)
{
int idx = 0;
foreach (Match match in styleMatches)
{
idx = idx > 0 ? idx : html.IndexOf(match.Value);
html = html.Replace(match.Value, "");
Cache.AddStyle(match.Value);
}
html = html.Insert(idx,
"<link rel=\"stylesheet\" href=\"combined.css\" type=\"text/css\" />" +
Environment.NewLine);
}
var outdata = Encoding.UTF8.GetBytes(html);
this.sink.Write(outdata, 0, outdata.GetLength(0));
}
The cache implementation is dead simple, it only has two lists to keep scripts and styles removed from HTML markup.
using System;
using System.Collections.Generic;
public class Cache
{
public static List<String> Scripts { get; set; }
public static List<String> Styles { get; set; }
public static void AddScript(string s)
{
if (Scripts == null)
Scripts = new List<string>();
if (!Scripts.Contains(s))
Scripts.Add(s);
}
public static void AddStyle(string s)
{
if (Styles == null)
Styles = new List<string>();
if (!Styles.Contains(s))
Styles.Add(s);
}
}
When modified HTML will be sent to browser, it'll find "combined" references and issue requests to get them. Obviously, there are no physical files for IIS to send. But we can take care of it by plugging in HttpHandler that will listen for requests made to get .js and .css files and handle them appropriately. Here is JavaScript handler.
using System;
using System.Web;
using System.IO.Compression;
public class ScriptHandler : IHttpHandler
{
public bool IsReusable { get { return false; } }
public void ProcessRequest(HttpContext context)
{
if (Cache.Scripts != null && Cache.Scripts.Count > 0)
{
string s = "";
foreach (var src in Cache.Scripts)
{
s += ScriptResolver.GetLocalScript(GetFileName(src));
}
s = Compressor.Minify(s);
Compressor.Compress(context);
context.Response.Write(s);
}
}
string GetFileName(string src)
{
int start = src.IndexOf("src=") + 5;
int end = src.IndexOf(".js") + 3;
return src.Substring(start, end - start);
}
}
As you can see, it looks up that cached list of removed .js references and goes through them, reading each .js file and combining all scripts into one big string. ScriptResolver just opens and reads file from disk, nothing interesting. Then using Response.Write handler will stream resulting string to the client instead of passing back not-existing "combined.js" file that browser asked for. Before sending, it will use Compressor to minify string and compress response. Our compressor is not too complicated:
using System;
using System.Web;
using System.Text;
using System.Text.RegularExpressions;
using System.IO.Compression;
public class Compressor
{
public static void Compress(HttpContext context)
{
if (IsEncodingAccepted("gzip"))
{
context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);
SetEncoding("gzip");
}
else if (IsEncodingAccepted("deflate"))
{
context.Response.Filter = new DeflateStream(context.Response.Filter, CompressionMode.Compress);
SetEncoding("deflate");
}
}
public static string Minify(string body)
{
string[] lines = body.Split(new string[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries);
StringBuilder emptyLines = new StringBuilder();
foreach (string line in lines)
{
string s = line.Trim();
if (s.Length > 0 && !s.StartsWith("//"))
emptyLines.AppendLine(s.Trim());
}
body = emptyLines.ToString();
// remove C styles comments
body = Regex.Replace(body, "/\\*.*?\\*/", String.Empty, RegexOptions.Compiled | RegexOptions.Singleline);
//// trim left
body = Regex.Replace(body, "^\\s*", String.Empty, RegexOptions.Compiled | RegexOptions.Multiline);
//// trim right
body = Regex.Replace(body, "\\s*[\\r\\n]", "\r\n", RegexOptions.Compiled | RegexOptions.ECMAScript);
// remove whitespace beside of left curly braced
body = Regex.Replace(body, "\\s*{\\s*", "{", RegexOptions.Compiled | RegexOptions.ECMAScript);
// remove whitespace beside of coma
body = Regex.Replace(body, "\\s*,\\s*", ",", RegexOptions.Compiled | RegexOptions.ECMAScript);
// remove whitespace beside of semicolon
body = Regex.Replace(body, "\\s*;\\s*", ";", RegexOptions.Compiled | RegexOptions.ECMAScript);
// remove newline after keywords
body = Regex.Replace(body, "\\r\\n(?<=\\b(abstract|boolean|break|byte|case|catch|char|class|const|continue|default|delete|do|double|else|extends|false|final|finally|float|for|function|goto|if|implements|import|in|instanceof|int|interface|long|native|new|null|package|private|protected|public|return|short|static|super|switch|synchronized|this|throw|throws|transient|true|try|typeof|var|void|while|with)\\r\\n)", " ", RegexOptions.Compiled | RegexOptions.ECMAScript);
return body;
}
private static bool IsEncodingAccepted(string encoding)
{
return HttpContext.Current.Request.Headers["Accept-encoding"] != null &&
HttpContext.Current.Request.Headers["Accept-encoding"].Contains(encoding);
}
private static void SetEncoding(string encoding)
{
HttpContext.Current.Response.AppendHeader("Content-encoding", encoding);
}
}
It has home-brewed Minify function (demo replacement for Ajax.Minifier) to make scripts meaner and leaner and Compress method to "gzip" response that should shrink styles even more to save bandwidth. With all that taken care of, our end result should look something like this:
Here we are, going from 134.4KB to 51.2KB in size and saving browser two round-trips. No, this sure won’t score 100 as we didn't take care of image optimization, browser caching, setting appropriate HTTP headers etc - but that's ok and by the way even this bare-boned solution took me from 44 up to 86 points at page speed test. This code is intentionally simplistic and doesn’t take into account age cases, error handling etc. This is for clarity and to better represent concepts of combining, minifying and compressing in general. You can download project from link below and run it in Visual Web Developer, WebMatrix or as IIS application. It is very little code that is easy to follow.
JUST DON'T USE IT AS PRODUCTION-READY CODE!
Because it is not :) At least not yet, I'm working on possibly utilizing it for BlogEngine.NET and will publish more solid version later. Current code is for demo purposes only, it lacks tons of things you would absolutely require in your real-world application and makes way too many bold assumptions. But with all those things taking most of the space it would be a lot harder to understand workflow I really wanted to focus on.
Demo1.zip (57.82 kb)
Remember those lazy days when you could kick your trustworthy CDONTS mail messages from anywhere inside juicy spaghetti code and it just worked? Well, those days are over. Even 1.x’s System.Web.Mail – also not a brainier to use – is outdated and big no-no our days.
Now we supposed to use [W:SMTP]. And sometimes this beast just refuses to cooperate. Complete showstopper. I’m not a quitter, but I’m not going to spend countless hours googling around for the fix either (although, I admit, it is kind of addictive). So after short hunt, when first four or five “guaranteed” solutions did not work out I started looking for workaround. More...