PATTERN Cited by 1 source

Preload-on-request hint (warm the backend before the client connects)

Preload-on-request hint is a pattern that attacks latency on a two-step client connection:

1. Client makes a cheap first request (an HTTP GET for the page).
2. Client then opens a more expensive connection (a WebSocket to a stateful backend service) that can't start serving until it has loaded some state into memory.

The pattern: on step (1), the fronting server immediately fires a hint to the stateful backend naming the state it's about to need, so the backend starts loading that state in parallel with the client establishing step (2). By the time the WebSocket lands, the state is already warm (or warming) in the backend.

(Canonical source: sources/2024-05-22-figma-dynamic-page-loading — Figma's backend hints Multiplayer on the initial page-load GET so Multiplayer begins downloading + decoding the Figma file before the client's WebSocket connects. Saves 300–500 ms at p75.)

Shape

Before:
  client ──HTTP GET page──▶ backend ──▶ client (page HTML)
  client ──WS connect─────▶ Multiplayer
                             │ (starts loading file now)
                             │ (decode takes >5s in worst case)
                             ▼
                           ready to serve
  ⟶ client waits for entire load+decode serially

After:
  client ──HTTP GET page──▶ backend
                             │ (1) fire preload hint
                             │     ──────▶ Multiplayer
                             │             │ load + decode
                             ▼             │ in parallel
                           client          │
                            │              │
                            │ (2) WS connect when page loads
                            └────────────▶ Multiplayer
                                           │ (already loading/loaded)
                                           ▼
                                         ready sooner

Why it works

The gap between step (1) and step (2) — page HTML download, JS parse, WebSocket handshake — is dead time from the backend's perspective in the naive architecture. The hint puts that time to work.

The hint is a fire-and-forget signal; the backend does the real load regardless of whether the client's WebSocket arrives. If the client never completes step (2), Multiplayer has done some wasted work (will age out of its cache). The pattern trades a small amount of wasted load on abandoned sessions for a large latency cut on completed ones.

Requirements

1. The state is identifiable from the first-step request. Figma knows from the page GET which file the client will load.
2. The backend can load state speculatively. Multiplayer tolerates "maybe no one will open a WS for this file."
3. The front-door service has a path to the stateful backend. A cheap internal RPC / pub-sub hint channel is enough; it doesn't need to carry the client's data.
4. Load-time wins exceed hint-cost losses. If only a small fraction of step (1)s become step (2)s, or if backend load is expensive and most loads are wasted, the pattern loses.

Impact at Figma

• 300–500 ms p75 savings on dynamic page load.
• This is on top of the parallel-decoding optimization (which cut the decode span itself by >40%). The two are complementary — parallel decoding makes the decode shorter; preload-on-hint moves it off the critical path.

Related patterns

• patterns/asset-preload-prediction — similar shape on the SSR tier: emit <link rel="preload"> for bundles the page is likely to need before SSR completes, so the browser fetches in parallel with server rendering.
• concepts/lazy-hydration — opposite side of the coin: defer non-critical loads so the critical path fits. Preload- on-hint anticipates a critical load so it overlaps with other work.
• HTTP 103 Early Hints — standardized preload-hint mechanism from origin to client. Preload-on-request-hint is the same idea applied inside the backend (origin → stateful-service), where the "hint" is an internal RPC rather than a response header.
• Pre-warmed cache on cache-miss prediction — e.g. a CDN prefetching likely-next-asset based on a request pattern.

When not to use

• When step-(1) → step-(2) conversion is very low (mostly wasted load).
• When the backend load is an expensive external call with per-invocation cost (billing, rate-limited API).
• When the hint itself has non-trivial cost (security context propagation, auth flows).

Seen in

• sources/2024-05-22-figma-dynamic-page-loading — Figma's backend → Multiplayer preload hint on page-load GET, shaving 300–500 ms at p75 before the client's WebSocket lands.