Try our conversational search powered by Generative AI!

Alexander Haneng
Jul 14, 2014
(3 votes)

EPiServer CMS Site Performance Part 1: Introduction

In this series we will look at how we can make the “Cloud Clinic” demo site we built with EPiServer CMS 7.7 perform and scale better.

In this first part we will do some base line measurements so we can see how our site perform before we do any improvements. In future posts we will try to minimize the size of the page, add caching, use Azure’s automatic scaling, add a CDN and generally anything we can do to make it faster.

Our demo site: Cloud Clinic
In a previous post wrote about how I created the Cloud Clinic demo site. It is a very small and static site (no visitors groups or user log in). However the HTML/CSS/JS came from an external source (Template Monster) and is not of the best quality (as we sometimes get in real life projects).


A base line measurement
The first thing we need is to do some base line measurements. In this case I have used YSlow for Chrome, Google Page Speed Insights and LoadStorm.

Chrome and YSlow 
We can get a basic feeling for the size of the site (bytes on the wire), number of requests and rendering time using the built in developer tools for Chrome and the YSlow add-on.

Bytes transferred: 333.3KB
Requests: 35
Time: 1.27 seconds


Google PageSpeed Insights
The PageSpeed online tool gives you two scores: one for mobile and one for desktop. The scores give you a good indication on how fast your site is. In addition you get detailed lists on what you need to improve. In our case it complained about browser caching, render-blocking JS, CSS that needs minifying and images that are not optimized.
Mobile score: 64/100
Desktop score: 77/100


Load testing with LoadStorm
LoadStorm is a paid cloud based load testing tool, but they also offer a free “QuickStorm” load testing service with 10 vusers over 10 minutes.

First I tried to run this tool with my Azure Web Site set to the free plan. After about 4 minutes it stopped responding and stayed that way for hours. Turns out the free plan only gives you a certain amount of CPU time for each interval, and when that CPU time is used up it will stop serving the site until a new interval starts. (This is also the case for shared, but with a higher CPU quota.) I flipped the switch to “Shared” and ran a new QuickStorm test.


QuickStorm load tests the front page of the site starting with 1 vuser and adds another vuser very minute ending in 10 vusers for the last 2 minutes.

From the graph we can see that didn’t stress the site out as the average and peak response times stayed fairly even all through the test. Here are the details:


The demo site performance isn’t terrible, but it isn’t great either. Now we have some base line measurements that we can compare with.

Go to Part 2: Bundling and Minification

Jul 14, 2014


Please login to comment.
Latest blogs
The A/A Test: What You Need to Know

Sure, we all know what an A/B test can do. But what is an A/A test? How is it different? With an A/B test, we know that we can take a webpage (our...

Lindsey Rogers | Apr 15, 2024

.Net Core Timezone ID's Windows vs Linux

Hey all, First post here and I would like to talk about Timezone ID's and How Windows and Linux systems use different IDs. We currently run a .NET...

sheider | Apr 15, 2024

What's new in Language Manager 5.3.0

In Language Manager (LM) version 5.2.0, we added an option in appsettings.json called TranslateOrCopyContentAreaChildrenBlockForTypes . It does...

Quoc Anh Nguyen | Apr 15, 2024

Optimizely Search & Navigation: Boosting in Unified Search

In the Optimizely Search & Navigation admin view, administrators can set a certain weight of different properties (title, content, summary, or...

Tung Tran | Apr 15, 2024