---
title: Improve search response time
slug: '1948'
canonical_url: https://docs.coveo.com/en/1948/
collection: searching-with-coveo
source_format: adoc
---
# Improve search response time
The search response time is the time your [search interface](https://docs.coveo.com/en/2741/) takes to provide results when a [user](https://docs.coveo.com/en/250/) sends a [query](https://docs.coveo.com/en/231/).

Some factors may imperceptibly or noticeably increase this response time.
End users, administrators, or developers can leverage Coveo features that create more complex queries, which then require more resources and therefore notably or significantly increases the search response time.
Complex queries can be legitimate and should complete successfully.

You can use this article to troubleshoot longer-than-expected search response times.
If following these recommendations doesn't improve the Coveo response time, contact [Coveo Support](https://connect.coveo.com/s/case/Case/Default).

> **Important**
>
> Search performance or load tests must be [planned with and authorized by Coveo](https://docs.coveo.com/en/2024#performance-testing).

## Assessing search response time

The [**System Performance**](https://platform.cloud.coveo.com/admin/#/orgid/organization/system-performance/) ([platform-ca](https://platform-ca.cloud.coveo.com/admin/#/orgid/organization/system-performance/) | [platform-eu](https://platform-eu.cloud.coveo.com/admin/#/orgid/organization/system-performance/) | [platform-au](https://platform-au.cloud.coveo.com/admin/#/orgid/organization/system-performance/)) page of the Coveo Administration Console displays the average response time of all your organization's query pipelines.

![Average response time widget on System Performance page | Coveo](https://docs.coveo.com/en/assets/images/build-a-search-ui/average-response-time.png)

Per-pipeline averages are available on the [**Query Pipelines**](https://platform.cloud.coveo.com/admin/#/orgid/search/pipelines/) ([platform-ca](https://platform-ca.cloud.coveo.com/admin/#/orgid/search/pipelines/) | [platform-eu](https://platform-eu.cloud.coveo.com/admin/#/orgid/search/pipelines/) | [platform-au](https://platform-au.cloud.coveo.com/admin/#/orgid/search/pipelines/)) page.

![Average response time widget on pipeline subpage | Coveo](https://docs.coveo.com/en/assets/images/build-a-search-ui/average-response-time-per-pipeline.png)

On a [Coveo JavaScript Search Framework](https://docs.coveo.com/en/187/) search page, you can see the total search response time for a query above the corresponding search results.

![Search response time highlighted in a Coveo-powered search interface](https://docs.coveo.com/en/assets/images/coveo-platform/search-optimization-response-time.png)

## Response time optimization tips

### For Coveo international users

#### Consider a multi-region deployment

The primary deployment region of all Coveo organizations is either the Eastern United States, Ireland, or Australia.
This implies that all queries made by end users must travel to that region and back.
Thus, end users who aren't located close to your primary deployment region would experience longer search request delays than end users who are.
To improve search request time for end users not located close to your primary deployment region, you'll likely want to consider [deploying over satellite regions](https://docs.coveo.com/en/2976#multi-region-deployments).

### For all Coveo users

#### Shortness

When making [natural language queries](https://docs.oracle.com/cd/E23507_01/Search.20073/ATGSearchQueryRef/html/s0202naturallanguagequeries01.html), keep them short.
Long natural language queries could take more time to process, as they may contain frequent terms matching many irrelevant items.
Moreover, since a blank space is considered as an `AND` Boolean operator by default, a query with many keywords could lead to a long response time or expected results not returned.

#### Boolean operators

If possible, when building queries with [Boolean operators](https://docs.coveo.com/en/1814#boolean-operators), use as few `OR` as possible.
A query with an `OR` operator may return a very large number of results.
Since the result ranking process duration is proportional to the number of results to rank, this operator may impact search response time negatively.

#### Wildcards

Use the [wildcard character](https://docs.coveo.com/en/1814#wildcard-operators) (`*`) only when necessary, and only in keywords queries with at least two characters before the wildcard character.
See [Wildcard constraints](https://docs.coveo.com/en/1580#wildcard-constraints) for detail.
Since the wildcard character represents one or more characters, finding all possible variations in the index takes time.
The more precise the context is around the wildcard character, fewer items match the query, and the less time it takes to return these items.

### For Coveo administrators

#### Precision

* Make your queries as precise as possible, with as few common or general terms as possible.
The less precise the query, the more time it takes to get significant results back.

* [Exact match operators](https://docs.coveo.com/en/1814#exact-match-operators) help narrowing your search, as they filter out all items that don't contain the queried expression.
However, exact match expressions are more complex to evaluate than regular keywords, since the keyword positions must be loaded to determine whether the keywords are located next to each other.

#### Simplicity

Simplify your queries as much as possible.

**Example**

The following expression creates a very complex syntax tree, which leads to many individual node (for example, `@filter=value`) evaluations.

`@filter = A OR @filter = B OR @filter = C OR @filter = D OR @filter = E OR @filter = F OR @filter = G OR @filter = H OR @filter = I OR @filter = J OR @filter = K OR @filter = L OR @filter = M OR @filter = N OR @filter = O OR @filter = P OR @filter = Q OR @filter = R`

The following construction is more efficient:

`@filter = (A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R)`

#### Comparison operators

* When searching for the value of a [Facet field](https://docs.coveo.com/en/1833#facet-and-multi-value-facet), use the Is Exactly operator (`==`).
When searching for the value of a field that isn't used to build a facet, use the Contains operator (`=`), unless you must match the exact field value.

**Example**

You have a Web source named `MyCompany` for your company's external website.
To narrow down search results to items of that source, you can use one of the following filtering expressions:

* `@source == "mycompany"`
* `@source = "mycompany"`

If you choose the first option, only results whose `source` field value is exactly `mycompany` are displayed.
If you choose the second option, all results whose `source` field value contains `mycompany` are displayed, such as content from your sources named `My Company Employee Portal` or `MyCompany Customer Database`.
Content from your `MyCompany` source is displayed as well.

You might expect the search with the Is Exactly operator to be slower since it's more restrictive and must make sure that there are no other characters before or after the queried value.
When used with a facet field, it's actually faster than a Contains operator search, because only one facet value is loaded in the search results.

> **Important**
>
> If the field isn't used to build a facet, using the Is Exactly operator when not necessary indeed makes the search process slower.

* Conversely, the Excludes operator (`<>`), which requires results to have a field value different from that queried, doesn't leverage the facet structure to speed up the query process.
Response time is therefore negatively impacted.
Use the [NOT operator](https://docs.coveo.com/en/1814#boolean-operators) to optimize your search.

**Example**

`@author NOT @author == "John Smith"` returns results faster than `@author <> "John Smith"`.

For more information, see [Comparison operators](https://docs.coveo.com/en/1814#comparison-operators).

#### Field options

* Enable the [**Facet**, **Multi-value facet**, **Sortable**, and **Free text search** options](https://docs.coveo.com/en/1833#field-options) only for fields that require them, since they can impact index performance.

* [[DisplayableInSearchResults]]Enable the **Displayable in results** option only for fields whose value you want to return along with the search results.
Applying this option to certain fields only minimizes the data to be returned by the server, but the impact on response time is minor.

* When sorting results on a custom field, enable the **Use cache for sort** option.
Keeping the field in memory improves response time.

* A field is referred to as a _computed field_ when facet code is edited to implement a calculation using this field.
When using computed fields, enable the **Use cache for computed fields** option.
Keeping the field in memory improves response time.

* [[Cardinality]]Cardinality is the number of different values a field has.
Cardinality has a great impact on nested query performance, especially with [string fields](https://docs.coveo.com/en/1833#field-type), as many values must be processed.
When using high-cardinality facets (especially string fields), enable the [**Use cache for nested queries**](#UseCacheForNestedQueries) option.

* When sorting your search results in a custom way, that is, by field instead of by relevance or date, the response time may not be optimal if the fields aren't loaded in cache.
Therefore, in the field options, enable both **Sortable** and **Use cache for sort** options.

For more information, see [Field type](https://docs.coveo.com/en/1833#field-type).

#### Facets

* The injection depth value is the number of search results that are scanned to find possible facet values.
The default value (1,000) may be too low if every item has many values for a single facet field.
You can [edit the injection depth yourself](https://docs.coveo.com/en/1852#editing-components), but you can also contact [Coveo Support](https://connect.coveo.com/s/case/Case/Default) to ensure it's adequate, as the larger the injection depth value, the slower the string-field facet.

* Some [string facet sorting options](https://docs.coveo.com/en/1852#editing-components) require more computation than others, which may lead to a longer response time.

**Example**

The **Occurrences**, **AlphaAscending**, and **AlphaDescending** options are the fastest algorithms, while **ChiSquare** takes longer.

* Avoid creating [string facets displaying many values](https://docs.coveo.com/en/1852#editing-components), as this increases facet loading time.
Default number is 5.

* If most of the indexed items have a different value for a certain string field, avoid enabling the [**Facet** option](https://docs.coveo.com/en/1833#facet-and-multi-value-facet) for this field.
Loading many values is resource-demanding, and therefore increases response time.
However, if you must have this facet in your search interface, enable the **Use cache for nested queries** option.

* When configuring range facets, enable cache usage.

For more information, see [Using facets](https://docs.coveo.com/en/1571/) and [JavaScript Search Interface Editor](https://docs.coveo.com/en/1852/).

#### Advanced field queries

* Although very powerful, advanced field query operators such as `*=` are more resource-consuming than free-text and [comparison operator](https://docs.coveo.com/en/1814#comparison-operators) queries.
See [Query syntax](https://docs.coveo.com/en/1552/) for details on these options.
Use advanced queries when necessary, and faster operators for better performances.
The [Use cache for nested queries](https://docs.coveo.com/en/1833#use-cache-for-nested-queries) option can be enabled to cache in memory all the values that occur a single time in the index, which are typically not cached.
Even if the setting is named after the nested query feature, the side effect is very beneficial to advanced field operators.

* Similarly, use wildcards judiciously when making advanced queries.
Queries that contain wildcards, when applied to the entire index content, are demanding and might lower performances.

For more information, see [Advanced field queries](https://docs.coveo.com/en/1897/).

#### Search results

* [Exclude irrelevant fields from your search results](#DisplayableInSearchResults) to improve loading time.

* [[NumberOfReturnedResults]]The number of requested results has a direct impact on query performance, as loading more items from the index takes more time.
[Keep the number of returned results as low as possible](https://docs.coveo.com/en/1852#editing-components).
Default number is 10.
The higher the number, the larger the quantity of items to return, and the slower the operation.
Also, result folding and duplicate filtering will impact performance as well.
Therefore, for folding, you should limit the number of folded results to 5 inside each top result.
By default, only the first two most relevant children are [folded](https://docs.coveo.com/en/428/).

> **Note**
>
> [Result folding](#result-folding-or-custom-filtering) and [duplicate filtering](#duplicate-filtering) are mutually exclusive.

* Ensure that you don't [load a large number of search results per page](https://docs.coveo.com/en/1852#editing-components).
The response time increases with the number of results to load on a page.
The default number is typically 10.

#### Query pipelines rules

* Keep query pipelines as simple as possible.
The more rules you configure in the query pipeline, the more time it takes to process.

* Use as few synonyms as possible in your thesaurus entries.
Synonyms of each queried term are included in the expanded query, so they can add up to make a much longer query, and therefore increase response time.
See [Thesaurus leading practices](https://docs.coveo.com/en/3405#leading-practices) for details.

* Use [query ranking expressions](https://docs.coveo.com/en/3375/) (QREs) wisely.
QREs require a significant amount of processing power, so using many QREs can slow down search performance considerably, especially when many results must be returned.
Combined use of Coveo Machine Learning (Coveo ML) [Automatic Relevance Tuning (ART)](https://docs.coveo.com/en/1013/) models can slow down the search even more, since ART models are trend-based whereas QREs are based on regular ranking values.
ART models and QREs are two resource-demanding features, and leveraging them simultaneously would result in an increased search response time.

* Use a [ranking function](https://docs.coveo.com/en/1448/) rather than many QREs with expressions that only differ by their field value.

* [Add stop words](https://docs.coveo.com/en/3406/) to your query pipeline to increase the speed at which [natural language queries](https://docs.oracle.com/cd/E23507_01/Search.20073/ATGSearchQueryRef/html/s0202naturallanguagequeries01.html) are processed.
These stop words should be extremely common words that appear in all or most indexed items.

**Examples**

`a`, `are`, `be`, `for`, `in`, `is`, `of`, `the`, `to`, `you`

For more information, see [Manage query pipelines](https://docs.coveo.com/en/1791/).

#### Nested queries

* [[UseCacheForNestedQueries]][Enable the **Use cache for nested queries** option](https://docs.coveo.com/en/1833#use-cache-for-nested-queries) for fields you use in nested queries.
This improves response time since a smaller number of values must transit between queries during evaluation.

> **Note**
>
> String fields are supported, but nested queries using them have a longer response time than nested queries leveraging numeric [field types](https://docs.coveo.com/en/1833#field-type).

* If you have a very high cardinality [string field](https://docs.coveo.com/en/1833#field-type) (1 million different values or more) on which you perform nested queries, try adding as many constraints as possible in the nested query filter.
This minimizes the number of values to be transferred from the inner query to the outer query, therefore improving response time.

* Although [nested queries](https://docs.coveo.com/en/1700/) support a very high number of nested levels, make nested queries with two levels or less whenever possible.
Complex nested queries take more time to execute, therefore impacting performance.

#### Body mapping

To see many or all available metadata in one field, don't configure a free-text searchable computed index field with all the values of all the item fields, as this could reduce performances.
Use the Coveo indexed document body feature instead (see [Add or edit a body mapping](https://docs.coveo.com/en/1847/)).
It's a property on an indexed document rather than a field, it's free-text searchable, and it's also used to create the document Quick view and provide a search result excerpt.

### For developers

#### `constantExpression` queries

[`constantExpression`](https://coveo.github.io/search-ui/classes/querybuilder.html#constantexpression) queries are conditions narrowing search results automatically on top of all user queries.

> **Leading practices**
>
> * Put the parts of query expressions that seldom change in `constantExpression` because it's cached.
> 
> * Avoid using [date/time operators](https://docs.coveo.com/en/1814#datetime-operators) (_now_, _today_, _yesterday_) in constant expressions, since the date or time they represent change regularly and they can't be cached.
> A `constantExpression` containing such an operator would require to be re-evaluated with every query.

If you have already created constant expressions, you may need to optimize them:

* Enable the [**Facet** option](https://docs.coveo.com/en/1833#facet-and-multi-value-facet) for the involved fields

* Ensure that you use the Is Exactly operator instead of the Contains operator (see [Comparison Operators](#comparison-operators))

* Ensure that your query syntax is as simple as possible (see [Simplicity](#simplicity))

* When a [`constantExpression`](https://coveo.github.io/search-ui/classes/querybuilder.html#constantexpression) contains a numeric field with a constant field value, enable the **Use cache for numeric queries** option.

**Examples**

* `@date > 2017/01/01`

* `@size > 1000`

> **Note**
>
> `ConstantExpression` queries that contain temporal references or other dynamic content can't be cached, as their values must be regularly recomputed.
> 
> For example, `@eventdate > now - 30d`.

#### Query expression filters

Optimize your query expression filters for performance.

**Example**

`NOT @type=="Bridges Customer Individual" NOT @type=="Bridges Customer Organization"`

In this example, the filter will be optimal _only_ if the `type` field is a facet field.
Otherwise, phrase execution will severely impact performance.

#### `$some` query extension

Use the [`$some`](https://docs.coveo.com/en/1462#some) query extension to optimize your [natural language queries](https://docs.oracle.com/cd/E23507_01/Search.20073/ATGSearchQueryRef/html/s0202naturallanguagequeries01.html).
This expression lets the index choose the best terms (that is, least common in the index) before executing the query, and requires the items to return only match a fraction of these best terms.

This query extension is especially useful to isolate relevant words in a long string.
By filtering irrelevant terms and querying only the most precise terms of a natural language query, you increase your search performance.

> **Notes**
>
> * The `best` and the `match` parameters values can be either absolute or percentage values.
> 
> * Items containing more than the number of keywords required by the `match` parameter are ranked higher than items containing the exact specified number.

**Example**

In a customer support context, one could use the `$some` query extension to find similar support cases without having to read the case description and manually select the words to query.
Pasting the entire case description in the `$some` extension may therefore be more efficient or return better results than a composing regular natural language query.

`$some(keywords: this is a simple test to show how to use the extension, best:4, match:50%)`

The `best` parameter dictates that four terms need to be kept among the rarest ones.
Then, items to return should match at least 50% of these four terms, meaning that two terms are required.
So `best` could choose to keep `simple`, `test`, `demonstrate` and `extension`, and items need to match two out of these four terms.
Of course, items matching all four terms score higher, as per regular ranking rules.

#### `$valueOfField` string

Use the [`$valueOfField`](https://docs.coveo.com/en/1462#valuesoffield) string wisely.
Using this string (often in Salesforce Insight Boxes) executes just as many queries when changing contexts (for example, switching between cases) because all `$valueOfField` strings reload at the same time, therefore increasing the response time.

#### Duplicate filtering

This feature filters out duplicates of items that are at least 85% similar to the original.

> **Note**
>
> Duplicate filtering and [result folding](#result-folding-or-custom-filtering) are mutually exclusive.

The [duplicate filtering](https://coveo.github.io/search-ui/components/tab.html#options.enableduplicatefiltering) feature increases response time, especially when applied to many search results.
When using this feature, keep the [number of returned results](#NumberOfReturnedResults) as low as possible.

#### Result folding (or custom filtering)

Result folding groups results based on the value of a field.

> **Note**
>
> Result folding and [duplicate filtering](#duplicate-filtering) are mutually exclusive.

* The result [folding](https://coveo.github.io/search-ui/components/folding.html) feature increases response time, especially when applied to many search results.
When using this feature, keep the [number of returned results](#NumberOfReturnedResults) as low as possible.

* Also keep the number of child items load per parent item (`range` option) to a minimum, since the parent and child results add up quickly, therefore leading to a increased response time.

**Example**

Your search result page loads 10 parent results per page, and you set the `range` option to 20 child item.
Your search result page could therefore load up to 210 results per page, that is, 10 parent results plus up to 20 child results underneath each parent.

* For an optimal response time, the field based on which results are grouped must contain single word values.
If not, the filter is much longer to execute, as phrases must be evaluated.

#### Queries per user

Avoid building a search interface that issues more than one search query per actual user search.
One user query should execute only one search call to the index, as additional queries would be more demanding and increase response time.

## What's next

If your response time issues seem to persist, contact [Coveo Support](https://connect.coveo.com/s/case/Case/Default) for help and further investigation.