The Dutch Umbraco Festival 2012 was held in Leiden (The Nederlands) and organized by Mindbus, the first Umbraco Certified Gold Partner in the Netherlands. Some 100 Umbraco developers, heard Umbraco founder Niels Hartvig reveal some exciting news on the future of Umbraco.

Hartvig started however with some criticism on the new Umbraco version, V5. This is, as you may have heard a completely rearchitectured version of Umbraco that is build on Microsoft's ASP.NET MVC. Umbraco V5 holds the promise to be even more extendable by allowing data to come from lot's of different data sources through something called the Hive.

Apparently the Umbraco HQ has been too confident in bringing out Umbraco V5, without enough real world website implementations. Umbraco 5.0 was too slow and there where usability issues. Now Hartvig makes a Mea Culpa, and talked about the improvements for Umbraco 5 that are around the corner.

Umbraco 5.1

First of all, next week will see the release of Umbraco 5.1 . This version has a lot of performance improvements. It has the long awaited membership functionality and it will contain some 20 Razor snippets for creating navigation, breadcrumbs, etc… Furthermore it has improvements for the tooling experience. An online enquiry revealed that 75 % of all Umbraco development is done either with the Visual Studio or Webmatrix development environments. So Umbraco 5.1 now has Scaffolding functionality for creating controllers and views that make developing for Umbraco V5 a lot easier. Also announced, is a Visual Studio Template for creating Umbraco V5 projects.

Another improvement that comes with Umbraco 5.1 is the availability of Fluent API's. These API's, inspired by jQueries method chaining, makes it easy to create content programmatically.

Umbraco 5.2

Hartvig revealed some functionality for future Umbraco releases that will come after Umbraco 5.1. In this next version, which should be released around the time when the annual Umbraco Developer Conference, CodeGarden 2012 will be held, there will be a Node Selector. This Node Selector is the successor of the very popular Multinode Tree Picker. Announced as a feature of the Umbraco 5.2 release is better functionality for creating and publishing packages with the use of a Package Creator.

Umbraco 4.8, the 'Ultimate V4 version'

For Umbraco V4, Niels announced Umbraco version 4.8 which should be released in May 2012. Umbraco 4.8 will be the last version for Umbraco 4, and he announced it as 'The Ultimate V4 version'. All dependencies will be updated with the latest versions and all pull requests will be merged. The biggest news with this version however is that the best components of uComponents, a very popular Umbraco Package, will be merged into the core of Umbraco 4.8.

Umbraco Concorde

However, like the late Steve Jobs tended to keep the best for last, Niels Hartvig revealed some details about Umbraco's investments for the Cloud with the project named "Concorde". Concorde can be seen as 'Umbraco as a Service'. Lately lot's of CMS's are providing Cloud services. Umbraco however takes a slightly different path, as Hartvig is saying, these services don't really solve the problems that classical hosting services pose. Therefore Concorde will be optimized for team development through the use of the popular Git source control system. With Concorde it will be possible to branche complete Umbraco solutions, it will provide automated upgrades and it will have a very attractive pricing that will be cheaper than a VPS. Asked about the price he revealed a pricing around 19 euro/month for a Concorde project. The revenue generated through Concorde should enable the Umbraco HQ to focus again more on the development of the Umbraco Core.

Summary

The Umbraco future looks very bright indeed. Developing for Umbraco 5 will become a lot easier through the use of Fluent API's and Scaffolding. Even as we speak, the Umbraco HQ is working hard on creating documentation for Umbraco V5 and a completely revamped Umbraco.tv providing video tutorials for Umbraco V5 development. The Umbraco Concorde project will make it a snap to deploy Umbraco websites in the Cloud, and the resources it will generate will enable the Umbraco HQ to invest more in the development of the Umbraco Core.

In the first part I spoke about the four rules of thumb of optimizing the performance of your website. One of these rules states:

Send [data] as infrequently as possible

In part three I explained a technique to enable this: configuring the Content Experation Headers on your webserver

In this fourth part in the series of optimizing the performance of your website, I will deal with another technique to send data as infrequent as possible, that is, implementing the use of Content Distribution Networks

Content Distribution Networks (CDN)

