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. 

You can read more about this service on Cloudflare or Microsoft Azure CDN

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?

CDN Bingo

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.

100+

content pages

10+

images on page

2+

target countries

10+ GB

media files

4+ seconds

full page load

100.000+

sessions per month

500.000+

page views per month

>40%

mobile traffic

5+ MB

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?

This is the first question you should ask. There are many tools to help you answer it such as Google Pagespeed Insights, WebPageTest, Lighthouse, GTMetrix and others.

The metrics you should be looking at are:

  • Time to first byte (TTFB)
  • Full page load time (HTML + all images, JavaScript, CSS, etc.)

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:

Is your website slow

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:

Global CDN nodes

But the real number of edge CDN servers is significantly higher, and looks more like this:

Local CDN nodes

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.

Contacts geolocation

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:

Contacts geolocation behind CDN

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.

Cookies

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):

Cookies and CDN

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:

Page Builder error

The quick fix is to configure a CDN to bypass the cache for all URLs starting with “/cmsctx/*”.

Form builder

Forms built with the Kentico Form Builder, as well as some of your custom MVC forms, may stop working unexpectedly. The cause of this is the use of an AntiForgeryToken to prevent a  CSRF attack. It uses cookies in the background and can become an issue, so remember to test it.

Campaign tracking

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.

A/B testing

The Kentico A/B testing feature uses cookies to decide which variant to display to a site visitor. Similar to other cookie-based features, this will mean that A/B testing may stop working.

Sticky session

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:

Sticky session and CDN

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:

Personalization and CDN

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.
  • Where all dynamic parts listed above will always be requested from the website’s  origin via JavaScript ,after the default version of the page is loaded.

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.

Conclusion

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: hello@deleteagency.com

GET IN TOUCH
Make enquiry

Delete Limited.

Registered in England.

03933385

Registered Address.

3370 Century Way, Thorpe Park, Leeds, LS15 8ZB

VAT Registration.

GB 927 1409 27