With this week’s release of RequestReduce 1.2, RequestReduce is even more effective in reducing the HTTP requests made by a browser when visiting your website. Most significantly, this release adds the minification and merging of external javascript resources. A big thanks goes to Matt Manela for providing the initial Javascript Reduction code! Other mentionable features in this release include:
- Automatic expansion of CSS @Import. All imports will be downloaded and injected into the calling CSS and then minified and merged with the rest of the page’s head CSS.
- Wider support for PNG lossless compression. RequestReduce now issues the –fix parameter to optipng which will attempt to fix PNGs with extraneous data.
- Ignore 404 and 500 failures of individual resources. In other words, if one script or stylesheet fails to crunch, the rest should still succeed.
- Several bug fixes to the overall response filtering.
RequestReduce 1.2 is available via Nuget installations and from downloading it at http://www.RequestReduce.com. I will discuss the new features in some detail but first…
What makes RequestReduce the best static resource cruncher available?
OK. Glad I got that off my chest. Now for the details of this release’s features:
Javascript Crunching: What exactly is crunched
RequestReduce will minify all external javascripts that have a valid javascript mime type, do not have a Cache-Control header set to No-Cache or No-Store and does not have an Expires or max-age of less than a week. Furthermore you can explicitly tell RequestReduce what scripts you would like it to skip by supplying a comma separated list of url substrings. For example, on the Microsoft properties I work on, I have this set to /tiny_mce since the way that /tiny_mce loads its plugins does not play nice when the scripts are not in the same directory where tiny_mce expects them to be.
By default, if no urls are provided in this list, RequestReduce will ignore the Google and Microsoft JQuery CDNs. It does this since it is likely that browsers will not have to download this content because most will have already cached those resources while visiting a Google or Microsoft property in the past.
You can also use more complicated or customized rules via code. RequestReduce exposes a Func for approving the processing of urls. You can hook into this by registering a lambda or delegate to this Func in your Global.asax startup. Here is an example:
var javascriptResource = RRContainer.Current.GetInstance<JavaScriptResource>();javascript.TagValidator = ((tag, url) => { if(url.EdsWith(".myjss") || tag.Contains("data-caching=dont")) return false; });
The first input param is the full script tag element and the url is the javascript SRC.
Important considerations in the placement of your javascripts
In a perfect world, I would crunch all your scripts together and dynamically inject them into the DOM to load asynchronously. In fact, because the world is perfect, I could even defer the loading of the scripts until after document complete. But alas, the world is not perfect. RequestReduce knows absolutely nothing about your code and takes the safest approach to ensure that your page does not break.Therefore, RequestReduce will make sure that any dependencies that your markup has on your scripts or that your scripts have on other scripts are not broken.
RequestReduce will only merge blocks of scripts that can be reduced contiguously. For example assume you have the following scripts on a page:
<html> <head> <link href="http://localhost:8877/Styles/style1.css" rel="Stylesheet" type="text/css" /> <link href="/Styles/style2.css" rel="Stylesheet" type="text/css" /> <script src="http://localhost:8877/Scripts/script1.js" type="text/javascript"></script> <script src="/Scripts/script2.js" type="text/javascript"></script> </head> <body> <div class="RatingStar"> </div> <div class="Up"> </div> <div class="Rss"> </div> <div class="Search"> </div> <script src="http://localhost:8877/Scripts/script3.js" type="text/javascript"></script> <script src="http://www.google-analytics.com/ga.js" type="text/javascript"></script> <script src="/Scripts/script4.js" type="text/javascript"></script> </body></html>
You will end up with five scripts:
- The scripts in the <head/> will be merged together and remain in the head.
- Script 3 will be minified but will not be merged since it lies just below common markup and above a near-future expiring script (google analytics).
- The google analytics script remains entirely untouched since it is a near future expiring script.
- Script 4 will be minified but not merged since it is not adjacent to any other non near futures script.
Although script three and four do not benefit from merging, they are at least minified and served with far future expiration and a valid ETag.
With all this in mind, you want to make sure that you group scripts together that are not near future expiring and can remain together without causing issues with load order dependencies. Also make sure that you do not have any setting that causes all of your javascript to be served with a near futures expiration unless you have a particularly good reason to do so.
I intend to roll out more functionality here to allow site owners to provide hints via data attributes in the script tags where scripts can be loaded asynchronously or deferred. I also intend to use some different approaches in the ways I discover changing content on the origin server and may be able to merge and minify near future expiring content. The fact is that most near future expiring content does not change often but wants to enforce that client’s check with the server frequently just in case there is a change.
Plugging in alternative minifiers and settings
RequestReduce attempts to follow a decoupled architecture which allows developers to swap out certain parts with their own behavior. To override RequestReduce's use of the Microsoft Ajax minifier library, you simply create a class that derives from IMinifier. There is not much to IMinifier:
public interface IMinifier{ string Minify<T>(string unMinifiedContent) where T : IResourceType;}
Here Is RequestReduce's implementation:
public class Minifier : IMinifier{ private readonly Microsoft.Ajax.Utilities.Minifier minifier = new Microsoft.Ajax.Utilities.Minifier(); private readonly CodeSettings settings = new CodeSettings {EvalTreatment = EvalTreatment.MakeAllSafe};
public string Minify<T>(string unMinifiedContent) where T : IResourceType { if (typeof(T) == typeof(CssResource)) return minifier.MinifyStyleSheet(unMinifiedContent); if (typeof(T) == typeof(JavaScriptResource)) return minifier.MinifyJavaScript(unMinifiedContent, settings);
throw new ArgumentException("Cannot Minify Resources of unknown type", "unMinifiedContent"); }}
It's not difficult to imagine how you would change this implementation to use something like the YUI Compressor for.Net. Lets say you had a YuiMinifier class that you want RequestReduce to use instead of its own minifier. You would just need to add the following code to your startup code:
RRContainer.Current.Configure(x => x.For<IMinifier>().Use<YuiMinifier>());
That's it. Now your minification code will be used.
Suddenly CSS @import is not quite so evil
Just about anyone worth their salt in web development will tell you never to use CSS @Import. Except maybe the internet latency monster. He loves CSS @import but will quickly bite off your toes when he see you using it. Suffice it to say that the internet latency monster is a meanie.
RequestReduce can now identify @import usages and auto expand them so that no extra latency is incurred. I still do not think it is a good idea to use @import but now it lacks its sting.
So if you have not started using RequestReduce already, I strongly encourage you to do so. I would also greatly appreciate any feedback you have of what features you would like to see added or bugs you are running into. I’d also like to hear your success stories. You can submit all feature requests and bug reports to the github page at https://github.com/mwrock/RequestReduce/issues?sort=comments&direction=desc&state=open.