Delivering Performance: How does your content management system score?
31 Aug 2010
Last week, I was talking with a client who is on the hunt for a ASP.NET-based CMS, and he asked me what I know about how content management systems affect site speed. It’s a really good question.
As a former executive in the CMS space, I know we always took the “we just sell guns, we don’t kill people approach.” In other words, we just built the containers and the users put in the content, so how could we be reponsible for site speed? However, I knew that the choices we made in the underlying CMS system did have a dramatic impact on site speed.
So over the weekend, I decided to try a very unscientific experiment. I singled out five ASP.NET content management systems — Sitefinity, DotNetNuke, Ektron, Kentico, and Sitecore — and tested* their page load times along with the page load times of four of their case study clients. I tried to choose a similar cross-section of sites from each, wherever possible: ecommerce, not-for-profit, corporate, and educational.
This table shows the load time for each site, with the averages for each CMS solution provider in the column on the far right, listed in order from fastest to slowest. Click through to see the test results for each site.
| SITEFINITY | Quaker Oats | Discover BC | AT&T Web Hosting | The Trump Network | AVERAGE LOAD TIME |
| 3.113 | 7.409 | 6.747 | 3.000 | 4.677 | 4.989 |
| DOTNETNUKE | Pier 1 Imports | Marriott Orlando | Midas | UNPAN | |
| 7.538 | 7.379 | 5.309 | 7.052 | 8.927 | 7.241 |
| EKTRON | NYC Ballet | Special Olympics | University of Virgina | MGM Casino | |
| 8.528 | 6.464 | 7.246 | 7.412 | 8.136 | 7.557 |
| KENTICO | Habitat for Humanity | Bayer Health Care | CARES: Kids Fly Safe | OASIS | |
| 4.088 | 11.008 | 11.472 | 7.405 | 4.942 | 7.783 |
| SITECORE | Boy Scouts of America | Beliefnet | Canadian Cancer Society | WebTrends | |
| 8.465 | 8.141 | 9.629 | 10.346 | 11.827 | 9.681 |
Note that none of the sites fared particularly well. The average page load time was 7.45 seconds, which is not blazingly fast by any standard. But what was interesting to me was the variance in the averages: there was an almost 5-second gap between the company with the fastest average load time and the company with the slowest. At the outset of this little experiment, I was expecting the averages to fall within a much smaller spread. This greater variance seems like it might be an indicator of… well, something.
Some mitigating factors
Now, as I’ve already said, this was a pretty unscientific study — like most studies that take place between 10 pm and 2 am on a Saturday night. In all fairness to the CMS providers I tested, there are a few variables they have no control over, including:
- Randomness — Maybe I randomly chose Sitefinity’s four best sites, and Sitecore’s four worst. It’s possible. Though I do think it’s interesting that top-ranked Sitefinity’s own website loaded in just over 3 seconds, while bottom-ranked Sitecore took more than 8 seconds to load.
- How the CMS is used — If you’re committing no-nos, such as uploading massive unoptimized images or not enabling compression, the CMS can’t compensate for those things.
- Third-party content — As I’ve mentioned in another post, third-party content is a wild card that your CMS can’t control.
But I do think there’s a kernel of truthiness even in my quick voodoo-science survey, enough to warrant asking a few questions of your CMS provider or in-house CMS developers.
If you use a CMS, or are planning to, three questions to ask
- How does the CMS apply Yahoo and Google‘s performance best practices for things like optimizing caching, optimizing browser rendering, and minimizing roundtrips and payload?
- If the CMS does apply some of these best practices, what is the provider’s process for updating your CMS software to accommodate new best practices as they emerge?
- How does the CMS deliver performance internally? In other words, how fast will its pages load for you when you’re the one out there actively pushing new content? This study by Aberdeen Group states that issues with application performance are affecting overall business revenues by up to 9%. That includes CMS performance. I know from painful experience that a slow CMS is an excruciating performance killer.
A giant caveat
Having said all of this, I’m very aware that it’s overly simplistic to suggest that you choose your CMS provider based solely on its ability to deliver performance. You need to take a lot of other things into consideration: core functionality, usability, support, price. All I’m proposing is that when you’re creating your CMS scorecard, add “performance” to your list of criteria.
A great big juicy business opportunity?
With site speed emerging as a critical business requirement, is this an opportunity for a CMS solution provider to step up and deliver a product that can promise to optimize pages for faster performance? It seems to me that it is.
*All tests were conducted using Webpagetest: IE7 on DSL via the server in Dulles, VA.