The idea behind a CDN is that the webserver gets less requests for static files (CSS, images, Javascript) because these files get served by a worldwide network of server. Because these servers a geographically in located closer to the user requesting the files, they get downloaded faster to the user's browser.

I a user requests a file that is not yet in the CDN's cache, the CDN will request the file from your server an d store it in it's cache. From that time on, the file get's served from the CDN's cache.

Major CDN players are Akamai, Limelight, Internap and Amazon. CDN's are primarily used for static files like images, CSS and Javascript, but there are ways to use a CDN for dynamic files. The services of these vendors don't come cheap, but If you have a big website with lot's of traffic and lot's of international visitors, a CDN can make a huge difference in the performance of your website.

There a also free CDN services, like the one provided by Microsoft and Google. The CDN's are primarily used for accessing jQuery library files.

• Microsoft: http://www.asp.net/ajaxlibrary/CDN.ashx
• Google https://developers.google.com/speed/libraries/devguide
• Jquery.com: http://docs.jquery.com/Downloading_jQuery

Following is a demo of how you can use the jQuery core library file stored on Microsoft's CDN:

jQuery core library accessed from the local webfolder (/scripts)

<script type="text/javascript" src="scripts/jquery-1.7.2.min.js">

Access to the same jQuery core library file on Microsoft's CDN

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js">

One will remark that this solution makes the website dependent on the third party CDN and this is true. Although it's very unlikely that CDN's from Microsoft or Google will go down, an uptime of 100% cannot be guaranteed.

Therefore I use a fallback script that dynamically creates a link to the local jQuery library file when jQuery is not detected after loading the page:

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js">

<script>window.jQuery || document.write('<script src="/scripts/jquery-1.7.2.min.js">\x3C/script>')</script>

Conclusion

There is no reason not to make use of a CDN for your statical files. CSS, Javascript and images get downloaded faster to the visitor's browser because the server from where this files are served is geographically closer from where the visitor is making his request. This is a big advantage for websites with lot's of international visitors.

Another advantage of using CDN for your static files is that the server gets fewer requests to handle;

Content Expiration

In part one of this blogpost series on improving the performance of your website, we saw the three rules of web performance:

• Reduce http requests
• Send as little as possible
• Send it as infrequently as possible

In this blogpost we will discuss a technique to send data from the server to the browser as infrequently as possible.

This technique consist of setting content expiration headers on the folders of your website. Like with http compression it's also a measure that needs to be taken at the infrastructure level, which is your webserver.

Why Content Expiration?

If a visitor visits a page on a website, the browser stores files like images, css and Javascript in it's cache. So what one would expect is that on a next visit to the same page, the browser will show these files from it's cache. But this is not the case.

First the browser will sent a request to the server to check if the files in it's cache haven't changed. If they have, the server will sent the new content, if they haven't, the server will sent a 304 status code, saying that the files haven't changed and the browser can load the files from it's cache.

So without content expiration, lot's of unnecessary request and responses are sent over the wire for files that are already in the browser's cache.

What we will do next is leverage the brocher's cache, by setting content expiration headers on the folders of our website.

A test before enabling content expiration

To show the effect of setting the content expiration headers on the folders of my website, I run a Page Speed test for my website:

Figure 1 Page Speed test before setting content expiration on my folders

The Page Speed Score is 91/100 This is the same since I enable http compression for my website (read my blogpost article on http compression).

Setting Content Expiration on a web folder

Page Speed suggest to enable browser caching for the folders 'css' and 'scripts'. For the purposes of this demo, I will set content expiration headers for the 'css' folder:

1. I open IIS 7.5 and browse to my css folder in the tree structure of my website
2. In the features pane I double click the 'HTTP Response Headers' function
3. In the Actions Pane on the right, I click the link 'Set Common Headers'
4. The Set Common HTTP Response Headers dialog screen shows up and I check the 'expire web content' check box.
5. In the same dialog screen I choose the 'After' radio button and fill in a expiration period of 365 days (see figure 2) and click 'OK'.

Figure 2 setting the Content Expiration headers for the CSS folder to 365 days

A test after setting content expiration on a web folder

If I do run a new Page Speed test for the homepage of my test site, I see that my Page Speed score has improved from 91/100 to 96/100 . The indicator for browser caching has turned green now, and the suggestion to chache the css folder is gone (see figure 3)

