Monitor and improve website performance

Become more proactive rather than reactive when dealing with website performance issues. Keep in mind, these are simply 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, it is recommended to 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 easily 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.

ISC has several layers of caching which should be utilized. The following Application and Website Settings are used to manage caching:

Cache CMS Content – Set to YES on Production sites.
Cache Etags – Set to YES. This allows caching of rest API results and other resources on the client.
Cache Category Menu – Set to YES. This ensures heavy processing associated with generating the navigation menu doesn't happen on every page load.
Category Menu Cache Refresh Minutes – Appears when the Cache Category Menu setting is enabled. This defaults to 60 and is the number of minutes to keep the category menu cache active.

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, on the far right, 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 HAR analyzer or it can be submitted to the Insite Support team as a part of a ticket.
The CSS and JavaScript must be bundled and minified, which is the default for release mode. Relatively few JavaSript and CSS downloads should show up in the browser developer tools.
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. See Optimize Webfonts
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 Show Attributes On Search Setting is set toYES 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 Maximum Attribute Facets Setting to a lower number than the default of 1000.