The most time-consuming phase of the startup process is of a website is to dynamically precompile pages and templates. Each time a page or widget template is loaded for the first time, it needs to be compiled. The same applies when you rebuild your project and all previously compiled pages and templates are deleted, only to be compiled once more, even though you did not modify them. In such cases, you can keep the already compiled and unchanged pages and templates. You do this by adding the following setting to your web.config file:
When you enable this setting, the temporary ASP.NET files are not deleted after the project is compiled. Only modified assemblies are replaced. Since the dynamically compilated pages and widget templates are not deleted, after rebuilding the project, pages and widgets are loaded from the temporary ASP.NET files, instead of compiling them from scratch. Thus, pages are loaded much faster. For more information, see this MSDN blog on Optimizing ASP.NET compilation behavior.
When you request a page that contains a compiled widget template, the template has a cache dependency to the physical file of this same template. Thus, when you modify the related files , the compiled template is invalidated, so that the modified version is precompiled upon subsequent loading of the widget.
If you change a template of a widget, which is not loaded yet, that is, was never accessed since application start, its compiled version is not invalidated. So, be aware that next time you load this widget template, you may load a version which is not up-to-date.
This can happen even if you do not enable the optimizeCompilations setting, even though very rarely since each rebuild deletes all dynamically precompiled templates. With the setting enabled, the possibility for loading an outdated version of a template is even higher.
RECOMMENDATION: If you enable the optimizeCompilations setting, we recommend that you manually clean up the temporary ASP.NET files to ensure that all templates are up-to-date.
If you are still experiencing bad performance upon application startup, you can try diagnosing with more accuracy what the problem is, for example, custom code may be slowing down loading times. For more information, see Measure the performance of the Sitefinity startup process.
Back To Top