Sitefinity Cloud utilizes CDN, distributed output cache, page precompilation, and autoscaling, which significantly increases your website performance.

Page precompilation

Precompilation of pages is a standard feature of ASP.NET that has the following advantages:

  • Helps pages load faster when requested for the first time
  • Reduces processor load
  • Skips the warm-up phase when a site is deployed

While Sitefinity CMS offers a precompiler tool that enables customers to precompile the pages of their website, Sitefinity Cloud, seamlessly integrates the precompiler tool into the deployment process. This process ensures that when a new package is deployed to production, the pages of your website are always precompiled. Depending on the complexity of your website, this performance improvement alone can reduce the time it takes to load a page for the first time from seconds to milliseconds.

Output cache

The output cache configuration in Sitefinity Cloud has two features that improve website performance.

Distributed output cache

Azure Cache for Redis is used to share the same output cache across all website instances. This improves the performance after deployment, scale-out, and unplanned restarts, because instances that do not have to build up the output cache on their own. For example, a new website instance, which has been added after scale-out, can instantly start returning a cached response for a given page.

Output cache warmup

The output cache warmup is a powerful Sitefinity CMS feature that is configured with each Sitefinity Cloud setup. When content editors make changes to content items that are displayed on one or more pages, the output cache for those pages is invalidated. This is done to ensure that the latest content is displayed to end-users. The downside is that the first request for these pages is relatively slow, until that pages are cached again. Output cache warmup overcomes this slowdown. When using output cache, the website will request itself and cache the new version of the pages. This is done in the background and the performance of the first page request is hidden from end-users - the old version of the page is displayed to end-users, until the new version is cached. After the new version is cached, it is instantly displayed to the end-users, without decrease in performance.

The following diagram illustrates this process:



In Sitefinity Cloud every request goes through a CDN, which then selectively caches the responses depending on the cache headers from the server. This includes the HTML markup of page requests. Caching pages on the CDN level can drastically boost website performance, not only in terms of speed, but also in terms of handling large load.

The following chart illustrates the performance difference for serving a page through CDN:

Without CDN With CDN
A-B-testing CDN

Personalization and A/B testing

Sitefinity Cloud supports complex cases using CDN, such as A/B testing. Sitefinity Cloud automatically detects whether a page needs to be cached or not and provides the necessary cache-control header values to inform the CDN what to do. For example, pages that have active A/B tests will not be cached on the CDN. Pages that have fully personalized versions for the whole page will also be excluded from the CDN cache. Pages that have personalization per widget will have CDN cache, because the changes are applied client-side after the page is rendered.

Cache invalidation workflow

In a classic setup, when using CDN, the CDN cache is refreshed only after the TTL expires. This does not allow for long CDN cache durations, because website content can quickly become stale. In Sitefinity Cloud, to solve this problem, there is a workflow configured where it will proactively purge CDN cache for specific URLs. This means that every time a page is updated, the CDN cache is updated right away, with up to few minutes delay. In addition, the CDN invalidation workflow is configured to work in accord with the output cache warmup. This means that when a page is updated, Sitefinity Cloud will first request the new page, ensure it is cached on the server, and only after that will send the purge request to the CDN. This ensures optimal website performance on all caching levels.

The following diagram illustrates this process:


Was this article helpful?