> For the complete documentation index, see [llms.txt](https://fredhopper.gitbook.io/product-discovery/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fredhopper.gitbook.io/product-discovery/building-the-front-end-experience-with-fhr/best-practice/fredhopper-query-response-best-practices.md).

# Query Response Best Practice

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**

{% hint style="success" %}
**Optimal limit**: 24 display fields

**Acceptable limit**: 48 display fields
{% endhint %}

{% hint style="info" %}
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.
{% endhint %}

### 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**

{% hint style="success" %}
**Optimal limit**: 24 items per response

**Acceptable limit**: 48 items per response
{% endhint %}

### 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**

{% hint style="success" %}
Always suppress the `facets:url-params` response component.
{% endhint %}

{% hint style="info" %}
Suppress the following additional components if not used:

* `items:url-params`
* `campaigns:url-params`
  {% endhint %}

### 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**

{% hint style="success" %}
Do not enable prev/next links
{% endhint %}

### 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**

{% hint style="success" %}
Enable HTTP GZIP compression for query responses.
{% endhint %}

### 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**

{% hint style="success" %}
Reduce the number of item campaigns triggered for each query:

* **Optimal limit:** 1 per query
* **Acceptable limit:** 2 per query
  {% endhint %}