Enabling caching for search queriesfor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Enabling caching for search queries
Last updated :  
11.x , 10.x , 9.x , 8.x

The previous lesson tuned how fast content gets indexed. This one tunes something different: how fast a search query itself gets answered, especially when many visitors search for the exact same thing — a trending term, a common product name, the default "browse all" query — repeatedly within a short window.

What you'll learn in this lesson

  • Why identical search queries are ideal cache candidates
  • Configuring Search API's own results cache
  • The staleness trade-off this cache introduces

Why search queries cache well

Unlike a personalized page, a search for "wireless headphones" returns the same result set for every visitor who searches it (assuming no per-user filtering) — a genuinely cacheable, shareable computation. If that term gets searched 200 times in an hour, computing it once and serving the cached result to the other 199 is a direct, uncomplicated win.

Enabling the results cache

// Search API's own results cache plugin, configured per-index.
$index = \Drupal\search_api\Entity\Index::load('default_index');
$index->setOption('cache_settings', [
  'default' => [
    'cache_lifetime' => 3600, // 1 hour
  ],
]);
$index->save();

This caches the actual result set (which items matched, in what order) for a given query, so an identical subsequent query within the cache lifetime skips re-executing the search entirely — for a Solr or Elasticsearch backend, this can mean skipping a real network round-trip to that separate search service, not just a database query.

The staleness trade-off: a cached search result can go stale the moment matching content changes — a newly-published article that should now appear in a cached "recent articles" search won't, until the cache lifetime expires or something explicitly invalidates it. Choose cache_lifetime based on how tolerant your specific search is of showing slightly outdated results — a "search our blog archive" feature can tolerate an hour of staleness far better than a live inventory search.

Faceted search needs special care

If your search results include facets (filterable categories, price ranges, tags), each unique combination of query + active facets is effectively a different cache entry. A search UI with many facet combinations can end up with a large number of distinct cache entries, each individually valid but collectively consuming more cache storage than a simple unfaceted search would — worth monitoring, not necessarily a reason to avoid caching facets at all.

Quick check: your site has a live product search where inventory counts change frequently throughout the day. Is a 1-hour cache_lifetime a good default here? If you said no — inventory-sensitive results probably need a much shorter lifetime, or explicit invalidation on stock changes, since an hour of staleness could show out-of-stock items as available — you've understood the real trade-off this setting makes.

Key takeaways

  • Identical, non-personalized search queries are strong cache candidates — the same computation serves every visitor who runs the same search.
  • Search API's results cache skips re-executing a query (including, for Solr/Elasticsearch, a real network round-trip) within its lifetime.
  • Choose cache_lifetime based on how staleness-tolerant your specific search feature actually is — one setting doesn't fit every use case.
  • Faceted search multiplies distinct cache entries per query+facet combination — monitor cache size, don't assume it's free.

Coming up next

You've now covered indexing and query-result caching. Next, we look at the search backend itself — configuring Apache Solr specifically for genuinely faster search.