GitHub rebuilds Issues navigation for instant, cache-first loading

GitHub reworked how Issues pages load to cut down on the latency users feel when navigating between issues and linked threads. Instead of chasing small backend gains, the team shifted work to the client: render instantly from local data, then revalidate in the background. This required a new IndexedDB-backed caching layer, a preheating strategy to boost cache hit rates, and a service worker so cached content stays usable even during full page reloads.

To measure success, GitHub used an internal metric called HPC (Highest Priority Content), closely aligned with Web Vitals' LCP, bucketing navigations as instant (under 200ms), fast (under 1000ms), or slow. Rather than just chasing tail-latency improvements at p99, the team focused on shifting the overall distribution so speed becomes the default experience for most sessions, not just avoiding the worst outliers.

Baseline analysis revealed three navigation types—hard navigations (full page loads), Rails Turbo transitions, and React soft navigations—with hard navigations being both the slowest and most common, largely because GitHub is still mid-migration from Rails to React and many user journeys cross that boundary. The team prioritized React soft navigations first, where they had the most architectural leverage, targeting roughly a 30% cache-hit ratio based on observed patterns of users repeatedly reopening the same issues during triage.

The approach offers a transferable pattern for any team building data-heavy web apps: local-first caching with stale-while-revalidate can meaningfully reduce perceived latency without requiring a full architectural rewrite.