1. Commerce
  2. System Management
  3. Site Performance
  4. Common Causes of Site Performance Issues

Common Causes of Site Performance Issues

The following sections describe common issues that can adversely affect the performance of your Commerce website. Review the following information to learn how to identify and resolve common causes of poor website performance.

Content Delivery Network (CDN)

You can optimize your website and decrease page-loading time by caching data and site assets on the content delivery network (CDN) available with Commerce websites. A CDN replicates and stores (caches) files from an origin server (for example, NetSuite) and makes them available around the world. The main benefit of a CDN is that it makes server response times faster. CDNs improve performance because they are:

  • More likely to be geographically closer to the user than the origin server (lower latency)

  • Less likely to be as busy as the origin servers (load-balanced)

  • Set up to store and serve copies of files and data that have already been generated (significantly lower computational costs)

If you do not use a CDN, you could experience bottlenecks. Bottlenecks occur when numerous users try to access NetSuite application resources simultaneously. Without a CDN, all users attempt to access a single, central resource rather than many distributed resources.

If you do use a CDN and your site experiences performance issues, check for issues like these:

  • If a particular node is down, your users could be routed to a server that is further away than normal.

  • An issue commonly referred to as cache misses, which means that the CDN does not have a copy of a requested resource.

    • When a copy is not available, resource requests are sent directly to the application and this can be time-consuming.

    • If you have recently cleared your site’s cache or added several new items or features to your site, cache misses will occur until a copy of all resources can be generated by the application and stored on the CDN.

    • Cache misses can also occur when cached resources are out of date. Cached resources are only stored for a set period of time.

  • Another common cause of slow site performance is Domain Name System (DNS) issues. To learn more about DNS issues and how to resolve them, see Troubleshoot DNS Issues with the CDN.

Test if the CDN is Working

The most common cause of site performance issues is that the CDN is not working at all. When you initially set up a site, it is customary to deactivate caching because of frequent updates to the site and wanting to avoid old files being served or needing to constantly invalidate the cache. So it’s easy to forget to reactivate caching when the site goes live. To check whether you’ve enabled the CDN, see Enable CDN Caching for instructions.

If CDN caching is enabled but still appears to be malfunctioning, you can test it using these command-line tools:

  • dig on Unix systems

  • nslookup on Windows sytems

This example shows how to run dig:

              dig IN A www.example.com

This example shows how to run nslookup:

              nslookup -class=IN -querytype=A www.example.com
Note:

When testing, make sure you are looking up the correct domain for your website. For example, example.com and www.example.com are completely different domains, and only one can be used for your Commerce website.

When you run one of these commands, you should see your site’s domain resolve to the CDN provider, for example, Akamai:

              ;QUESTION
webstore.example.com. IN A 
;ANSWER 
webstore.example.com. 14399 IN CNAME webstore.example.com.hosting.netsuite.com. 
webstore.example.com.hosting.netsuite.com. 299 IN CNAME webstore.example.com.e87389.ctstdrv1234567.hosting.netsuite.com.edgekey.net. 
webstore.example.com.e87389.ctstdrv1234567.hosting.netsuite.com.edgekey.net. 21599 IN CNAME e35026.x.akamaiedge.net. e35026.x.akamaiedge.net. 19 IN A 2.22.31.144

If the CDN is not enabled, the A record resolves straight to a NetSuite server IP address:

              ;QUESTION 
webstore.example.com. IN A
;ANSWER 
webstore.example.com. 299 IN A 212.25.248.17

SEO Page Generator and Time To First Byte (TTFB)

Part of the architecture behind your site’s frontend is the SEO page generator. One of its primary uses is to generate static, fully-rendered versions of your site’s pages so they can be crawled by search engines that may not be able to process JavaScript on the fly.

