NOTE: Performance fine-tuning and debugging performance issues fall outside of the scope for support: https://www.progress.com/support/sitefinity-scope-of-support .
Measure, measure, measure
When dealing with performance issues, it is useful to know as precisely as possible what type of performance degradation we are 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 comparison between other environments and measure 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:
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 your hosting provider.
General performance optimization
If Sitefinity takes too long to generate pages, you can check the following articles for performance optimization:
You can check if the Data Caching is enabled: under Administration > Settings > Advanced > Data, Enable data caching should be empty, so it gets the default value (True).
See Sitefinity documentation, cache settings http://docs.sitefinity.com/administration-cache-settings for further information about Sitefinity Caching
Use Load Balancing
Websites which have to handle a large amount 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. You 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.
Static resources take some time to load: consider using a CDN
Faster system restart
Please refer to the Sitefinity startup performance
Speedup the Local development
Use SSD disk or RAM disk when possible. More information
Remove the unnecessary assembly references, keep only the ones needed and used, e.g. in case of using nuget packages
Install Roslyn compilation: https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Usage of Diagnostics module
If Diagnostics module is active, deactivate it by navigating to Administration > Modules & Services > Action (of Diagnostics module) > Deactivate