Where a search spends its milliseconds

In short

• The useful budget for a search that answers as you type is the 100 ms a person reads as an immediate response, and the server can only spend part of it.
• In a production measurement, the server side median came in at 24 ms, and the search engine was less than a third of that.
• What makes the difference isn't a cache: it's not doing unnecessary work on every keystroke.
• A results cache pays off less than people think, because a store's searches have a long tail and stock changes.
• The time the visitor feels includes the network and the drawing in the browser, and that part is lost faster than it can be won back on the server.

Promising "instant search" is easy, and we promise it too. What matters is the budget behind the promise: how many milliseconds there are, what they're spent on, and what you decide not to do so as not to spend them. This article is that accounting, without the marketing.

The budget isn't a choice of ours. It comes from a limit known since 1993, when Jakob Nielsen set out the three response time limits: 0.1 seconds is the limit for a person to feel that the system is reacting instantly. A search that answers as you type has to fit in there, and the server isn't the only guest at the table: the network and the drawing in the browser want their share too.

What we measured, and under what conditions

The numbers that follow aren't from a synthetic test. They were taken from a production server on 9 August 2026, with 84 search requests to a PrestaShop store of ours, and they come from the Server-Timing header that the service sends on every request, with no gatekeeping.

Before reading them, three caveats that change the interpretation:

• The catalogue was small, with 19 products. The search engine's share is the one that grows most with the size of the index; the others barely move.
• The server was under no load, with a load average below 0.2 across four cores. These numbers are a floor, not a promise at peak hour.
• The marks measure wall time for each operation, and many of them run in parallel on purpose. That's why the sum of the slices is larger than the total, and it reads like this: a big slice tells you how long that was waited on, not how much it delayed the response.

The path from a keystroke to the answer

Every key typed in the box fires the same route:

1. The layer in the store waits a short moment so as not to send one request per letter, and gathers up whatever was typed in the meantime.
2. The request reaches our service, which identifies the store by its public key and picks the right index (store, language and currency).
3. The query is prepared: text normalisation, the store's synonyms, active merchandising rules, filters already chosen.
4. The search engine answers with products, per facet counts and highlights.
5. The response is assembled with the fields that particular results layout needs, and no others.

There isn't a step here that's optional or surprising. The time is won inside each one.

Where the milliseconds go

Two rows deserve an explanation, and they're the two that surprise people.

The logging for analytics one is what usually ruins systems like this. Recording the search before answering adds a write to the critical path, and a database having a bad minute becomes a search having a bad minute for everyone. Those 2.5 ms exist, they're real, and the visitor doesn't pay for them: the write leaves after the response has gone. It's the clearest example of that caveat about parallel slices.

The second attempt one is the share most people don't expect to find. When the first search was going to end in little or nothing, another one runs, more tolerant, so as not to hand an empty screen to someone who mistyped a letter. It costs almost as much as the main search, and it's money well spent: the no results screen is expensive in another way.

Notice what the table doesn't show: no step dominates. There's no bottleneck to attack, and that's why the only way down from here is to remove work, not to optimise one spot.

Pros and cons of a results cache

The question always comes up: why not store the most requested answers? We store some things, but not search results, and the reasoning is worth explaining.

The third row of the left column is the most dangerous, because a cache improves the averages without improving the experience of whoever typed something rare, which is exactly the person who most needs a good search.

What we do instead is keep in memory what changes little (store configuration, synonyms, rules) and not repeat work per request. The gain is similar and there's nothing to invalidate.

What the visitor feels

Those 24 ms are our part, and they're the easiest of the three. What the person feels includes two more:

• The network. A request from a phone on a mobile network easily spends more time travelling than we spend answering. That's why the requests are small and the response carries only the product card's fields. On the store's side there's no work to add: the PrestaShop module injects a single script tag and the processing happens outside the store's server.
• The drawing in the browser. A grid with large images can spend more time composing than everything else put together. Images with declared dimensions and deferred loading are worth more than any optimisation of ours on the server side.

That's why the only measurement we respect is the one that includes all three parts. A pretty server median with a slow store is still a slow store.

What we decided not to do

• We don't send one search request per keystroke without waiting: the short interval saves most of the requests and nobody feels it.
• We don't return the whole product. The card needs seven fields and that's what travels.
• We don't write analytics on the critical path.
• We don't cache results, for the reasons above.
• We don't pre-compute facets for combinations nobody asked for.

None of these decisions is spectacular. Added up, they're the difference between a search that answers as you type and one that answers when you've finished typing.

Frequently asked questions

How long should an online store search take?

Under 100 ms from the keyboard to the screen is the reasonable target for a search that answers as you type, because that's where the answer stops feeling like waiting. In a production measurement with 84 requests, our server side median came in at 24 ms, of which less than 7 ms was the search engine. The rest of the budget belongs to the network and the browser, and that's where almost every store loses it.

Does a results cache make search faster?

It improves the averages and little else. A store's searches have a very long tail, prices and stock change during the day, and filters multiply the combinations to store. The work of invalidating the cache is usually greater than the gain.

What makes a search slow?

Indexes with too many searchable fields, facets with thousands of values, analytics writes on the response path, and responses that carry the whole product when the card only uses a handful of fields.

Does search make the store slower?

It shouldn't. The processing happens outside the store's server and the response is small. What usually weighs on the page is the drawing of the results: images without declared dimensions and without deferred loading cost more than the entire search.

Do you measure time on the server side or the visitor's side?

Both. Server time is what we can optimise directly, and it goes out on every response in the Server-Timing header, broken down by step and with no gatekeeping: anyone who wants to check this article's numbers opens the browser tools on a store with Buskara installed. The visitor's time includes the network and the drawing in the browser, and it's the only one that matches what the person feels.

Do this article's numbers apply to my catalogue?

The search engine's part, not necessarily: it was measured on a catalogue of 19 products and it's the share that grows most with the size of the index. The other shares (identifying the store, picking the index, applying rules, counting facets) depend little on the number of products and a lot on the configuration. The shape of the table holds; the first row is the one that changes.