Suchvorschläge ohne Wartezeit: die Shopsuche beschleunigen

Ein Besucher, der über die Navigation kommt, stöbert. Ein Besucher, der ins Suchfeld tippt, sucht - einen bestimmten Artikel, eine Marke, eine Bestellnummer aus dem letzten Angebot. Im B2B-Portal ist das noch ausgeprägter: Einkäufer kennen ihre Artikelnummern und erwarten, dass nach wenigen Zeichen die richtige Position in der Liste steht. Die Suche ist damit der Weg durch den Shop, auf dem Absicht und Geduld am weitesten auseinanderliegen. Die Absicht ist hoch, die Bereitschaft zu warten gering. Wer hier ins Leere tippt, verliert den Faden, bevor der Shop überhaupt zeigen konnte, was er führt.

Suchvorschläge sind dabei kein Extra mehr, sondern die Erwartung. Das Baymard Institute stellt in seinem E-Commerce-Benchmark fest, dass 80 Prozent (Baymard Institute) der untersuchten Shops Suchvorschläge anbieten; bei der ersten Erhebung 2014 waren es bereits 72 Prozent (Baymard Institute). Wer das Suchfeld einmal mit Vorschlägen erlebt hat, liest jede Pause als Störung. Gleichzeitig ist die Autovervollständigung technisch eine der anspruchsvollsten Stellen im Shop: Sie verbindet Eingabeverarbeitung im Browser, eine Netzanfrage, eine Datenbank- oder Indexabfrage und das Rendern einer Liste - und das nicht einmal pro Seitenaufruf, sondern potenziell bei jedem Tastendruck.

Genau deshalb reicht der Blick auf die Ladezeit der Startseite hier nicht. Eine Shopsuche kann auf einer Seite mit gutem Largest Contentful Paint stecken und trotzdem träge wirken, weil ihre Zeit nicht beim Laden entsteht, sondern während der Nutzung. Wie sich solche Nutzungszeit in den Kennzahlen niederschlägt, ordnet unser Überblick zu den Core Web Vitals ein.

Die häufigste Bremse ist zugleich die einfachste: Das Suchfeld schickt bei jedem Tastendruck eine Anfrage los. Wer einen längeren Begriff tippt, erzeugt so viele Anfragen, wie der Begriff Buchstaben hat - und fast alle davon beantworten eine Frage, die in dem Moment, in dem die Antwort eintrifft, niemand mehr stellt. Jede dieser Anfragen belegt eine Verbindung, einen Worker auf dem Server und am Ende Rechenzeit im Browser, wenn die Antwort verarbeitet wird. Bei Lastspitzen im Saisongeschäft wird aus dieser Verschwendung schnell ein Engpass für den ganzen Shop.

Entprellen, im Englischen debounce, löst das: Die Anfrage startet erst, wenn die Eingabe für einen kurzen Moment ruht. Tippt der Besucher zügig durch, entsteht eine Anfrage am Ende einer Tipp-Pause statt einer je Zeichen. Die Pause wird nicht geschätzt, sondern an der eigenen Messung eingestellt: lang genug, um schnelles Tippen zusammenzufassen, kurz genug, dass Pause, Serverantwort und Rendern zusammen unter der Grenze von 1,0 Sekunden (Nielsen Norman Group) bleiben. Dazu gehört eine Mindestlänge des Suchbegriffs. Ein einzelner Buchstabe liefert selten brauchbare Vorschläge, aber eine teure Abfrage mit riesiger Treffermenge - in Sortimenten mit kurzen Artikelnummern kann die Grenze dagegen niedriger liegen als in einem Modeshop.

Wichtig ist, was nicht entprellt wird: das Zeichnen des getippten Zeichens. Der Browser zeigt das Zeichen selbst an, sobald der Hauptthread frei ist. Wer im Eingabe-Handler dagegen synchron eine Liste filtert, Analyse-Ereignisse verschickt oder das halbe Suchmodul neu zeichnet, verlängert die Verarbeitungszeit jeder einzelnen Taste. Der Handler sollte nur den Wert entgegennehmen und den Zeitgeber neu starten - alles andere läuft später. Wie sich unvermeidbar lange Aufgaben aufteilen lassen, zeigt unser Beitrag zu scheduler.yield und langen Tasks.

