Someone who filters a listing or types in the search box is not window-shopping: they know what they want. They are the visitors most ready to buy, and they are exactly the ones PrestaShop makes wait the most. Every filter click, and every pause while typing in the search box, is a request to the server: PrestaShop starts, runs heavy database queries and sends the result back. And none of those answers can be cached.
This article explains what happens on each click, how much it weighs on a real shop, and how Instant Filters and Instant Search move the work somewhere else: from the server to the customer’s browser.
What happens on every click
PrestaShop’s faceted search and its search box work the same way: the browser asks the server for the result of every change. The stock search box does it every time the customer pauses while typing (a few tenths of a second), to show suggestions.
The path of a filter click or a letter in the search box
What is saved once the catalogue is already in the browser
- Click or key
- →
- Request
- →
- PrestaShop starts
- →
- Database queries
- →
- Counts and prices
- →
- Response
- Click or key
- →
- The browser searches its files
- →
- Result
With few visitors you don’t notice. With traffic, those queries compete with the ones of customers who are paying: search and filters are among the most expensive pages a shop serves, and since every combination of filters or letters is different, a page cache cannot store them.
Server requests of a single visit
Example: typing “t-shirt” in the search box, then ticking 5 filters
Illustrative example: up to 7 requests while typing (one each time the customer pauses) and 5 while filtering. With the modules, the browser downloads the static files once, and a CDN can serve them; after that it never asks the server again.
Speed is sales
This is not a technical detail. When the answer is slow, the customer leaves:
What the studies say
A filter that takes a second to answer is felt on every click. A search box that suggests nothing until the server replies looks broken. And a product the customer cannot find is a product they do not buy.
Moving where the work is done
Both modules share one idea: the shop prepares the data once, and the customer’s browser does the rest.
- PrestaShop writes static JSON files with the catalogue: what can be filtered (categories, brands, features, attributes, price, stock) and what can be searched (name, references, brand, categories, tags, descriptions…). There is one set per language, currency and customer group, so prices are always the ones that visitor pays.
- The browser downloads them once: the search, on the first click in the box; the filters, when a listing opens. They are static files: the web server sends them without PHP, or a CDN does.
- From then on, filtering, counting, sorting, paging and searching happen in the browser, in milliseconds and without another request.
- When you change a product, its stock, a price or a category, PrestaShop’s hooks update only what changed. No cron job needed.
The listing the server prints does not change, so Google and visitors without JavaScript see it as before.
A search box that understands what customers type
Because searching happens in the browser, it can afford to be generous with what is typed: comparing thousands of words there takes milliseconds. Instant Search ignores capitals and accents, finds words while they are being typed and forgives typos: “caost t-shrit” finds “Coast T-shirt”, even with letters swapped. When no product has every word, it shows those that have the most, instead of an empty page.
And you decide where it looks and how much each place counts: name, reference and barcodes, brand, categories, features, attributes, tags and descriptions, each with a weight from 1 to 10. A “Try it” box in the back office ranks your products with the weights you are moving, before you save.
Before and after, on a 20,000-product store
Rather than guess, we set up a PrestaShop 9 store with 20,000 products on a server like many shops have: 4 cores and 8 GB of RAM, with PHP and the database on the same machine. We simulated 50 visitors at once, each doing what a customer does: open a category, tick two filters, search for “mountain fox” and open the results, with a few seconds between actions. First with PrestaShop’s stock search and filters, then with Instant Filters and Instant Search.
What changes with 50 visitors at once
| With 50 visitors at once | Without the addons | With the addons |
|---|---|---|
| Filter click | 0.20 s (1 in 10 over 0.42 s) | 0.02 s in the browser, 0.09 s on a mid-range phone. No request to the server |
| Search suggestions | 0.45 s (1 in 10 over 2.2 s) | 1 to 6 ms in the browser, 2 to 25 ms on a mid-range phone. No request to the server |
| Results page | 0.48 s (1 in 10 over 2.4 s) | 0.04 s (1 in 10 over 0.06 s) |
| Category page | 0.33 s (1 in 10 over 1.2 s) | 0.27 s (1 in 10 over 0.33 s) |
| PHP requests per second | 15.4 | 5.2 |
| Database CPU | ~300% (3 of the 4 cores) | ~32% |
| Downloads once per visit | — | 0.38 MB of filters and 0.31 MB of search, compressed |
ecom-addons measurements, November 2026: PrestaShop 9.0.2 in production mode with 20,000 products, stock search (ps_searchbar) and stock faceted search (ps_facetedsearch) against Instant Search and Instant Filters. A 4-core, 8 GB server simulated with Docker; 50 visitors pausing about 5 seconds, for 90 seconds. “Mid-range phone”: Chrome with the CPU 4 times slower. Times are medians.
What the customer waits for at each action
With 50 visitors at once on a 4-core, 8 GB server: from the typical time (median) to what the slowest 10% of visitors wait
What changes is not just the time of each click:
- Search and filters stop touching the server. Each suggestion and each filter goes from a request to PHP and the database to a few milliseconds in the customer’s browser.
- The server breathes. PHP requests drop to a third, and the database goes from using 3 of the 4 cores to a third of one. That is why even the pages that still go through PHP, like categories, get faster and steadier: without the addons, 1 in 10 took over 1.2 s; with them, 0.33 s.
- The long waits disappear. Without the addons, 1 suggestion in 10 took over 2 seconds, right when most people were searching. With the addons there is no queue, because there is no request.
Database CPU use
With 50 visitors at once, on a 4-core server (400% = all 4 cores)
With more visitors, or on shared hosting, the gap grows: without the addons the server’s work rises with every visitor who searches or filters; with them, it does not.
The texts of that test store repeat a lot, which is why they compress so well: in a catalogue with very varied texts, the files of 20,000 products can weigh up to 1.5 MB compressed. That is still about the weight of a few product photos, downloaded once per visit.
The speed trio
A fast store needs the three things a visitor does most to fly:
- The page. Page Cache serves ready-made pages to new visitors, in around half a second instead of several, with no risk to carts or prices. We told the story in this article.
- The filters. Instant Filters filters, counts and sorts in the browser, without a request per click.
- The search. Instant Search answers at every key, typos included, without querying the database.
All three run on PrestaShop 8.2 and 9.0, with any theme and without touching the server. And all three do the same thing for your server: they take away work that does not need to be repeated for every visitor.
Want it all in one place? Speed up PrestaShop brings together the page cache, the filters, the search and the checkout, with what we measured and where to start.
Sources
- Deloitte Digital and Google, Milliseconds Make Millions (2020).
- Portent, Site Speed is (Still) Impacting Your Conversion Rate (2022).
- Think with Google, page load time statistics.
- ecom-addons measurements with a test catalogue of 20,000 products (November 2026).