Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Improve website performance

Describes suggestions to correct common issues in Optimizely Configured Commerce that impact the speed or responsiveness of websites and how to monitor and debug using Google Chrome or other tools.

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 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. The following is a good article on optimizing web fonts:

    Webfont optimization

  • 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.