Wo die Millisekunden einer Suche verbraucht werden

Kurz gefasst

• Das nutzbare Budget einer Suche, die schon beim Tippen antwortet, sind die 100 ms, die ein Mensch als sofortige Antwort liest, und der Server darf davon nur einen Teil verbrauchen.
• In einer Produktionsmessung lag der Median auf der Serverseite bei 24 ms, und die Suchmaschine war weniger als ein Drittel davon.
• Was den Unterschied macht, ist kein Cache: es ist, bei jeder Taste keine unnötige Arbeit zu tun.
• Ein Ergebnis-Cache bringt weniger, als man denkt, weil die Suchen eines Shops einen langen Schwanz haben und sich der Lagerbestand ändert.
• Die Zeit, die der Besucher spürt, umfasst Netz und Zeichnen im Browser, und dieser Teil geht schneller verloren, als man auf dem Server gewinnt.

„Sofortige Suche“ zu versprechen ist leicht, und wir versprechen es auch. Interessant ist das Budget hinter dem Versprechen: wie viele Millisekunden es gibt, wofür sie verbraucht werden, und was man bewusst nicht tut, um sie nicht zu verbrauchen. Dieser Artikel ist genau diese Buchhaltung, ohne Marketing.

Das Budget ist keine Entscheidung von uns. Es kommt von einer Grenze, die seit 1993 bekannt ist, als Jakob Nielsen die drei Grenzen der Antwortzeit festhielt: 0,1 Sekunden sind die Grenze, damit eine Person spürt, dass das System sofort reagiert. Eine Suche, die schon beim Tippen antwortet, muss da hineinpassen, und der Server ist nicht der einzige Gast am Tisch: das Netz und das Zeichnen im Browser wollen auch ihren Teil.

Was wir gemessen haben, und unter welchen Bedingungen

Die folgenden Zahlen stammen nicht aus einem synthetischen Test. Sie wurden am 9. August 2026 auf einem Produktionsserver erhoben, mit 84 Suchanfragen an einen eigenen PrestaShop-Shop, und kommen aus dem Header Server-Timing, den der Dienst bei jeder Anfrage mitschickt, ohne Zugangssperre.

Bevor du sie liest, drei Vorbehalte, die die Deutung verändern:

• Der Katalog war klein, mit 19 Produkten. Der Anteil der Suchmaschine ist der, der mit der Größe des Index am stärksten wächst; die anderen bewegen sich kaum.
• Der Server war ohne Last, mit einem Load Average unter 0,2 auf vier Kernen. Diese Zahlen sind eine Untergrenze, kein Versprechen zur Stoßzeit.
• Die Messpunkte messen die Wanduhrzeit jeder Operation, und viele laufen absichtlich parallel. Deshalb ist die Summe der Anteile größer als das Ganze, und man liest es so: ein großer Anteil sagt, wie lange darauf gewartet wurde, nicht wie sehr er die Antwort verzögert hat.

Der Weg von einer Taste bis zur Antwort

Jede in das Feld getippte Taste löst denselben Ablauf aus:

1. Das Layer im Shop wartet einen kurzen Augenblick, um nicht eine Anfrage pro Buchstabe zu schicken, und fasst zusammen, was inzwischen getippt wurde.
2. Die Anfrage erreicht unseren Dienst, der den Shop über den öffentlichen Schlüssel identifiziert und den richtigen Index wählt (Shop, Sprache und Währung).
3. Die Abfrage wird vorbereitet: Normalisierung des Textes, Synonyme des Shops, aktive Merchandising-Regeln, bereits gewählte Filter.
4. Die Suchmaschine antwortet mit Produkten, Zählungen pro Facette und Hervorhebungen.
5. Die Antwort wird mit den Feldern zusammengesetzt, die diese Ergebnisdarstellung braucht, und mit keinem weiteren.

Kein Schritt hier ist optional oder überraschend. Die Zeit wird innerhalb jedes einzelnen gewonnen.

Wo die Millisekunden verbraucht werden

Zwei Zeilen verdienen eine Erklärung, und es sind die beiden, die überraschen.

Die der Aufzeichnung für Analytics ist die, die solche Systeme gewöhnlich ruiniert. Die Suche vor der Antwort zu speichern fügt dem kritischen Pfad einen Schreibvorgang hinzu, und eine Datenbank mit einer schlechten Minute wird für alle zu einer Suche mit einer schlechten Minute. Diese 2,5 ms gibt es, sie sind echt, und der Besucher zahlt sie nicht: der Schreibvorgang startet, nachdem die Antwort abgegangen ist. Es ist das klarste Beispiel für jenen Vorbehalt zu den parallelen Anteilen.

Die des zweiten Versuchs ist der Anteil, mit dem die meisten nicht rechnen. Wenn die erste Suche in wenig oder nichts geendet wäre, läuft eine zweite, tolerantere, um niemandem einen leeren Bildschirm zu liefern, der einen Buchstaben vertauscht hat. Sie kostet fast so viel wie die Hauptsuche, und das Geld ist gut angelegt: der Bildschirm ohne Ergebnisse ist auf andere Weise teuer.

Achte darauf, was die Tabelle nicht zeigt: kein Schritt dominiert. Es gibt keinen Engpass anzugreifen, und deshalb ist die einzige Art, von hier aus herunterzukommen, Arbeit wegzunehmen und nicht eine Stelle zu optimieren.

