Skip to content

CONCEPT Cited by 1 source

Preheating

Definition

Preheating is a cache-population discipline in which a high-fanout source surface (issue list, dashboard, project view) proactively walks references to likely-next destinations and pre-fills cache entries for them — but only fetches data when the cache entry doesn't already exist. "Preheating proactively walks high-intent issue references and prepares cache entries ahead of navigation, but it only hits the network when the issue is not already present in the client cache. If usable data already exists, preheating stops." (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

The framing GitHub uses to distinguish preheating from traditional prefetch is sharp: "This makes it fundamentally different from traditional preloading. It is cache-population logic, not freshness-enforcement logic."

What preheating is not

  • Not eager prefetch. Eager prefetch fetches the data for every likely-next destination regardless of cache state. "On high-fanout surfaces such as issue lists, dashboards, and projects, eager prefetching amplifies request volume, creates N+1-style access patterns and pushes unnecessary compute onto the system for pages a user may never open."
  • Not freshness enforcement. Preheating doesn't refresh a stale cached value to the latest server state; it leaves cached data alone if it exists. Freshness is recovered after the user navigates, via background revalidation along the SWR read path.
  • Not request-time prefetch. It is preheating, not just-in- time fetch on hover; it runs before the user's intent is declared, at any opportunity the source surface provides.

Why "cache-population, not freshness-enforcement" matters

The economic argument for preheating is that it shifts the unit of optimisation from "keep cached data fresh" (which costs a network call per item per refresh interval) to "keep some usable data local" (which costs a network call per item only on first sighting). On high-fanout surfaces with N issues visible, eager prefetch amplifies traffic by ~N×; preheating amplifies traffic by only the cold-cache fraction of the same N — typically <100 % on warm sessions, quickly approaching 0 % as the user works through their issue queue.

This is the architecturally important property: preheat cost shrinks with cache warmth. After enough preheating, the network cost of preheating is essentially zero because all the visible items are already cached. Eager prefetch never gets that property because it always fires on every render.

Operational discipline

Preheating works only if it does not crowd out user- initiated work. GitHub's published discipline:

  • Low-priority workers — preheat fetches run on workers separate from the user-initiated request path.
  • Strict rate limiting — bound preheat capacity at request origin.
  • Circuit breakers — back off entirely when upstream signals pressure.
  • User work pre-empts speculative work — if the user initiates a request, in-flight preheating is deprioritised.
  • Triggered from high-intent surfaces only — issue lists, dashboards, projects, dependency views. Not from low-signal surfaces.

"User-initiated work always takes precedence over speculative fetches, allowing us to avoid the noisy-neighbor problem and keep the system stable while still improving cache-hit ratios for real user navigations." (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

Quantified impact (canonical instance)

GitHub's issues#show cache rollout sequence:

Phase Cache-hit ratio Instant share (React soft)
Cache layer alone ~33 % 22 %
+ preheating + memcache ~96 % ~70 %

The ~33 % → ~96 % cache-hit ratio jump is almost entirely attributable to preheating + the in-memory tier (the persistent IndexedDB layer was already in place). Preheating's job is raising the cache-hit ratio without proportionally raising network volume, and the GitHub data shows it works: cache-hit ratio tripled while network volume rose only by the cold-cache fraction of new preheat sources.

Relationship to nearby concepts

  • Prefetch (general): fetches data ahead of demand. Eager prefetch always fetches; preheating is a conditional form that no-ops on hit.
  • Cache warming (general): the act of populating a cold cache, often at startup. Preheating is a traffic-driven form of cache warming that runs continuously rather than at startup.
  • Spatial locality prefetching: fetching nearby items because spatial proximity predicts future access. Preheating is a temporal- intent-driven form: the source surface shows what's likely next, and preheating walks that list.
  • Prefetch window metadata coattending (LLM-altitude prefetch primitive): same family — prefetch only the things you'll need, no more.
  • patterns/proactive-cache-daily-batch-prediction: batch-altitude precompute-and-cache pattern; preheating is the request-time analogue at the client cache.
  • concepts/stale-while-revalidate-cache: SWR is what picks up after preheating; preheating populates, SWR refreshes on read.

Trade-offs

Axis Eager prefetch Preheating Lazy fetch on click
Cache-hit ratio very high very high low
Network amplification ~N× ~cold-cache× none
Freshness always fresh bounded-stale until revalidate always fresh on demand
Capacity discipline needed high high low
Suitable for high-fanout source surfaces no (N+1 storm) yes yes

The "high-fanout source surface" cell is what makes preheating the right answer for issue lists / dashboards: eager prefetch is too expensive there, lazy fetch leaves ratios too low, and preheating clears the floor at the cost of some staleness controlled by the SWR layer beneath.

Seen in

Last updated · 542 distilled / 1,571 read