Figure 3 After setting content expiration headers the Page Speed Score has improved to 96/100

A closer look with Fiddler

To get some more details about the web performance improvement, I use Fiddler. As I mentioned in my first blogpost on Improving the performance of your website , Fiddler is a great tool to see the data traffic between the browser and the server.

Before I set content expiration for the css folder, I could see in fiddler that there where lot's of 304 status codes for files in my css and scripts folder (see figure 4)

Figure 4 Fiddler shows the 304 status responses from the server

As I mentioned before, a 304 status code is the servers way of telling to the browser that the content of these files hasn't changed.

If I check back Fiddler after I set the content expiration headers on the css folder, I can see that all the files from that folder have a max-age header set to 31536000 seconds (see figure 5). If you do the math on this you will discover that this equals 365 days. The browser now shows the files directly from the cache without sending requests to the server. This is the reason for the Page Speed score improvement from 91/100 to 96/100

Figure 5 the files of the css folder are cached for 365 days (max-age=31536000)

What if my content has changed?

Now some readers may ask themselves, what happens if content does change, will the browser still show the old file from the cache? The answer is yes. The browser will continue to show the file from it's cache until the browser's cache has been emptied or the content expiration period is exceeded.

A way to make the browser receive the updated file when the content of this file has been changed is to use a version number in your files name. When the user goes to the page, the browser will notice that there is a new file and download it from the server.

It can be a bit tedious for a developer to give all it's files a version number, that's why the technique for combining files in one file is used and to give this 'combined file' a version number, but this is the subject of another blog post in this series.

Conclusion

By intelligently setting content expiration headers on our folders, files from these folders are now immediately shown from the browser's cache. This not only made the performance of our website much better, it also takes off lots of load from the server and saving lots of network bandwith usage.

In the next blogpost we'll have a look at another technique to take the load off the server, and that is the use of Content Delivery Networks.

Http Compression

In  part one of the blogpost series on improving your website I stated that one of the basic rules to improve the webperformance is to 'send as little a possible' from the server to the browser. One way to do this is enabling http compression on your webserver. As you will see later on, this is very easily configured in IIS 7

What is http compression?

Http compression reduces the size of the files send from the server to the browser, by sending the files in a compressed format.

The server evaluates the browser "Accept Encoding" header, this is how the browser specifies to the server that it can handle compressed content. If the server finds this header in the request it will send it's response as compressed content. If the server gets a request where the client does not support compression, the server will send the response as normal content.

Http compression in IIS 7

