The goal is to become proactive rather than reactive when dealing with website performance issues. Below are some suggestions; there could be other solutions that resolve performance issues as well.
## Common server-side issues
The most common server side issues are database bottlenecks. Customizations made that load a large amount of data from a table can slow performance significantly.
A typical database mistake is to obtain a repository **.GetTable()** queriable and then chain **.ToList()** before filtering the results with **.Where**. This results in the entire table being read into memory, rather than filtering results at the database level. When there are performance problems, you should review all custom database access code and look for queries that might be loading too much data or doing so frequently.
**SQL Profiler** – If a database problem can't be located, run SQL Profiler on the database to examine the activity for large queries.
**CPU Profiler** – a CPU profiler is also useful for finding SQL slowness or other performance hotspots. In this case you must run the site locally and load a page (or rest api call) while tracing with the profiler and examine the places where the most time is being spent executing code. Visual Studio includes a profiler but we recommend using Ants Performance Profiler or Jetbrains DotTrace.
## Client-side considerations
Using the Google Chrome browser tools (ctrl-shift-i) is a useful way to track down front-end performance issues. In particular, the **Time** column on the **Network** tab, shows the time for each resource or API call to be returned. Sorting by **Time** will show the slowest items first. Filtering to **XHR** will show just the REST API and template calls that are happening. The **Waterfall** column is useful for seeing what resource are blocking others. Etag caching should be visible in the browser tool when the items have Size listed as **(from disk cache)**.
You can export the browser tools network data on page by right clicking in the list area and selecting **Save as HAR with Content**. The HAR file can subsequently be viewed with a tool such as <https://toolbox.googleapps.com/apps/har_analyzer/> or it can be submitted to the Insite Support team as a part of a ticket.
Web fonts can have a large affect on client performance. It is strongly recommended to remove any unused fonts and optimize those that are in use. The following is a good article on optimizing web fonts:
Keep image files as small as possible.
The left navigation on the **Product List** page can cause browser slowness if hundreds of attributes are rendered, which can happen when the **Search_FilterOnSearch** Application Setting is set to **True** so that searches combine attributes from many categories. It may be a good idea to limit the number of attribute types which are displayed by reducing the **Search_MaximumFacets** Application Setting to a lower number than the default of 1000.
## Monitor performance
There are many excellent and inexpensive third-party site monitoring services. It is highly recommended to choose one to monitor site performance and receive alerts if the speed drops below a certain threshold. Here are a couple of examples:
It is also possible to watch server side performance in the IIS logs, but this does not provide a holistic view of page performance.
[Time taken and logparser for website statistics](🔗)