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, like on a Product Detail page, you've probably used the Item Search API and 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, so it’s important to understand how the values are determined and if they're necessary. Typically, the more fields you have, and the more complex they are, the longer it takes to get 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
When you make a request to the Item Search API, it’s important to be specific. If you don't specify any fields or field sets, the API returns an array of objects with only the internal ID for each item. For example, when showing items in a list, you’ll probably want fewer item fields than when you show a single item on a Product Detail page. While you can specify individual fields for each API request, it’s better to define field sets ahead of time so your data model is consistent across all pages of a certain type.
Field sets are set up per domain on the Website Setup record. Your site's initial setup includes some default field sets, usually set by a script. As your site grows, it's normal to add new field sets or new fields to existing ones.
Your site comes with different field sets for different purposes to avoid unnecessary or expensive fields. When you're prototyping a new customization, make sure you think about each field set you use. It might seem tempting to use an existing field set for your items' data, but unless you need the data to be exactly the same, you might want to create a new field set. While one field might not impact performance, there are other factors to consider. For example, if a response has an unnecessary field, the time to generate that data could be multiplied by 100 if you request 100 items on a Product List page. This gets even bigger if there are matrix child items, depending on how many combinations you have.
Performance Costs of Individual Fields
Each extra field you request comes with a cost, and some fields cost more than others. Fields like Name or Description are relatively cheap because they're static. Other fields, like ones for live stock information, are more expensive because they're dynamic. When adding a field, think about whether it needs to be there and if it's worth the performance hit. You should regularly check your field sets and only include the fields you really need.
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 before they order. If it's in stock, it can show if stock is low and even display a banner encouraging them to order before it sells out. It's a heavy field to generate, but it's worth it in this case. However, it wouldn't be useful to request this data for an existing order in a shopper's order history—they don't need to know how many more they could order in that case.
Expensive Fields
The following table lists examples of expensive fields and their intended use, plus field sets you should avoid and why. When you add these fields to a field set, they only take up one line, but they provide data objects that can be expensive to generate.
The fields listed are examples of places where you might think to use the field but should probably avoid. This isn't a complete list. If a field isn't listed, it doesn't mean it's not expensive.
|
Field |
Usage |
Field Sets to Avoid |
Reason to Avoid |
|---|---|---|---|
|
Generates a list of items and the item details for a particular item. |
|
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 are children of the specified product. |
|
Typically, it’s not necessary to generate the details of matrix children when viewing a list of products. You can use it in the order field set, but orders with lots of lines might slow things down. |
|
itemoptions_detail |
Generates a list of all item options and their values for a particular item. |
search* |
By default, it's part of several field sets, like the search field set. But if your site is slow, you might want to remove it. |
|
quantityavailable |
Generates the total available for a particular item. |
order |
This field shows live stock status, so it's not needed since shoppers don't need this information. |
|
Generates a breakdown of stock quantities and their status, typically for multi-location inventories. |
|
Stock fields are expensive. If you need a Boolean value, use |
Fields marked with an asterisk (*) are contextual recommendations only.
Facets
As with fields and field sets, you don't want to add unnecessary facets because they can cause performance issues. When adding facets, ask yourself the following questions:
-
Is the filter useful? In other words, will shoppers really use it?
-
How many values will the facet return?
-
How many items will each of the facet values return?
A facet with lots of unique options, like one that only applies to a single product, probably isn't that helpful for shoppers trying to narrow down results. Also, if a search returns too many facets, it can overwhelm shoppers. Having both problems could likely overwhelm both your customers and the service providing the results.
Best Practices
-
Don't go over 1200 fields total in your Field Sets, Facet Fields, and Sort Fields, or the search index rebuild will fail.
-
Try to keep facets to 40 or fewer. It's not a strict limit, but you'll notice performance drops if you go higher.
-
Facet values should not exceed 1,000.
-
Each facet value’s name should be under 200 characters.
-
Only add facets when they are necessary.
The standard site code and configuration have the correct settings, but keep these tips in mind when you're running your own searches:
-
When you make a request to the Item Search API, leaving out include=facets from the URL means facets won't be generated or returned, which helps performance. Usually, you only need facets on Product List pages.
-
If you need facets but know you can skip some, use facet.exclude in your request URL to remove those facets 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. Inside this template, there's a placeholder for the Facets.FacetedNavigation child view, which has a data-exclude-facets attribute. Add the facet you want to exclude to this attribute’s value.
For example:
<div data-view="Facets.FacetedNavigation" data-exclude-facets="commercecategoryname,category,myfacet,myotherfacet><div>
If you're using SuiteCommerce or SuiteCommerce Advanced 2021.2 or later, you can use the defineSearchMasterOptions() method on the Environment component to set site-wide defaults for the Item Search API, like stopping facets from rendering.