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)
Tell me what you want, but CSS is twisted. Some simple basic tasks that should be no-brainer sometimes make you throw things and say words you later deeply regret. Usually people use IE6 as lightning rod, sadly even if you don't care about IE6 anymore CSS still will find ways to hurt you. Consider this simple scenario - I want DIV with some text and 3 little ones inside it alined right.
In a sane world, you would create a DIV, text element inside it, then 3 more DIVs with appropriate size and alignment. In CSS world, you should first "wrap your head around it" - meaning, make your brain just as twisted so it is in sync with framework. Then you understand that this is not how things "float". You need to do it all backwards! Is it hard? No. Intuitive? Hell no! May be, we need jQuery for CSS to make things to make sense. I think I even saw one somewhere on the internet, may be I'll go look around. But first I need to turn few pages in my old good "VB for dummies" book to calm down.
<html>
<head>
<style>
#widget { width: 300px; display: inline-table; background: #dedede; padding: 5px; }
#widget div { float: right; width: 20px; margin-left: 2px; border: 1px solid #ccc; text-align: center; }
#widget h2 { padding: 0; margin: 0; font-size: 16px; }
</style>
</head>
<body>
<div id="widget">
<div>3</div>
<div>2</div>
<div>1</div>
<h2>Some pretty long title splitting on second line goes here.</h2>
</div>
</body>
</html>
Lots of people use Google Analytics to track user statistics on the blog. If you one of them, there is another tool you might be interesting in – something called “Woopra”. Although Analytics are cool, Woopra excels in real-time tracking – it literally shows what is going on your blog right now. Just tale a look at the picture below – you can see how many people are browsing through your blog, what pages they on, searches used to bring them in, referring sites and more. And it is all real-time, you can see people coming and leaving. Pretty fun stuff.
This will probably work with any blogging software, definitely works nicely with BlogEngine. Simply create account with Woopra, they will give you a tracking script similar to how Analytics does. It is recommended you add this script to your header section (admin/settings/custom code/html head section) but I suspect it will work if added to “tracking script” section just as well. There is size limitation for free version, 30,000 “actions” per month, but that should fit any casual blog easily. You can also buy premium if your blog suddenly goes into the stratosphere.
I was looking for a warm colorful theme for my kids/family site and this one from ezwpthemes.com looked like a good fit (leaving aside it is in the dating category…). Anyways, I did little experiment and slightly changed my routine converting Wordpress themes by going straight to “view page source” and working with raw HTML instead of dealing with server-side code. This time I actually got down and dirty to all those PHP files and built theme by merging templates and replacing PHP code with ASP.NET equivalents when possible. It wasn’t hard at all, which proved a point I had in mind going to PHP files in the first place. I think it is relatively easy to build a converter that will take Wordpress theme and spit out theme for BlogEngine. Wouldn’t that be awesome? Ok, it won’t get 100% result, some things will need to be worked out after post-conversion process by hand. But even if it will get 80% of the job done, I’d take it. I just might try it some day!
Meanwhile, give a try this new theme. It looks best in BE 2.5, but also works fine with version 2.0. If you find any problems, drop a line here.
Theme can be downloaded from the dnbegallery and you can preview it here.