Time to First Byte (TTFB) is a performance metric that measures the delta between the time a browser requests content and when it starts to receive it. In simple terms, the web browser goes through the following process:

  1. Looks up domains using DNS

  2. Makes a TCP connection

  3. Negotiates security via TLS/SSL

  4. Sends a request for content

  5. Waits for content (while timing TTFB)

  6. Begins receiving content

You can use your browser’s developer tools to measure TTFB, as shown in the following example:

Shows how TTFB is measured in a browser's developer tools.

Refer to your browser’s developer tool documentation for detailed instructions about how to troubleshoot TTFB performance problems.

You can also use the SEO page generator when troubleshooting TTFB performance issues. Using its comprehensive logging feature, you can break big requests for resources down into smaller ones, which can provide greater detail than the browser tools offer. For more information, see SEO Page Generator Debug Log.

If you use the SEO page generator’s debug log, look for the following types of entries:

If any of these entries are present in the log, they can help you determine where to look for performance problems.

Image Optimization

Images are often the single biggest contributor to page size and performance. Several methods are available to optimize images, including increasing their compression to reduce each image’s size and reducing the number of images on a page. For more information, see Manage and Maintain Images.

Page Rendering

Page rendering performance refers to a different kind of performance—perceived performance. If you improve a page’s perceived performance, you give users the impression that the page is loaded and ready to use. Often the perception of good performance is just as important as the actual, measured performance.

Several tools are available for testing perceived performance. These tools take screen shots at set intervals (for example, every 100 ms) to create a film strip that you can review to determine the amount of time required to achieve a meaningful paint. Check your web browser’s developer tools for more information, or use a service such as WebPageTest.

Some common causes of perceived performance issues are:

  • Custom fonts

  • Slow, blocking (synchronous) requests

  • Calls to third-party scripts

Be cautious when implementing tracking tags for analytics or ads. Tracking tags can have a significant impact on perceived performance, particularly if they have not been properly implemented. Google Tag Manager can help ensure tracking tags are properly implemented and maintained. For more information, see Google Tag Manager.

To test the performance impact of tracking tags, you can use your browser’s developer tools to block requests to specific domains. For example, in Chrome, you can right-click on a particular request in the Network tab and choose Block request domain — after a refresh, all attempts to reach that domain are automatically prevented. If your site loads particularly quickly after this, you may have identified an issue.

Item Search API

Almost all item data on your site is requested through the Item Search API. When a query is made, the NetSuite search service goes through your site’s index, finds which items should be returned, and then performs a database query to return those items. There is a performance cost when the query is processed and the data returned.

If you suspect there could be performance issues with the Item Search API, you can get the request URL (for example, in the Network tab of your browser’s developer tools) and then attach ssdebug=T as a parameter to the end of the URL. This parameter produces additional JSON data at the bottom of the request such as:

  • searchrequest – provides an abstraction of the request that was processed

  • sessioninfo – provides information about your site

  • perftiming – provides details about how quickly the response was generated

The following example shows how this additional data is displayed:

Shows the additional JSON data produced by the debug parameter.

In the preceding example, you can see the perftiming:sqltiming value is 2314, which means the SQL query to the database took 2.314 seconds to complete. Determining whether you should be concerned with the value for this field can be tricky. But if the value is significantly higher than the one in this example and is causing noticeable performance problems, you may need to consider making changes to the queries you are submitting.

If your searches are taking too long, the most common cause is requesting too much data. Every field of data in a response comes with a cost, and so you should keep your fields and field sets to the minimum required.

When working with field sets you should consider:

  • Where you are using them – Avoid reusing field sets instead of creating new ones for particular use cases. When you use an existing field set for a unique use case, you increase the likelihood of requesting more data than is necessary. Unfortunately, this can cause slowness.

  • How you are using them – Avoid creating fields when a system-generated field is available. For example, the isinstock field is lightweight and is set up to return a boolean value and so there’s no need to create your own field to show whether items are in stock. Also, be sure to use default field sets.

    Default field sets are designed to cover several use cases and so should be trimmed down for your own site. For example, if you use the default search field set for product list pages, follow best practices and carefully choose the fields to retain. Do not add more fields, but use more suitable fields, if necessary. Remember that search results and commerce category pages cause the API to retrieve a lot of data for each item, and the more items per page, the greater the performance cost.

