From Latency to Instant: Modernizing GitHub Issues Navigation Performance

GitHub Issues changed its server-centric flow to reduce navigation latency, moving to a stale-while-revalidate model that first renders data already available on the client and then updates it in the background. The goal was to increase the instantaneity users actually perceive, rather than just average latency.

The success metric was an internal metric called HPC (Highest Priority Content). Similar to Web Vitals LCP, it measures when the most important content is first rendered, with the following thresholds:

• Instant: HPC < 200ms
• Fast: HPC < 1000ms
• Slow: HPC >= 1000ms

In initial traffic, hard navigation accounted for the largest share at 57.6%, and HPC also varied: hard 2.05, Turbo 1.76, React 1.04. Since GitHub is still in a transitional period using both Rails rendering and a React frontend together, the bottleneck was the structure where a full load occurred every time these two boundaries were crossed.

The first improvement was an IndexedDB-based client cache. They expanded the memory store to save issue data, handling reads as cache-first and writes with background revalidation. They also introduced a service worker to reuse cached data even after refreshes or hard navigation.

To further boost the cache hit rate, instead of blindly increasing prefetch, they chose preheating. Starting from an initial cache hit rate baseline of about 30%, they prepared data in advance for items in the issue list likely to be opened next, while avoiding request spikes and N+1 patterns.

After the rollout, 22% of React navigations fell into the instant range, a large increase from 4% before the rollout. This corresponded to about 15% of total requests, with the cache hit rate managed at about 33% and server/cache mismatches kept at around 4.7%.