Http compression is enabled on IIS7 for free. If you are still using IIS 6, there is a good blogpost on how to enable http compression in IIS 6.0 (http://weblogs.asp.net/owscott/archive/2004/01/12/57916.aspx)

IIS 7 has by default only static compression enabled. Static compression means that on the first request, IIS will compress static files like Javascript files and CSS files, and keep them cached on the server, so that with a next request it can serve those cached compressed files.

Dynamic compression also compresses dynamic content. It does has a small CPU load of about 1% because unlike static compression IIS cannot cache dynamically compressed content, but if you are that tight on CPU usage you got a bigger problem on your hand than that. Besides, IIS 7 also gives you the ability to stop using dynamic compression if your CPU usage goes above a certain level.

Http compression demo with IIS 7.5

To see the benefits of IIS Compression, we do a little test. I installed a testsite and disabled static and dynamic compression on IIS 7.5.

If I run Google Page Speed, I get a Page Speed score of 76/100 (see figure 1). The red alert suggestion states that I should enable compression:

"If you compress your files with gzip, their filesize will be decreased with 104.4 KiB (a gain of 71%)"

Figure1 With http compression off, the Page Speed score is 76/100

To enable IIS compression, I take the following steps:

1. Open IIS 7.5
2. Choose my website in the tree
3. Click 'Compression' in the Features pane
4. Check both 'enable static content compression' and 'enable dynamic content compression' (see figure 2)
5. Click 'apply' in the Actions Pane to apply your changes

Figure 2 Enable static and dynamic content compression in IIS 7.5

If I run the Page Speed test now, I get a huge benefit, instead of 76/100 my Page Speed score is now 91/100 (see figure 3)

Figure 3 After enabling IIS Compression for the content of my website, my Page Speed score is 91/100

Conclusion

So to conclude on http compression, by enabling static and dynamic compression on the webserver,  there is a great reduction in the size of the files that are sent from the server to the browser. This not only results  in a huge performance benefit for your website, but also in reduced bandwidth usage. With all the major browsers supporting compressed files there is not a good reason not to use http compression.

This is a blogpost series on web performance and we will have a look at some tools and techniques to optimize the performance of your website.

Other blogposts in this series are:

• part 2: http compression
• part 3: content expiration

Why optimize the performance of your website?

Optimizing the performance of your website is important for mainly two reasons:

• Faster page download times
• Reduced bandwith usage

Faster page download times are not only important for your users, of which we know will move away from your website if they have to wait too long for a page to download. Fast downloading pages are also important for the indexation of your pages by Google. Google officially stated in 2008 that it would take the page download time as an additional factor for they quality score (Google official statement on page download time)

Reducing the bandwith usage on your network and server actually can save you money because there is less data traffic between the server and the clients requesting content on your server.

Basic performance rules

There are tree basic performance rules:

• Reduce http requests
• Send as little as possible
• Send it as infrequently as possible

Reduce http request

To improve the performance of your website, you should try to minimize the number of requests between the client and your server. Techniques for accomplishing this is bundling of files into one file and using sprites for your images. We will look into this techniques in further blogposts in this web performance blogposts series.

Send as little as possible

Techniques for this are:

• Minification of your css stylesheets and Javascript files
• Enabling http compression on your webserver
• Optimize your images

We'll dive deeper into this techniques in the following blogposts in these series on improving performance of your website.

Send it as infrequently as possible

There are mainly two techniques for sending content as infrequently as possible:

• Set Content Expiration headers
• Using Content Delivery (CDN) networks

In the next blogpost article in this series we will look into how to set the content expiration on the webserver to prevent unnecessary requests to the server.

We'll also take a look at Content Delivery Networks. These are global networks of servers that offload work from your server. Another advantage of a CDN is that these servers are geographically closer to your user which results in faster download times.

Measure, measure, measure

Before you start optimizing the performance of your website, you should measure first the performance of your website and locate the areas that are causing longer download times.

After you have located the performance issues, you should also measure if your performance optimizations actually improved those performance issues.

Following are some tools that you can use to measure the performance of your website

Fiddler

One of the most used tools for measuring webperformance is Fiddler. Fiddler was developed by Microsoft's Eric Lawrence and it enables you to trace all http traffic between your browser and the server. Fiddler has some nice features like the Transfer Timeline, that shows a graphical view of all the requests and the time it took to download them.

Figure 1: The Transfer Timeline in Fiddler

more information: www.fiddlertool.com

Network Monitor

Network monitor is a free tool from Microsoft. The difference with Fiddler is that Fiddler only traces http traffic while Network Monitor analyses all protocols.

More information: http://www.microsoft.com/download/en/details.aspx?id=4865#overview

Page Speed (Google)

Page Speed is an open source project for measuring the performance of your website. The nice thing about Page Speed is that it gives the webdeveloper suggestions for improving the performance of his website.

Figure 2: Google Page Speed as a Chrome Extension

Page Speed is available as a Chrome Extension and as an online service

More information: http://code.google.com/speed/page-speed/

LogParser (Microsoft)

LogParser is another Microsoft tool that allows you to analyse your IIS log files using a SQL query like language. You can export the result to a .csv , XML, and many other output format files

More information: http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1976

LogParser is a tool that runs from the commandline. There also exist GUI tools that use LogParser like LogParser Lizard from Lizard Labs (http://www.lizard-labs.net/log_parser_lizard.aspx)

Third party services

Keynote and Gomez are commercial services for long term performance trends and comparison to other major websites

Keynote: http://www.keynote.com/products/web_performance/web-performance-testing.html

Gomez: http://www.gomez.com/instant-test-pro/

Summary

In this blogpost I gave a high level overview on the basic rules of performance optimization.

I also stressed the importance of measuring your website performance before and after you applied your performance optimizations

Finally I reviewed some tools for measuring your website performance

In the next blogpost in these series we will have a closer look at the performance optimization techniques at the infrastructure level, more specifically your webserver. These techniques include http compression, setting content expiration headers and using Content Delivery Networks