Suchbegriffe verteilen sich nicht gleichmäßig. Die Anfänge von Begriffen - die Präfixe - wiederholen sich über alle Besucher hinweg zwangsläufig öfter als ganze Begriffe: Jeder vollständige Begriff beginnt mit seinen Präfixen, und viele verschiedene Begriffe teilen sich denselben Anfang. Genau diese Anfragen sind oft die teuersten, weil kurze Präfixe die größten Treffermengen erzeugen. Und genau sie lassen sich am besten zwischenspeichern, weil ihre Antwort für alle Besucher mit gleichem Kontext identisch ist.

Ein Antwort-Cache für Suchvorschläge braucht einen sauberen Schlüssel. Der Suchbegriff wird vorher normalisiert: Leerzeichen am Rand entfernen, Groß- und Kleinschreibung vereinheitlichen, Unicode-Schreibweisen angleichen. Sonst landen Varianten desselben Präfixes als getrennte Einträge im Cache, und die Trefferquote sinkt. In den Schlüssel gehört alles, was die Antwort tatsächlich verändert - Verkaufskanal, Sprache, Währung und im B2B-Portal die Kundengruppe, wenn Vorschläge Preise oder kundenspezifische Sortimente zeigen. Nicht hinein gehören Sitzungskennungen oder Tracking-Parameter: Sie machen jeden Eintrag einmalig. Wie ein einziges Cookie die Trefferquote zerlegt, beschreibt unser Beitrag zu Cookies, Vary und Cache-Fragmentierung.

Für die Anfragen, die am Cache vorbeigehen, zählt die Abfrage selbst. Ein gewöhnlicher B-Tree-Index hilft einer Mustersuche nur, wenn das Muster am Anfang der Zeichenkette verankert ist - also bei LIKE 'bohr%', nicht bei LIKE '%hammer' (PostgreSQL-Dokumentation). Ohne nutzbaren Index bleibt der Datenbank meist nur, die Tabelle Zeile für Zeile zu durchsuchen. Eine Präfixsuche oder ein eigener Suchindex mit vorberechneten Wortanfängen beantwortet dieselbe Frage mit einem Bruchteil der Arbeit. Welche Abfragen in einem Shop die meiste Zeit kosten, zeigt der Beitrag zur Datenbank-Query-Optimierung; wie viel davon auf eine einzelne Suchanfrage entfällt, macht ein Antwortkopf sichtbar, den wir im Beitrag zu Server-Timing beschreiben.

Übliche Lighthouse-Läufe laden eine Adresse, warten, bis die Seite ruhig ist, und bewerten den Aufbau. Getippt wird dabei nicht. Die Autovervollständigung wird so nie ausgelöst, und die Ergebnisseite der Suche steht meist gar nicht auf der Liste der geprüften Adressen, weil sie erst durch eine Eingabe entsteht. Ein Shop kann dadurch in jedem Bericht gut aussehen, während sein Einstieg mit der klarsten Kaufabsicht ungemessen bleibt. Wie sich Lighthouse-Ergebnisse einordnen lassen, zeigt der Beitrag zum Lighthouse-Report.

Für die Suche braucht es drei Blickwinkel. Im Labor analysiert Lighthouse im Zeitraum-Modus einen frei gewählten Zeitraum, der typischerweise Nutzerinteraktionen enthält - etwa das Tippen ins Suchfeld und das Absenden der Suche - und misst darin Layoutverschiebungen und JavaScript-Ausführungszeit (Lighthouse-Dokumentation). Das Leistungsfeld der Entwicklertools zeigt jede einzelne Taste mit Eingabeverzögerung, Verarbeitungszeit und Darstellungsverzögerung; mit gedrosselter CPU kommt das einem Mittelklasse-Smartphone näher als der Arbeitsrechner. Im Feld liefern RUM-Daten den echten INP, und wenn jede Interaktion ihr auslösendes Element mitschreibt, lässt er sich auf das Suchfeld filtern. Was Felddaten leisten und wo CrUX aufhört, vergleicht unser Beitrag zu RUM und CrUX.

Den Netzweg misst man getrennt: Wie viele Anfragen erzeugt ein typischer Suchbegriff, wie lange dauert jede, wie viele werden abgebrochen, und welche Präfixe verfehlen den Cache? Die Resource-Timing-Daten des Browsers und ein Server-Timing-Kopf am Suchendpunkt beantworten das ohne Zusatzwerkzeug. Die Ergebnisseite selbst gehört mit einer typischen Suchadresse in jede Messreihe - als eigene Vorlage, so wie Kategorie- und Produktseite. Warum die Startseite allein nie reicht, erklärt der Beitrag Vorlage statt Startseite.