Limiting indexed fields for performancefor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Limiting indexed fields for performance
Last updated :  
11.x , 10.x , 9.x , 8.x

Every field you add to a search index makes that index bigger, slower to build, and slower to query — even fields nobody ever actually searches by. It's tempting to index "everything, just in case" when setting up a Search API index for the first time; this lesson is about resisting that instinct and indexing deliberately.

What you'll learn in this lesson

  • Why every indexed field has a real, ongoing cost
  • Auditing which fields your search UI actually queries or displays
  • The difference between indexed and stored fields, and why it matters

The cost of an unused indexed field

Each field you add to an index configuration (/admin/config/search/search-api/index/{index}/fields) increases the size of every single index entry, the time it takes to index each item, and — for full-text fields specifically — the size of the inverted index structures covered in the Solr lesson. A field indexed but never actually used in any search query or facet is pure overhead with zero corresponding benefit.

Auditing what's actually used

// Check what your search view/page actually filters or sorts on —
// those are the fields that genuinely need to be indexed. Everything
// else on the index configuration screen is a candidate to remove.
$index = \Drupal\search_api\Entity\Index::load('default_index');
foreach ($index->getFields() as $field_id => $field) {
  // Cross-reference $field_id against your actual Views search
  // exposed filters, sort criteria, and displayed result fields.
}

A practical audit: open your search results View's configuration and list every field it actually filters, sorts, or displays. Anything on the index that isn't in that list is a genuine candidate for removal — it was likely added "just in case" when the index was first set up and never revisited.

Indexed vs. stored — a distinction worth understanding before trimming. An indexed field is searchable/filterable/sortable but costs the most. A stored field's value is retrievable directly from the index (useful for displaying a result without a separate database load per result) but doesn't need to be full-text indexed if nobody searches by it. Some fields genuinely need both; many only need one or the other — check both settings independently rather than treating "indexed" as an all-or-nothing switch.

Quick check: a field is currently both indexed and stored, but your search View only ever displays its value in results — never filters or sorts by it. What's the safe trim? If you said keep it stored, remove the indexed/full-text setting, you've correctly separated the two costs this lesson distinguishes.

Key takeaways

  • Every indexed field adds real cost to index size, indexing time, and query time — "just in case" indexing has a genuine ongoing price.
  • Audit your actual search UI's filters, sorts, and displayed fields to find which index fields are genuinely used versus vestigial.
  • Indexed and stored are separate settings with separate costs and purposes — trim each independently based on actual use.
  • Revisit index field configuration periodically, especially after a search UI redesign that may have stopped using fields still configured on the index.

Coming up next

You've now covered the complete search-performance toolkit — indexing, query caching, backend choice, and field discipline. Next, we turn to a different kind of query entirely: optimizing REST and JSON:API responses for headless and API-driven Drupal.