Yesterday I wrote about the support for enclusures that has been introduced with Subtext 2.0. Today I’m going to talk about the improvements we introduced to our skinning engine in order to reduce the number and the size of HTTP requests. And we added support for mobile browsers as well.
Web Performance Optimization
It all started last year, when Yahoo released YSlow, an add-on for Firebug that measures the performance of a web page based on the best practices evangelized by the Yahoo’s team for Exceptional Performance. Pushed by Mads Kristensen I improved the performances of my own blog with some manual tweaks to the style sheets and to the javascript files and introducing a handler for compressing the contents. This made my blog improve from 36 points to 64 points.
After this proof of concept I ported the optimizations to Subtext, so that all the users could benefit from them.
The optimization consists in:
- Minification of all styles and script (remove all useless space, new lines, tabs and so on)
- Merging all styles into one file
- Merging all scripts into one file
- Gzipping the contents sent to the browser
All the skins bundled with Subtext have already been updated to take advantage of these optimizations. Let’s see now how to enable these optimizations in custom skins.
How to update your skin to take advantage of the new optimizations
If you are running your blog with a custom skin, there are some steps that you have to make to take advantage of this new feature.
But just relax, everything is backward compatible: this means that if you don’t do anything, your skin will work as before, without the performances optimizations.
Step 1: Minify your files
The first step of the optimization is done at build time by our build server: all the javascript and css files provided in the installation package are already minified using YUI Compressor. But if your skin uses some custom styesheets or custom javascript files, in order get the most out of the optimization, you have to minify them as well.
If you are using some javascript loaders to load other modules (like in script.aculo.us) make sure you can load the modules also by themselves without using the loader script (with script.aculo.us it is possible).
And before you go on with the next step, please test you skin after the minification of the scripts: if the scripts are not written properly (with all the ; and } at the right place) it’s very likely that the minification breaks something.
Step 2: Change the skin configuration file
Are you sure our skin is still rendering fine after step 1? If it is, the next step is to enable the merging of CSS and scripts. To do this you have to update the skin definition which is inside the \admin\Skins.User.config file.
The new skin optimizations are enabled by 4 new attributes (in bold in the following code sample) in the skin definition:
1: <SkinTemplate
2: Name="GreenBook"
3: TemplateFolder="RedBook"
4: StyleSheet="Green.css"
5: MobileSupport="Supported"
6: StyleMergeMode="MergedAfter"
7: ScriptMergeMode="Merge"
8: ExcludeDefaultStyle="true"
9: >
10: <Scripts>
11: ...
12: </Scripts>
13: <Styles>
14: <Style href="~/scripts/lightbox.css" />
15: <Style href="IEHacks.css" conditional="if IE" />
16: <Style title="elastic" href="piyo-elastic.css" media="screen"/>
17: <Style href="print.css" media="print" />
18: </Styles>
19: </SkinTemplate>
The first 3 attributes are the ones that always existed since .Text:
- Name: is the name of the skin (the one that is in the dropdown list in the admin)
- TemplateFolder: is the name of the folder where the skin is saved
- StyleSheet: is the name of file that contains a different variation of the main skin available inside the TemplateFolder
And till here nothing new. The next 4 attributes are the new ones, so let’s review them one by one.
MobileSupport
This is not strictly related to the performance optimization, but is used to specify the level of support of the skin for mobile browsers. It accepts one of the 3 following values:
- None, the default if not specified, means that this skin doesn’t work with mobile browsers
- Supported, means that this skin works well both with desktop and mobile browsers
- MobileOnly, means that this is a skin specific for mobile browsers
ScriptMergeMode
This one enable the merging of javascript files.
- DontMerge, the default one, tells Subtext not to merge all the scripts into one
- Merge, means that all the JS files are merged into one
The scripts will be merged in the order they are listed in the skin definition.
If you specify “Merge” the skinning engine will play safe to ensure that your skin always works fine. So if one of your scripts is a remote one (maybe you want to use the version of jQuery hosted by Google) the scripts will not be merged. The same will happen if one of your scripts is specified with a query string parameter (as in scriptaculous.js?load=effects)
StyleMergeMode
When it comes to styles things get a bit more complicated: we have 3 different attributes instead of 2.
- None means that no merging will happen (default)
- MergedAfter: all css files that can be merged will be included in the page after the ones that cannot be merged
- MergedFirst: all css files that can be merged will be included in the page before the ones that cannot be merged
I know this sounds a little bit cryptic: I’ll come to this after the next attribute.
ExcludeDefaultStyle
This is a boolean (possible values true or false) that instructs the skinning engine whether to use the default style.css file or not.
Step 3: Upload and enjoy
Well… only two steps, not a complicate procedure, isn’t it?
Now just upload the modified skin configuration file and enjoy the improved performances of the frontend of your blog.
How styles are evaluated in a Subtext skin
A Subtext skin is composed by 5 different kind of stylesheets.
- style.css: this is the default CSS file, the one that contains all the layout specific for the skin.
- secondary stylesheet: the one whose name is specified with the StyleSheet attribute of the skin template. This is usually used to provide a variation over the main CSS, like a different color schema or right sidebar vs left sidebar and things like that.
- custom css: the css rules for this stylesheet are specified by the blog author in the admin section of the blog. Used to add the styles for personal badges or for styles specific to the contents of posts.
- the css files specified without any attribute: usually used for the system styles or for CSS frameworks (as in line 14 of the snippet above)
- the css files specified with some attributes: stylesheets with the title attribute (line 16) or with a conditional comment in order to be used only with specific version of IE (line 15) and with a media attribute so that they are applied only when printing or only in screen mode (like 17). Needless to say that these files cannot be merged with the others otherwise they will loose their “attributes”, so these are the “non mergeable” css.
Let’s see now the order in which all these files are included into the page in the 3 different StyleMergeMode:
None
With this value the merging doesn’t take place, so the usual order is used:
- all the css as specified in the skin definition (4 and 5)
- the default style (1)
- the secondary style (2)
- the custom css (3)
MergedAfter
All css files that can be merged will be included in the page after the ones that cannot be merged:
- All non mergeable files in separate files (5)
- The merged file with:
- All mergeable styles (4)
- the default style (1)
- the secondary style (2)
- the custom css (3)
MergedFirst
All css files that can be merged will be included in the page before the ones that cannot be merged:
- The merged file with:
- All mergeable styles (4)
- the default style (1)
- the secondary style (2)
- All non mergeable files in separate files (5)
- the custom css (3)
Feedback? Questions?
As usual, if you have questions, bug reports and feedback just write on the forums and report bugs.
Tomorrow I’ll talk about another cool new feature of Subtext: Future Posting. Please subscribe to the feed if you want to get it automatically in your feedreader.