Search optimization and performance

Integrating FactFinder Search efficiently means not only sending queries and handling responses, but also considering performance-related features such as caching and output compression. Using these features properly can improve response times and reduce load.

Caching search results

FactFinder incorporates a search results cache designed to expedite the processing of queries that have been executed previously. Passed search parameters are examined to determine whether a query is identical to one already stored in the cache. To maximize the efficiency of the cache, it is recommended that only those parameters strictly required by FactFinder are transmitted to the search engine. By default, all parameters received by FactFinder are considered relevant for the cache. The inclusion of superfluous parameters will result in a reduction in the cache's efficiency.

Additionally, it is possible to implement caching on the shop side. For example, the shop application could cache the rendered results for a query to avoid calling FactFinder repeatedly. However, when doing so, keep in mind that the FactFinder server has its own logic for invalidating its cache. FactFinder will automatically clear or invalidate cached results when certain events occur, such as when the configuration is changed, or when the product data is updated (e.g., a feed import). The external shop system will not be aware of these internal events. This means that if the shop is caching results independently, it might serve stale data if FactFinder data or configuration has changed and the shop’s cache hasn’t been updated accordingly.

Parameters not directly used by FF itself can potentially be utilized by custom extensions, which may in turn modify the search result. For this reason, all received parameters are treated as relevant for the cache.

Output compression

For queries that result in a large volume of data (for example, queries that return many results along with extensive filtering options and navigation data), the size of the response payload from FactFinder can become quite large. This can impact network transmission time and thus the overall latency of search results.

FactFinder can compress the output data using GZIP compression, which significantly reduces the size of the data sent over the network. Most modern web servers and clients support GZIP compression for HTTP responses. On the FactFinder side, if the application server is configured for it, the search response can be sent compressed.

Depending on the programming language being used, it may also be necessary for corresponding client-side code to be implemented to support this compression method. The client must explicitly request compressed output by including the value gzip in the Accept-Encoding request header.

Suppression of blank search queries

It is observed that many visitors to web shops click the Search button without entering any text into the search field (a "blank" query). From a user experience perspective, executing a blank search is usually not desirable.

As a best practice, the integration should suppress blank search queries on the front end. Instead of sending an empty query to the search engine, the application should intercept it and prompt the user for input. For example, when the user clicks the search button with an empty search field, the website could display a message like "Please enter a search term." and set focus back to the search input. This informs the user that a query is needed and prevents sending a meaningless request to the server.

This helps to prevent the execution of blank queries, helps maintain the quality and relevance of search interactions and can contribute to a more positive user experience.