For more information, see Field Set and Facet Field Performance.

Commerce Categories

Generating category data can be resource-intensive so plan your commerce categories with performance in mind by following these guidelines:

  • Use current Commerce Categories functionality; do not use legacy SiteBuilder categories

  • Do not go deeper than three levels in your taxonomy

  • Try to assign each product to only one category

A common misconception about categories is that the more you have, the better. But, ideally, you want the exact opposite. Categories should be neatly organized and easy to navigate. If your shoppers repeatedly notice the same products appearing in your site’s various categories, they may become frustrated and shop elsewhere. Categories are meant to segment your catalog and repetition undermines the segmentation.

For more information, see Commerce Categories.

Scriptable Cart

Scriptable cart scripts run on both Commerce websites and back office sales transactions, and are frequently used to perform additional actions or connect to third-party services. These actions are often blocking, which means the application must wait for the script to complete before an operation can continue. If the application is waiting, that means your users are also waiting.

You may experience performance issues associated with Scriptable Cart. For example, if your script listens for changes to line items in an order, you may notice performance issues when adding items to the cart. Performance issues with the checkout wizard are not uncommon because of Scriptable Cart.

If you notice a performance issue, you can go to Customization > Scripting > Scripted Records > Sales Order to review all scripts that are running.

In some cases, Scriptable Cart causes performance issues when a script is running on the website and it only needs to run in the back office context. If one of your scripts should only be running in the back office context, you can go to its deployment record and toggle the All Roles and All Employees checkboxes:

  • If you check All Roles and uncheck All Employees, the script runs in the website.

  • If you uncheck All Roles and check All Employees, the script runs only in the backend.

Note:

This is a temporary workaround. Long-term, you need to refine your script to run more efficiently.

User Event Scripts

If you notice performance issues while placing an order, you may need to examine your user event scripts and consider changing some of their settings.

  • There’s an option called Execute in Commerce Context on a script’s deployment record and this option determines whether the script runs on websites — if you toggle this off and things improve, then this is likely where your problems lie.

  • There’s also a feature you can enable called Asynchronous afterSubmit Sales Order Processing that may help improve performance if your script listens for the afterSubmit event. When this feature is enabled, afterSubmit user events are triggered asynchronously when a sales order is created during checkout, meaning the events run in the background. When an afterSubmit user event runs in asynchronous mode, the next page is loaded during the period of time the afterSubmit user event is still processing.

Shopping Environment Short Cache

When unnecessary pages, such as blog posts, are loaded into the shopping environment short cache for your Commerce website, load time increases for all pages in your shopping environment.

The CMS Pages Lazy Load setting lets you control which CMS page settings are loaded into the shopping environment short cache for your Commerce website. You do this by specifying the Custom Script Record IDs for the records that you do not want to load in the shopping.environment.shortcache.ssp file.

For example, if you create blog posts using the SuiteCommerce Blog extension, you can prevent your blog pages from loading into the shopping environment short cache by entering the Custom Script Record ID customrecord_sc_blogpage_type_post in the CMS Pages Lazy Load field. This will ensure that the blog post pages are loaded into the short cache only when those pages are requested.

To configure the CMS Pages Lazy Load setting:

  1. Go to Commerce > Websites > Configuration.

  2. Select your website and domain and click Configure.

  3. Go to the Integrations tab and the Site Management Tools subtab.

  4. In the CMS Pages Lazy Load field, enter the Custom Script Record IDs for the records you do not want to load in the shopping environment short cache.

  5. Click Save.

For more information, see CMS Pages Lazy Load.

Related Topics

Reduce Repeated Calls with Throttling and Debouncing
Field Set and Facet Field Performance
Troubleshoot DNS Issues with the CDN

General Notices