Latenz beseitigen als Architektur, nicht als Trickkiste: optimistische Mutationen, Cache-Stufen, Stampede-Schutz, verschobene Nacharbeit — jeweils gegen die naive Variante gemessen.
Die Hälfte von Velocity, die Nutzer spüren. Nichts davon macht den Server schneller.
Beide Spalten sprechen mit demselben simulierten Server. Die eine wartet darauf, die andere wendet die Absicht sofort an und gleicht danach ab.
Blockiert 500ms pro Klick.
Wendet sofort an; dieselbe Bestätigung nach 500ms folgt.
Nur für umkehrbare, vorhersehbare Aktionen. Zahlungen, Löschungen und Rechteänderungen sind niemals optimistisch — ein Rollback, das ein nie vorhandenes Recht wiederherstellt, ist schlimmer als Warten.
Sechs Spekulationsstufen über SvelteKits eigene Auslöser. Die Attribute unten stammen aus dem Modul, sie sind nicht abgetippt.
| Absicht | Code | Daten | Wofür |
|---|---|---|---|
none | off | off | Teure, selten benutzte oder verändernde Links. |
code | viewport | off | Eine teure Route: Chunk vorwärmen, den Server nichts kosten. |
data | hover | hover | Der Normalfall, passend zum app-weiten Hover-Standard. |
code-data | viewport | tap | Links mit hoher Wahrscheinlichkeit: Chunk früh, Daten beim Drücken. |
idle | off | off | Von preloadOnIdle gesteuert, sobald die Seite interaktiv ist — nicht von einem Attribut. |
Daten werden nie allein durch Sichtbarkeit geladen. Auf einer Seite mit vierzig Links würde ein Viewport-Trigger vierzig Route-Loads für jemanden auslösen, der nur vorbeigescrollt ist.
Eine lange Liste sollte so viel kosten wie das Sichtfeld, nicht wie die Datenmenge. Wechsle die Zeilenzahl und beobachte, was im DOM bleibt.
Bewusst nur einheitliche Zeilenhöhen: variable Höhen brauchen Messung und eine laufende Offset-Tabelle, und beides erzeugt Scroll-Sprünge. Pfeiltasten, Bild auf/ab, Pos1 und Ende bewegen eine wandernde Auswahl — die Zeilen, durch die man sonst tabben würde, existieren größtenteils nicht.
Geht dieses Pattern noch besser? Sag uns, wie.
Feedback geben