Field Set and Facet Field Performance

Field sets are groups of data fields exposed for each item when you request them through the Item Search API. Any time you see product data, such as on a Product Detail page, it’s likely you have used the Item Search API, as well as a field set that defines what data is returned. Facets are used to filter search results based on the values of the data fields. For example, all or some of your items could have colors and a shopper may want to see results for items that have a specific color.

The item data you use in your field sets and facets is highly customizable, therefore it’s important to understand how the values for those fields are derived and whether they are necessary. Typically, the more fields and the more computationally expensive those fields are, the longer it takes to return results.

Review the following information to learn about common causes of poor website performance when requesting fields, field sets, and facets through the Item Search API.

• Fields and Field Sets

• Performance Costs of Individual Fields

• Expensive Fields

• Facets

• Preventing Facets from Rendering in Search Results

Fields and Field Sets

When you make a request to the Item Search API, it’s important to be specific. Without specifying any fields or field sets, the API returns an array of objects where each item lists only the internal ID. For example, when displaying items in a list, you’ll probably want fewer item fields than when you show an individual item on a Product Detail page. While you can specify individual fields to include on each request to the API, it’s preferable to define sets of fields ahead of time so that the data model is standardized across all pages of a particular type.

Field sets are set up per domain on the Website Setup record. There are a number of defaults included with your site’s initial setup, which are usually determined by a script. However, as your site evolves, it’s normal to make modifications. Such modification includes adding new field sets or adding new fields to existing field sets.

The field sets included with your site contain different field sets for different purposes. This is to avoid unnecessary and expensive fields. However, when prototyping a new customization, it’s important that you consider each field set you use. It can be easy to rely on an existing field set for your items’ data, but unless you need the data to be exactly the same, you may want to create a new field set. While one field may not impact performance, there are other factors to consider. For example, if a response contains an unnecessary field — the time it takes to generate data for that field could be multiplied up to 100 times if, for example, you requested 100 items on a Product List page. This could be further multiplied if there are matrix child items, depending on the number of matrix combinations.

Performance Costs of Individual Fields

Each extra field you request comes with a cost, and some fields’ costs are higher than others. Fields such as Name or Description are relatively cheap as they are static. Other fields, such as those related to live stock information are quite expensive because they are dynamic. When including a field, consider whether it needs to be there and if it is worth the performance hit. You should regularly review changes made to your field sets and only include the fields that are needed.

Example

The quantityavailable field provides live stock information which is useful on Product List and Product Detail pages. It gives an idea of how much stock is available for a particular item. If an item is out of stock it lets shoppers know this before they order. If it is in stock, it lets shoppers know if stock is low and could also display a promotional banner encouraging them to order the item before it sells out. It’s an intensive field to generate data for, but it’s worth doing in this scenario. However, it would not be useful to request item data on an existing order that the shopper is reviewing in their order history. In this scenario, they would not need to know how many more they could order.

Expensive Fields

The following table lists examples of expensive fields and their intended use, and field sets that should be avoided and why. When these fields are added to a field set they occupy only one line, however they provide objects of data that can be expensive to derive.

Note:

The fields listed are examples of places where you might commonly think to use the field, but probably should avoid. This is not an extensive list. If a field is not listed, it doesn’t necessarily mean that it is not expensive.

Field	Usage	Field Sets to Avoid	Reason to Avoid
correlateditems_detail relateditems_detail	Generates a list of items and the item details associated with a particular item.	details order search typeahead	These fields work best when specifying one or a small number of items for a particular purpose. For example, a merchandising zone on a Product Detail page.
matrixchilditems_detail	Generates a list of items that have a child relationship to the specified product.	order* search typeahead	Typically, it’s not necessary to generate the details of matrix children when viewing a list of products. It can be used in the order field set, however orders with many lines can slow performance.
itemoptions_detail	Generates a list of item options (all item options and their values) for a particular item.	search*	By default, this is included in a number of field sets, including the search field set. However, depending on site performance you may want to remove it.
quantityavailable	Generates the available total of a particular item.	order	This field provides live stock status and, therefore, is not necessary since shoppers do not require this information.
quantityavailable_detail quantitybackordered_detail quantitycommitted_detail quantityonhand_detail quantityonorder_detail	Generates a breakdown of stock quantities and their status. Typically, associated with multi-location inventories.	order* search typeahead	Stock fields are expensive. If you require a Boolean value use isinstock and ispurchasable.

Fields marked with an asterisk (*) are contextual recommendations only.

Facets

As with fields and field sets, you want to avoid unnecessary facets to avoid performance issues. When adding facets, ask yourself the following questions:

• Is the filter useful? Meaning, how likely is it that a shopper will actually use it.

• How many values will the facet return?

• How many items will each of the facet values return?

A facet many unique options, such as a facet that applies to only one product, may not be particularly useful to a shopper looking to narrow down results. Also, a search that returns a large number of facets may overwhelm the shopper. A combination of both will likely overwhelm the customer and the service that provides the results.

Best Practices

• Keep facets to a maximum of 40. This is not a hard limit. However, performance degradation becomes noticeable when the maximum is reached.

• Facet values should not exceed 1,000.

• Each facet value’s name should be under 200 characters.

• Only include facets when they are necessary.

All standard parts of the site source code and configuration have these parameters set appropriately. However, keep the following in mind when performing your own searches:

• When making a request to the Item Search API, omitting include=facets from the request URL ensures that the facets are not generated and returned. This improves performance. Generally, you only need this information on Product List pages.

• If you do need facets, but you know you can exclude specific ones, then using facet.exclude in your request URL can remove that facet from the results.

Preventing Facets from Rendering in Search Results

When you want to prevent shoppers from selecting a facet to filter search results with, you can exclude the facet from rendering. To do this, use the filter set up in facets_facet_browse.tpl. Within this template is a placeholder where the Facets.FacetedNavigation child view is rendered, which has a data-exclude-facets attribute. Add the facet that you want to exclude in this attribute’s value.

For example:

              <div data-view="Facets.FacetedNavigation" data-exclude-facets="commercecategoryname,category,myfacet,myotherfacet><div> 

            

Note:

For sites using SuiteCommerce or SuiteCommerce Advanced 2021.2 or later, you can also use the defineSearchMasterOptions() method on the Environment component to dictate site-wide defaults to the Item Search API, such as preventing facets from rendering.

Related Topics

Common Causes of Site Performance Issues

Reduce Repeated Calls with Throttling and Debouncing

Troubleshoot DNS Issues with the CDN

General Notices