Create a search view that doesn’t load entities from the database

By default, a view that is created by the Search API, loads all the entities/items (nodes, terms, etc.) that are contained in the result set from the database to display them: either as fields or entities rendered with a view mode. This is often the desired behavior, and can’t be avoided in other cases.

However, if you are using a dedicated search backend such as Solr, those are already able to return field values in the result. Therefore, you can use Solr's field values directly and avoid any entity loads from the database.

Caching considerations

Caching via, for example, Redis for improving performance may be a better strategy than using Solr as a sort of makeshift cache, since the entity loads may impact performance only slightly. Anecdotally, the Search API was actually faster in a benchmark between Search API and Search API Solr, and there may not be much performance difference between them. Choose whichever solution you like better, and only start looking at the performance if you experience bottle necks. If in doubt whether to use Solr for makeshift caching, see When to consider other backends, such as Solr or Elasticsearch.

Requirements for not loading entities

By default, many configuration options result in entity loads from the database in your view. Take care to change all of them and, if necessary, check for other configuration added by other modules.

• Search API version: use 8.x-1.12 or higher. 
• Search API server configuration: Enable “Retrieve result data from Solr”.
• Search Index fields: Ensure that all the fields that you want to use in the search view are added to the search index. 
• Views configuration
  • Query settings: Enable “Skip item access checks. (Caution: This is a security risk! When doing this, make sure the rest of your search is configured in a way that will still prevent items with restricted access from being displayed to unauthorized users!)
  • Format: The view needs to show  “Fields”.
  • Fields: Ensure that all fields are actually indexed by Solr, so that it is able to return them. The simplest way is to only add fields that have “(indexed field)” appended to their names.
  • Field configuration: Disable “Link this field to its item” and “Use entity field rendering” (where available).
  • Item language: Do not add Item language as a field.
  • Operation links: Do not add an Operations links field (“Index [INDEX NAME]” group).

Of course, you also have to index the fields you’re using in a way that makes sense to display them. For instance, when you use the “HTML filter” processor on a field you display, the field won’t contain any HTML (which might be desired).

To keep HTML in the output, see Storing and displaying rendered HTML and #2874641: Select Text Format in Views Field for textual content with values from search index.

Testing

Finally, make sure there are in fact no entity loads.

XDebug

You can use XDebug with PhpStorm (or your favorite editor) and set a breakpoint at some point in the entity loading process. If the breakpoint is reached, this will not only tell you that the entity is still loaded but also what code triggered the entity load and, therefore, what still needs to be adapted.

Open core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php and add a breakpoint at this line:
$entities_from_cache = $this->getFromPersistentCache($ids);

Reload the View and your editor should pop up, if any entities are loaded, showing their IDs.

dsm

As an alternative, you can add a debugging statement (dsm) in the code. For this you need to install and enable the Devel module, then you edit the following file by adding a dsm, clear the cache and check the output on your web page. 

Tip: Try this out before you change the search view to see what was loaded before. It might be preferrable to view the dsm output in the preview of the Search view on its admin page, because then there won’t be any additional entity loads that could come from the menu or other blocks on the webpage.

Edit core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php around line 388 by adding the following:

protected function doLoadMultiple(?array $ids = NULL) {

if (($this->entityTypeId == 'node')) {

dsm($ids);

}

Before changing the search view, you should see a list of node IDs; afterwards the output should be empty. Example of a loaded entity:

You can also check whether the rendered entity is correctly indexed with all its HTML by adding a dsm in search_api/src/Plugin/views/field/SearchApiFieldTrait.php around line 563:

// We also don't need to load the object if all field values that depend
// on it are already present on the result row.
$required = FALSE;
foreach ($dependents as $dependent) {
dsm($row);
dsm($dependent);

CacheExclude

Even though value are being served from Solr after these steps, it may still be necessary to use a module such as CacheExclude to skip certain paths from getting cached and filling up the database.