Removing latency as an architecture, not a list of tricks: optimistic mutation, cache tiers, stampede protection, deferred tails — each measured against the naive version.
The half of Velocity the user feels. None of it makes the server any faster.
Both columns talk to the same simulated server. One waits for it; the other applies the intent immediately and reconciles afterwards.
Blocks for 500ms per click.
Applies now; the same 500ms confirmation follows.
Only for reversible, predictable actions. Payments, deletions and permission changes are never optimistic — a rollback that restores a privilege the user never had is worse than a wait.
Six levels of speculation over SvelteKit's own triggers. The attributes below are read from the module, not retyped.
| Intent | Code | Data | Use for |
|---|---|---|---|
none | off | off | Expensive, rarely followed, or mutating links. |
code | viewport | off | An expensive route: warm the chunk, spend nothing on the server. |
data | hover | hover | The ordinary case, matching the app-wide hover default. |
code-data | viewport | tap | High-probability links: chunk early, data on pointer-down. |
idle | off | off | Driven by preloadOnIdle after the page is interactive, not by an attribute. |
Data never fires from mere visibility. On a page of forty links, viewport-triggered data would run forty route loads for someone who scrolled past.
A long list should cost the size of the viewport, not the size of the data. Switch the row count and watch what stays in the DOM.
Uniform row height only, on purpose: variable heights need measurement and a running offset table, and every one of those is a source of scroll jump. Arrow keys, Page Up/Down, Home and End move a roving selection — the rows a user would tab through mostly do not exist.
Think this pattern could be better? Tell us how.
Leave feedback