Fredhopper Query Response Best Practices

These are best practices to follow when configuring query responses within your FAS instance.

When configuring your integration with Fredhopper it's important to optimise the query responses to maintain performance. For each query parameter listed, there is a recommend optimal setting or limit, and if applicable an acceptable upper limit. Ignoring a recommendation won't individually cause an issue, but when combined with other recommendations being exceeded, it may lead to performance issues.

Display Fields

Configure the fields returned by locale and type of view (navigation, search, detail etc.).

The number of display fields requested for search and navigation pages should be limited to only the fields that are actually used or required by your integration.

The more fields you request, the larger the response will need to be, the more time it will take to process and retrieve the attributes for that response.

Recommendations

Optimal limit: 24 display fields

Acceptable limit: 48 display fields

Avoid requesting all-variants display fields. These are more expensive to return than regular fields as each item requires interogating all variants of an item, resulting in more requests of the data and a larger response.

View Size

The view size parameter affects the number of items returned in a single response.

It’s configured per universe/locale, but can also be specified for a single query with the fh_view_size query parameter.

The system default is 20.

Recommendations

Optimal limit: 24 items per response

Acceptable limit: 48 items per response

Supress Response Elements

You can configure Fredhopper to not return data in the query response. Doing so will result in smaller and faster responses.

This is configured using the fh_suppress parameter.

The facets:url-params component in the query response is by default included on each value of each facet. Many customers do not use it, and by suppressing this component you will get smaller and faster responses.

Recommendations

Always suppress the facets:url-params response component.

Suppress the following additional components if not used:

• items:url-params

• campaigns:url-params

Previous / Next Links

The previous and next links are disabled by default. You should avoid enabling these as the additional calculations will impact performance.

Recommendation

Do not enable prev/next links

HTTP Response Compression (front-end integration)

Our query API supports HTTP compression of the responses. We strongly advise using HTTP compression since it reduces the network traffic by factor of 10-15%.

Compression must be enabled by your front-end integrator. The query request must include an HTTP header: Accept-Encoding: gzip

Recommendation

Enable HTTP GZIP compression for query responses.

Item Campaigns

When implementing campaigns please consider the number of campaigns returned in a query.

When combined with a large number of returned items per campaign, this will impact performance.

Recommendation

Reduce the number of item campaigns triggered for each query:

• Optimal limit: 1 per query

• Acceptable limit: 2 per query