Tweets that mention Delivering Performance: How does your content management system score? — Web Performance Today -- Topsy.com
Aug 31, 2010 @ 10:08:16
[...] This post was mentioned on Twitter by sausagebot, Joshua Bixby. Joshua Bixby said: New blog post: Delivering Performance: How does your content management system score? http://bit.ly/cig45g [...]
Aug 31, 2010 @ 11:17:38
I think Umbraco should have been tested as well. It serves most content from RAM/cache when setup correctly. http://www.asp.net is powered by Umbraco.
Aug 31, 2010 @ 13:15:23
Joshua, first let me thank you for including Kentico in this comparison.
Still, I must say that this way of testing doesn’t provide any real information on how fast or slow a CMS is, because there are literally hundreds of factors that influence the overall website performance. Consider the following: hardware configuration, network connectivity, current traffic on the website, current trafic on the network between you and the site, and most importantly – the configuration of the CMS, version of the CMS, website size and custom code used by the web developer who created the site. The only way how to test CMS performance is to create a sample website, let the vendor help you optimize the settings for highest performance and then run a 24-hour load test on the same configuration.
Also, the features of the CMS obviously have an impact on the website performance. If you take a very basic CMS like Sitefinity or DotNetNuke and compare it to advanced, full-featured suites like Kentico or Sitecore, it’s no surprise that without proper configuration, the simple CMS will perform better. But at some point, you may get to the situation where a simple CMS will not be able to scale more in a large web farm or over multiple database servers and then the advanced CMS systems will show the advantage of their well-designed enterprise architecture.
We did lots of load tests that can be found in Kentico CMS Performance Report at http://www.kentico.com/downloads/KenticoCMS_5_5_Performance.pdf. It shows you can get as low as 4ms (! yes, miliseconds !) per page with Kentico CMS using a two-server web farm on a very common hardware configuration (we actually used desktop computers with a single Quad-Core processor).
Also, based on our experience, I can tell you that we were often able to help clients reduce the load time more than hundred-times by optimizing their code, configuring the caching, etc.
If you’d like to get any additional information about Kentico CMS for ASP.NET performance, please feel free to send me a message.
Sep 01, 2010 @ 00:27:20
Hey Joshua, I really like this benchmark, because it’s a real life experience. We all get company intern benchmarks that say how fast it could probably get IF you have the right equipment, the right code etc. But in the end it should be fast even without all these “enhancements”! Good comparison to see when I look for a new CMS!
Thanx!
Sep 01, 2010 @ 01:26:30
Petr,
I am bewildered by the comments with regards to DNN and Sitefinity. It’s either due to ignorance, or as an attempt to create an improper impression in the minds of the readers of this blog.
I don’t know what is your definition of “simple” and “advanced” CMS systems, but I do know that http://www.telerik.com is running on Sitefinity. Our site has over 400,000 community users, more than 500,000 forum posts, tens of thousands of pages, it is used by over a hundred content editors simultaneously, it serves millions of pages each month and has lots of modules and integrations to a dozen external systems. Oh, and it runs in a WebFarm setup just perfectly.
Your company has a good track record of using other companies’ names frivolously in order to win some attention, but please be more mindful of the facts.
Sep 01, 2010 @ 16:53:18
@Petr
If all you are looking at is how fast the back-end can spit out html then you’re missing the big picture (and the bulk of the time it takes for a user to receive the page).
A good CMS will force best practices for it’s plugins and content authors without the owners having to do the heavy lifting. Things like:
- Versioning static files (css, js in particular) and setting far-futures expires on all static content
- Merging css and javascript files into as few as possible
- Putting javascript at the bottom of the pages instead of in the head
- Using image sprites (and/or data URI’s) for page elements
- Built-in support for offloading static objects to a CDN
All of this should “just work” out of the box and enabled by default. There’s a LOT more that could be done but this is the bare minimum and I haven’t seen a CMS that does even these without additional software or plugins.
Designing a fast back-end is trivially easy by comparison.
Sep 02, 2010 @ 16:55:55
I think Petr’s reaction and Patrick’s comment sum up the key point in this post: the CMS community still believes that doing a lab test demonstrating back-end speed shows that they perform well.
I’m not singling out any particular company for criticism. In fact, when I was CEO at IronPoint, we were as ignorant and as guilty as anyone. It’s like the entire community either doesn’t understand the problem or doesn’t want to acknowledge that the problem exists. It’s the big white elephant in the room when it comes to performance.
Steve Souders has talked often about the notion of fast by default:
http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/
In this post he says “To make it easier for developers, we’ll see performance best practices get built in to CMSs, templating languages (PHP, Python, etc.), clouds (AWS, Google App Engine), JavaScript libraries, and most importantly in major conduits of the Web – browsers, servers, and proxies. A lot of this is already happening.”
Well, it is not happening in most CMS solutions. Let’s hope it does.
Sep 03, 2010 @ 23:28:19
@Patrick and @Josh
Well, I take this as a challenge to do things better on the CMS vendor side.
As an excercise, we analyzed the Kentico.com performance and we figured out that the main improvement we can make is moving the static files (site graphics that is not managed by the CMS) to a CDN. After this change, our result improved from 4.088s to 2.740s (see http://www.webpagetest.org/result/100904_45XN/1/details/). There weren’t any major things that we could improve on the CMS side to make our site faster.
What it shows is that no matter how optimized the CMS is, the final result will always depend on the web designers and developers who need to take care of optimizing their graphic, HTML code, C#/PHP/whatever code and also infrastructure and overall architecture. And I appreciate that your blog posts help to educate the developers.
As a CMS vendor, we can help improve the results or enfore best practices here and there (for example our CMS supports automatic resizing of uploaded images, fixes invalid XHTML code, eliminates .NET viewstate, etc.), but without deep understanding on the developer’s side and good planning, we cannot really guarantee the results of the final website.
Since Kentico CMS provides a flexible development platform, we do not restrict the developers in their creativity pushing them into a “single way how to do things best”. But it also means that they can make mistakes. For example, we could push them to put their JavaScript files into a single file. But then, what if they need, for whatever reason, to place them separately into a specific place in the code?
I would compare this to website security – while the CMS vendor can do a lot on his side, the security of the site always depends on many other factors – network and system security, custom code security, users writing their passwords on Post-It papers, etc.
Conclusion: CMS vendors can help, but there’s no silver bullet for automatic optimizing of website speed.
PS: With 2.740s, we can finally say Kentico CMS is the fastest CMS in the world … LOL
Webmaster Crap » Blog Archive » Delivering Performance: How does your content management system …
Sep 06, 2010 @ 08:43:42
[...] Read more from the original source: Delivering Performance: How does your content management system … [...]
Sep 09, 2010 @ 10:10:51
Thanks for responding, Petr. I think you’ve nailed the fact that a well-optimized CMS-driven website is a collaboration between the CMS provider and the developers who own the site. The responsibility of the CMS provider is to create a tool that will automatically implement as many performance rules as possible, and then to educate customers as to what performance best practices remain for them to implement. The key is being as honest and as transparent as possible.
Looking for VC funding? Then you need to be at least this fast. — Web Performance Today
Sep 14, 2010 @ 15:01:16
[...] Delivering Performance: How does your content management system score? [...]