Delete’s Solutions Architect and Kentco MVP, Dmitri Bastron, recently covered this topic at the Kentico Xperience Connection event. So if you missed it, or you simply want to know more about this subject, here’s a summary of what Dmitri and two other Kentico MVPs had to say.
Kentico Xperience & CDN: A Complete Guide
In this post, our Kentico MVP, Dmitri Bastron, provides a complete guide for solution architects working with Kentico Xperience explaining how to assess and identify whether you should use a Content Delivery Network (CDN) for performance.
What is a CDN?
A CDN typically refers to a cloud-based service of geographically distributed caching servers.
These are the two things to keep in mind when you’re trying to understand a positive and a negative impact of a CDN on your website:
- Is it geographically distributed?
- Is it a caching service?
Many of our clients ask if their websites require a CDN or if funds should be allocated for it as part of their hosting budgets. At Delete, I have gained a lot of experience in this area through working on many projects of all sizes, and although a CDN is easy to configure and efficient in solving certain performance issues, it sometimes can create more problems than it solves.
Before we get started you need to determine if you need a CDN. So to help, we have developed a game-like methodology to give you a quick “yes” or “no” answer. It is called “CDN Bingo”. It takes two minutes and most of the information needed to play it can be taken from Google Analytics.
Pick the facts which are true for your website from the table below.
images on page
full page load
sessions per month
page views per month
downloaded on page load
If you scored any three in a row horizontally, vertically or diagonally it’s a BINGO and you need a CDN.
If not, a CDN won’t provide any significant improvements for you.
Whatever your result, throughout this post I will provide you with more information to support the results of this game.
When do you need CDN?
Like any cloud service, a CDN isn’t free. You need to establish if the investment is worth it for your website. Deploying a CDN is not a purely technical question, it is a business decision as well.
Let’s map the CDN Bingo game statements above against the questions you should be asking yourself.
Is your website slow?
The metrics you should be looking at are:
- Time to first byte (TTFB)
At Delete, our default goal is to have less than 200ms for TTFB and less than 4 seconds for the full page load time.
If you have no problem with these two metrics then a CDN will not improve your website performance.
In fact, if your website is already relatively fast, a CDN could slow it down. After testing a CDN on a Kentico Xperience website which was optimized by configuring Output Caching and File Caching, the load test showed the following results:
TTFB for static resources cached on a CDN was the same as when resources were served directly from the origin website, but for dynamic resources that bypass the CDN, the cache TTFB increased.
Key takeaway: don’t optimise things that are good enough already.
Does your website target more than one country?
You should also check where exactly your website is slow.
If your audience is in two countries, e.g. the UK and China, but the website is hosted in the UK, the Chinese visitors may experience poor page load times compared to the UK visitors.
So test your website performance from all your key locations, this WebPageTest tool lets you do it. However, if your target audience is clustered closely on the world map then you won’t even be using a half of CDN’s benefits.
Is your traffic high?
This is an easy rule to follow:
- If your website traffic is high, a CDN will improve performance.
- If your website traffic is low, a CDN could degrade performance.
Under low traffic most static resources requested from a CDN will either not be cached yet (as nobody has requested them before), expired or removed due to low priority.
CDN edge servers will download them from your website’s origin, which may take longer than requesting them directly (see the image above).
If you configure the cache expiration for your static resources to be one year, a CDN will cache it for a year. But nothing is ever simple, as this image below shows:
But the real number of edge CDN servers is significantly higher, and looks more like this:
With this, you should remember the following:
- The actual number of CDN edge servers is higher than you think
- Each node holds its own cache
- CDN nodes typically do not exchange or synchronise their caches
- CDN nodes process other websites as well
- The amount of caching resources on each node is limited
The truth is that if other websites on the same CDN edge server have higher traffic than yours, then your cache will be among the first to be removed because of its lower priority.
The next request to a resource from the same geographical location would miss the cache and go directly to your website’s origin. You can read other support requests similar to this one, about why a CDN does not cache data for a long time.
Do you have many static resources or media files?
Look at the overall volume of images, documents and downloads your website serves. In my experience, if the total size of static resources is:
- Less than 10GB, then your server should definitely handle it without a CDN
- 10-100GB, you may see positive effect from a CDN
- 100GB and growing, then a CDN will be useful
The more static resources you have, the longer you will be able to cache them.
Do you have a lot of mobile traffic?
Another important factor is the amount of mobile traffic.
Despite the launch of 5G networks, mobile internet remains slower than stationary internet. This public research data shows an average of 20+ Mbit/s for 4G and 6 Mbit/s for 3G for the UK.
This is why we often see a small improvement with page load for desktop users with good internet and a big improvement for mobile users. A CDN helps to reduce network lag by serving cached data from the closest edge server.
A list of challenges with a CDN for Kentico Xperience
By now you’ll have a better idea of whether or not your website needs a CDN. But you may still wonder how much time and effort setting one up would take.
It took me two days to read the documentation and configure a CDN for a Kentico Xperience for the first time. It then took two weeks to investigate and solve all the issues the CDN created.
Here is a full list of all the major challenges I’ve encountered during several years of deploying CDNs for Kentico Xperience websites. I’ve also provided the technical solution to every challenge I’ve noted, so you’ll know the possible scenarios for things to test before going live with it.
Kentico Xperience has a great feature for recognising the specific geolocation of your website visitors from their IP addresses. I was surprised to find that after enabling a CDN, Kentico will store the CDN server geolocation instead:
You can solve this problem by substituting a ‘request IP address’ with the ‘first IP address’ in the X-Forwarded-For header that a CDN typically sends.
Depending on the CDN cache settings and response cache headers your website returns, a CDN can remove cookies from the response (there are many StackOverflow questions like this one):
If you need to set any cookies in your code, make sure you test and solve this issue with the correct CDN configuration.
MVC page builder
When a CDN is configured for your Kentico 12 MVC website, you may notice that the Kentico MVC Page Builder returns an error on pages containing MVC widgets:
The quick fix is to configure a CDN to bypass the cache for all URLs starting with “/cmsctx/*”.
If you use the Kentico campaign tracking feature make sure you test it with a CDN. Much like many other features, it’s based on cookies and a CDN can potentially cut this cookie and stop your campaign tracking working properly.
In case you have multiple Kentico MVC web applications, the load balancer and sticky session configuration may become problematic. This is shown in the diagram below:
When the load balancer is configured to use a sticky session, it adds an ARRAffinity cookie with the selected server ID from the farm. However, when the response goes through a CDN, this cookie can be removed and the next request can be directed to any other server from the farm and the sticky session simply won’t work.
Dynamic elements on the page
You may need to cache the HTML in addition to assets on a CDN for extremely high traffic pages. A CDN will keep only one cached version of HTML for every unique page URL.
The following minor things may suddenly become more complicated:
- Login state - “Hello, John!” with a small user icon on the right top corner
- Ecommerce basket state - “You have 5 items in your basket”
- Visited history - “Top 5 recently viewed products”
- Favorited, starred or saved content state - 🧡⭐ icons on your article tiles
- Suggested content - “You may also like these products”
- Personalised content - “Picture of Big Ben on the hero banner for UK visitors only”
Although Kentico offers an easy way of caching the output of dynamic and personalized content, it will work only for the HTML served directly from Kentico MVC web application.
A CDN will be completely unaware of this hidden logic:
The only viable solution for this issue is to to split the HTML into two parts:
- The HTML default version, where all common parts can be served from the CDN and cached.
Testing your CDN configuration
The IT infrastructure for most projects has multiple environments - development, test and production. Nobody anticipates that a CDN will be configured on developers’ computers, it would be complete overkill and makes writing code challenging. Nevertheless, the above list of potential issues must be tested.
My recommendation is to start testing your CDN configuration earlier and avoid doing it once you get to the production environment. Allocate enough time for your CDN configuration and ‘test, test and test’ before going live.
So to conclude, with all of the above my key takeaway for you is this:
A CDN is not a silver bullet and sometimes can bring more issues than benefits.
You should also remember to ask yourself these questions when making your decision:
- Is your website slow?
- Does it target more than one country?
- Is your website traffic high?
- Do you have many static resources or media files?
- Do you have many visits from mobile devices?
Then, when you’ve made the decision on whether or not to get a CDN, follow this approach:
- Plan it in advance
- Test the following features with a CDN
- - Kentico contact geolocation
- - Working with cookies
- - Kentico MVC Page Builder
- - Kentico Form Builder and custom forms
- - Kentico Campaign tracking
- - Kentico A/B testing
- - Sticky session
- - Dynamic elements on the page
- -- Login / my account state
- -- E-commerce basket
- -- Favorites / saved content
- -- Recently viewed
- -- Personalized content
I hope this article helps you in the same way it helps my colleagues and fellow Kentico developers here at Delete. If you’d like to know more or would like to speak to us then email: firstname.lastname@example.org