A slow Umbraco site can be challenging to solve. At BrainsmithsLabs, we've years of expertise in doing this. We allow a health check of your website, which involves a fixed cost diagnosis of performance issues - if the content here is a little too professional. 

Is it only slow in production?

If your delayed Umbraco site is excellent on your staging server or the developer PC, then this leads to issues of simultaneous user access to the site. You may prefer to read our other blog on fixing and diagnosing 100% CPU spikes to gain out about traditional issues that create performance problems with various users accessing a site:-

see the advice in that blog and attempt to upgrade Umbraco if you are running a previous version.

It may be that in your production environment latency among SQL server and Umbraco is high associated with the developer's PC and disc IO is slow. For instance, Azure web apps have a slow drive read/write related to a development PC.

An excellent written Umbraco website should operate nearly totally from memory-based content cache - some implementations may allow from custom code where the developer hasn't ultimately assumed the architecture of Umbraco and combined lots of custom SQL. 

How you benchmark SQL  disk and latency I/O depends on whether you apply VPS/dedicated servers or some cloud concept:-

but for general hosting SQL server profiler (part of management studio) will determine the inquiries that your website is running and how long-drawn they take. 

You could also install a tool like LeanSentry or NewRelic both in composition and locally to standard benchmark queries. 

People usually assume that a slow Umbraco website can be fixed with a more active server or a more robust database. Still, except your site commonly has higher than 50-60 concurrent users, this is unusually the case (you can apply live google analytics to see how various people are on your website).

It is inactive locally too!

In a way, this is great as it makes your slow Umbraco website more accessible to diagnose. 

Start by reducing custom code from the Umbraco request pipeline - associate your web.config file with one that is delivered with Umbraco to recognize what has been added. If you see new HTTP handlers or HTTP modules - try to temporarily discuss them and understand if this has an impression on performance (we've recognized issues with traditional Umbraco packages in the past).

For associating files - Beyond compare is excellent. 

The next test that we would accomplish would be to empty the Umbraco templates and execute the site without any CSS or HTML at all. It is comparatively easy to write a script to blank out templates and next restore them. 

If you've been within the steps above and you yet have a slow Umbraco site, then you'll mostly indeed discover that your website is quick now.

Slowly re-introduce functionality into your template and recognize when the site slows. When you know the element of the page that causes a problem - inspect and refactor the code.

As a fast and temporary fix, you could admit Macro caching, Umbraco’s Html.CachedPartial directive. 

You could also view at MVC output caching and doughnut caching - though those could have knock-on effects for your website and you should be fully versed in the intricacies and nuances. 

Common mistakes

We discuss some common patterns in custom code combined to Umbraco - which end up creating performance problems: 

• Extreme Linq: Loading massive sets of data into memory and filtering isn't an excellent idea - and also doesn't scale - what was quick with little or no content, can slow down. 

• Immoderate Log4Net logging: There is lots of good material on the internet about when and how logging should be used. 

• The difference in lock and sleep: If your codebase includes Thread. Rest and the locking of objects - you should be fully confident that you understand why you are preparing it and that it is important. In most standard website scenarios, lock and sleep can be refactored. 

• Joining Examine and other data: Lucene is not a relational database and shouldn't be adopted as such - if you have code that queries Check and then filters by Linq and combines data to the results from other sources, you likely need to rebuilt the functionality. 

• Querying the Umbraco database to recover content: This is the number one Umbraco cardinal sin - Umbraco content should be obtained from the Umbraco memory cache, applying the Umbraco API.