In-Browser filtering

The FiboFilters plugin was built to be significantly faster than the competition. This is achieved in part by eliminating client-server communication during filtering. The whole filtering process and calculating the counters takes place on the browser side. This reduces the server response time – up to 2 seconds – to zero. From the user perspective, the filtering is instant. We’re proud to have eliminated one of the main pain points for e-commerce customers.

The customer perspective

To work properly, FiboFilters needs a properly built filtering index.

Loading Descriptors on customers’ first visit

  1. On the customer’s first visit to your store, a server request is sent to download all data necessary for the filtering process (this is the only case where this action is necessary). This index we call “descriptors”.
  2. Descriptors are stored in the file:

    /wp-content/uploads/fibofilters/filters-descriptors-{$indext_build_id}.json

    For example, a descriptor for 10000 products and 10 filters can weigh around 155kB, assuming it’s gzipped. This is roughly an equivalent of a few images.
  3. Descriptors are stored in the cache storage – the customer downloads them and uses them as long as the index isn’t rebuilt. Please review for our article for more information on when the index will be rebuilt
  4. Descriptors are modified dynamically when the product data has been changed, for example, stock status or a product category. The cache will be fully refreshed only after the whole index is rebuilt. 

Filtering (after the filter state changes)

What is considered a filter state change? A filter state change occurs every time customers make a choice. For example, they select a “yellow color” T-shirt – this is considered the first change of state. Then, they also select a “yellow color” + “XL size” – the state changes again, and so on.

  1. Product ID’s matching the filtering query are calculated
  2. Information about selected filters, also known as applied filters, is displayed
  3. The filter status is refreshed and the counters are recalculated

Product rendering

  1. The HTML product templates that haven’t been displayed yet are downloaded with the AJAX request 
  2. The products are rendered
  3. Other elements, such as pagination, .woocommerce-no-products-found or .woocommerce-result-count are overwritten.

We described the product rendering process in detail in our article “Products loading and rendering”.

Key Benefits of In-Browser Filtering

  1. Many times faster filtering compared to the client-server approach
  2. High store traffic doesn’t affect filter performance.

Lifetime of JSON with descriptors

After each index rebuild, a new JSON file is created. It contains all of the descriptors. The old JSON files are stored for 2 days. Then, FiboFilters removes them automatically.

The link to the descriptors is displayed in the <head> section of the page’s HTML, so it can be cached. If the cache lasts longer than 48 hours, use the snippet below to extend the storage time of old JSON files:

add_filter( 'fibofilters/indexer/descriptors_cache/expiration_time', function () {
    return 5 * DAY_IN_SECONDS;
} );

If for any reason the JSON file with the descriptors can’t be downloaded, the descriptors will be fetched in an alternative, slightly slower way via the REST API.