Für und Wider eines Ergebnis-Caches

Die Frage kommt immer: warum nicht die meistgefragten Antworten speichern? Wir speichern einiges, aber nicht die Suchergebnisse, und es lohnt sich, den Gedankengang zu erklären.

Die dritte Zeile der linken Spalte ist die gefährlichste, denn ein Cache verbessert die Durchschnitte, ohne die Erfahrung derer zu verbessern, die etwas Seltenes getippt haben, und genau die brauchen eine gute Suche am dringendsten.

Was wir stattdessen tun: wir halten im Speicher, was sich kaum ändert (Konfiguration des Shops, Synonyme, Regeln), und wiederholen keine Arbeit pro Anfrage. Der Gewinn ist ähnlich, und es gibt nichts zu invalidieren.

Was der Besucher spürt

Diese 24 ms sind unser Teil, und es ist der leichteste der drei. Was die Person spürt, umfasst zwei weitere:

• Das Netz. Eine Anfrage von einem Handy im Mobilfunknetz braucht leicht mehr Zeit zum Reisen als wir zum Antworten. Deshalb sind die Anfragen klein und die Antwort bringt nur die Felder der Produktkarte. Auf Seiten des Shops kommt keine Arbeit dazu: das Modul für PrestaShop fügt ein einziges Script-Tag ein, und die Verarbeitung passiert außerhalb des Shop-Servers.
• Das Zeichnen im Browser. Ein Raster mit großen Bildern kann mehr Zeit beim Aufbau verbrauchen als alles andere zusammen. Bilder mit angegebener Größe und mit verzögertem Laden bringen mehr als jede Optimierung von uns auf der Serverseite.

Deshalb ist die einzige Messung, die wir ernst nehmen, die, die alle drei Teile einschließt. Ein hübscher Server-Median mit einem langsamen Shop bleibt ein langsamer Shop.

Was wir bewusst nicht tun

• Wir schicken nicht bei jeder Taste ohne Warten eine Anfrage: das kurze Intervall spart die meisten Anfragen, und niemand spürt es.
• Wir geben nicht das ganze Produkt zurück. Die Karte braucht sieben Felder, und genau die reisen.
• Wir schreiben Analytics nicht auf dem kritischen Pfad.
• Wir legen keine Ergebnisse im Cache ab, aus den Gründen oben.
• Wir berechnen keine Facetten für Kombinationen vor, die niemand verlangt hat.

Keine dieser Entscheidungen ist spektakulär. Zusammengenommen sind sie der Unterschied zwischen einer Suche, die schon beim Tippen antwortet, und einer, die antwortet, wenn man fertig getippt hat.

Häufige Fragen

Wie lange darf eine Suche in einem Onlineshop dauern?

Unter 100 ms von der Tastatur bis zum Bildschirm ist das vernünftige Ziel für eine Suche, die schon beim Tippen antwortet, denn ab da fühlt sich die Antwort nicht mehr wie Warten an. In einer Produktionsmessung mit 84 Anfragen lag unser Median auf der Serverseite bei 24 ms, davon weniger als 7 ms für die Suchmaschine. Der Rest des Budgets gehört dem Netz und dem Browser, und dort verlieren ihn fast alle Shops.

Macht ein Ergebnis-Cache die Suche schneller?

Er verbessert die Durchschnitte und kaum mehr. Die Suchen eines Shops haben einen sehr langen Schwanz, Preise und Lagerbestand ändern sich im Lauf des Tages, und die Filter vervielfachen die zu speichernden Kombinationen. Die Arbeit, den Cache zu invalidieren, ist meist größer als der Gewinn.

Was macht eine Suche langsam?

Indizes mit zu vielen durchsuchbaren Feldern, Facetten mit Tausenden von Werten, Analytics-Schreibvorgänge auf dem Antwortweg, und Antworten, die das ganze Produkt bringen, obwohl die Karte nur eine Handvoll Felder benutzt.

Macht die Suche den Shop langsamer?

Sollte sie nicht. Die Verarbeitung passiert außerhalb des Shop-Servers und die Antwort ist klein. Was auf der Seite meist wiegt, ist die Darstellung der Ergebnisse: Bilder ohne angegebene Größe und ohne verzögertes Laden kosten mehr als die ganze Suche.

Messt ihr die Zeit auf der Serverseite oder beim Besucher?

Beides. Die Serverzeit ist das, was wir direkt optimieren können, und sie geht in jeder Antwort im Header Server-Timing mit, nach Schritten aufgeteilt und ohne Zugangssperre: wer die Zahlen dieses Artikels prüfen will, öffnet die Werkzeuge des Browsers in einem Shop mit installiertem Buskara. Die Zeit des Besuchers umfasst Netz und Zeichnen im Browser, und sie ist die einzige, die dem entspricht, was die Person spürt.

Gelten die Zahlen dieses Artikels für meinen Katalog?

Der Teil der Suchmaschine nicht unbedingt: er wurde in einem Katalog mit 19 Produkten gemessen und ist der Anteil, der mit der Größe des Index am stärksten wächst. Die anderen Anteile (den Shop identifizieren, den Index wählen, Regeln anwenden, Facetten zählen) hängen wenig von der Zahl der Produkte ab und viel von der Konfiguration. Die Form der Tabelle bleibt; die erste Zeile ist die, die sich ändert.