Search optimization and performance

Improve search performance with caching, compression, and better handling of blank search requests.

Efficient FactFinder Search integration is about more than sending queries and handling responses. It also includes performance features such as caching and output compression. Used well, these features improve response times and reduce load.

Caching search results

FactFinder includes a search results cache to speed up queries that were already processed before. Submitted search parameters are checked to determine whether a query matches one already stored in the cache. To keep the cache effective, only send parameters that FactFinder actually needs. By default, every received parameter is considered relevant for caching. Extra parameters reduce cache efficiency.

You can also cache results on the shop side. For example, the shop application can cache rendered search results to avoid calling FactFinder repeatedly. If you do this, keep in mind that FactFinder invalidates its own cache when certain events occur, such as configuration changes or product data updates. The shop system does not know about these internal events automatically. That means independent shop-side caching can serve stale data unless you manage invalidation carefully.

Parameters not used directly by FactFinder itself may still be used by custom extensions and can therefore change the search result. For that reason, all received parameters are treated as relevant for the cache.

Output compression

For queries that return a large amount of data, such as many results combined with extensive filtering and navigation data, the response payload can become quite large. That increases network transfer time and can slow down the overall search experience.

FactFinder can compress the output with GZIP, which greatly reduces the amount of data sent over the network. Most modern web servers and clients support GZIP for HTTP responses. If the application server is configured for it, the search response can be sent in compressed form.

Depending on the programming language you use, the client may also need explicit support for this compression method. To request compressed output, include the value gzip in the Accept-Encoding request header.

Suppression of blank search queries

Many webshop visitors click the Search button without entering any text. From a user experience perspective, executing a blank search is usually not helpful.

As a best practice, suppress blank search queries on the front end. Instead of sending an empty query, intercept it and prompt the user for input. For example, if the user clicks search with an empty field, show a message such as "Please enter a search term." and move focus back to the search input. This makes the requirement clear and avoids a meaningless request.

This helps prevent blank queries, keeps search interactions more relevant, and improves the overall experience.