Did this article resolve your question/issue?



Sitefinity Performance optimization tips

« Go Back


TitleSitefinity Performance optimization tips
URL NamePerformance-optimization-tips
Article Number000186267
EnvironmentProduct: Sitefinity
Version: 5.x, 6.x, 7.x, 8.x, 9.x, 10.x, 11.x, 12.x, 13.x
OS: All supported OS versions
Database: All supported Microsoft SQL Server versions
Question/Problem Description
General recommendations to improve performance on Sitefinity?
How to improve the time Sitefinity takes to generate pages?
Performance improvements to the time to load the main HTML page.
Pages take too long to update after leaving the main page.
What Sitefinity features are available to improve Websites which handle a large number of requests?
Can Sitefinity preload specific pages to improve server load time?
Page updates take too long in general.
Slow loading of pages.
Website speed or page speed is slow.
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number

To narrow down the cause of the performance issues:

Measure, measure, measure

When dealing with performance issues, it is useful to know as precisely as possible what type of performance degradation one is talking about, e.g.

  • An example of a page that takes a long time to load
  • How long does it take to load?
  • Is the page always slow to load regardless of the time of day?
  • Is the page always slow do load on production and in development?

This allows a comparison between other environments and measures any improvement. For instance, if the same page loads normally off hours but is too slow during peak time, this is an indication the site is overloaded. On the other hand, if the same page takes a long time to load both on the production and development environment, a heavy load can be ruled out.

Where does the issue come from? 

Loading the page using the developer console Network tab (press F12 on most browsers) provides the first clues about where the issue could come from. In particular, focus on the time it takes to load the main HTML page:

User-added image

In the above example, the Web browser waits for 250ms for the main page to be ready to load ("Waiting (Time to First Byte)" metric), and 32ms to load it ("Content Download" metric).

  • A long "Time to First Byte" is often an indication that the Web site takes a long time to generate the page.
  • A long time to load is symptomatic of a slow network. Check with the hosting provider.
  • If the main page is quick to load but nonetheless takes a long time to be displayed, this may be because there are too many custom static resources to load (JavaScript, CSS, images). One way to reduce the overhead is to combine multiple resources into one (e.g. combine all custom CSS files into one)

NOTE: Performance fine-tuning and debugging performance issues fall outside of the scope for support. See Progress Sitefinity, Scope of Support

    Caching must be turned on as a prerequisite to further optimize performance. If caching is turned off the load speed on frontend facing pages of the site will be slow. Refer to the below optimization tips only if caching is turned on for the pages in the site.

    General performance optimization

    If Sitefinity takes too long to generate pages, check the following articles for performance optimization:

    If the Sitefinity App Pool process consumes a lot of CPU: Ways to keep the page in the cache: General performance practices: Issues with a slow startup: Use the Site Warmup service to preload some pages (available for Sitefinity 10.1 and up): Precompile the pages in the site: For Sitefinity projects hosted in the Cloud( e.g. Azure):
    • The Tier Plan can have a great impact on performance, as the lowest-Tiered Plans provide limited hardware resources
    • The web application, database, and Redis should be in the same data center (geographic region)


    Check if the Data Caching is enabled. Go to Administration > Settings > Advanced > DataEnable data caching should be empty, so it gets the default value (True).

    For more information, see Sitefinity documentation, Cache Settings 

    Use Load Balancing

    Websites that have to handle a large number of requests should be hosted in a load-balanced environment with at least 2 instances. This will guarantee not only very high availability for the website, but also allow to execute procedures on the website without affecting its availability. One can, for instance, remove one of the instances from the load balancing, perform some maintenance operation and put it back online, while the other node handles all the requests during the maintenance.

    This setup will also allow to warm-up the instance before letting it handle requests, and hide the waiting for that initial load.

    Deployment of a new version of the website should always detach the instances from the load balancer one by one, perform the upgrade, warm them up and even then put them back on. In this way, the website will provide a nice, consistent experience for the end users.

    For more information, see Sitefinity Documentation, Load balancing

    Static resources take some time to load: consider using a CDN

    Customers who want optimal performance often rely on third-party Content Delivery Networks (CDN) so that static files such as images, style sheets or JavaScript pages are loaded as fast as possible for their end-users.

    To configure Sitefinity to use a CDN, see Sitefinity documentation, CDN storage for content libraries

    Faster system restart

    For more information, see Progress Article, Sitefinity startup performance.

    Speedup the Local development

    For various tips, check Sitefinity Blog Posts, Sitefinity 10.1 Cuts Web Site Startup Time in Half

    Other tips:
    • Use SSD disk or RAM disk when possible. 
    • Remove the unnecessary assembly references, keep only the ones needed and used, e.g. in case of using NuGet packages
    • Disable any modules that are not needed in the current project (e.g. connectors, content modules, etc.)
    • Use the Roslyn compiler. See NuGet Packages Microsoft.CodeDom.Providers.DotNetCompilerPlatform

    Usage of the Diagnostics module

    If Diagnostics module is active, deactivate it by navigating to Administration > Modules & Services > Action (of Diagnostics module) > Deactivate

    For more information, see Sitefinity Documentation, Performance Diagnostics module


    Host the site with IIS web server. Running the sites through local development servers (IIS Express) does not count as a benchmark for speed because the web server is for development purposes and does not have the full IIS Performance boosters.

    Make sure the websites are not running debug mode. In web.config check the debug is set to false
    <compilation debug="false"

    Another part of the bootstrap process is the code added in Global.asax on Application_Start event and Boostrapper_Initialized events. If there is a slow executing code or code that works through a large collection of data this will impact the startup.

    If the site warmup module is configured based on this Sitefinity Documentation, site warmup it will slow down the site startup in order to preload certain pages. Check if it is configured and how many pages it preloads.

    Slow load for pages or a certain page

    Slow compilation time. If the page has a lot of widgets that query data, this load of data from the page and from its page template needs to be executed once so that the page compiles and outputs HTML, this is the slowest process of the page request. Once compiled all will be faster. The compilation can be speeded up via installing Roslyn compiler.

    More details about Roslyn, its installation and benefits are available in Sitefinity Blog Posts, Sitefinity 10.1 Cuts Web Site Startup Time in Half

    In case the Roslyn compiler does not improve the time to the first byte for the request to the homepage, then the page itself needs to be examined for causes of the problem.

    To do so, run a copy of the site locally, out of the production server and:
    • measure the startup time
    • remove a widget from the homepage and measure the time again. 
    • keep removing widget until the load speed improves, the last removed widget is the one causing slowdowns. 
    • if all widgets from the page are removed, but it still loads slowly go to the page template and continue the removal process to narrow down a problematic component.
    • move to the page template on which the page is based to narrow down the root or the problem to a widget on the page template.

    Temporary ASP.NET Files folder Permissions

    If the IIS Application Pool Identity does not have necessary permissions to this folder the Sitefinity Pages might be compiled on every request instead of being cached.

    Allow the IIS Application Pool Identity full permissions to the "%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" folder. 

    Firewall issues

    Check for any firewall rules that might be causing slow responses from the particular domain.
    References to Other Documentation:
    Last Modified Date8/17/2021 8:23 AM
    Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

    Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.