GitHub has redesigned the navigation architecture behind GitHub Issues to reduce perceived latency for developers by moving more work to the client-side. The engineering team introduced client-side caching, predictive prefetching, and service worker-based request handling to improve navigation performance, increasing instant navigation experiences from 4% to 22%. The changes address a common challenge in large-scale web applications: reducing delays caused by repeated network requests and client initialization during frequently repeated workflows.

The work focused on GitHub Issues users who frequently navigate between issues, lists, and related views, where previously retrieved information could be reused instead of fetched again from backend services. To reduce these repeated network dependencies, GitHub adopted a local-first approach that renders available data immediately from the browser while background processes retrieve newer information when needed. The architecture uses multiple client-side storage layers, including IndexedDB for persistent storage and in-memory caching for frequently accessed data during active sessions.

GitHub Issues client-side architecture (Source: GitHub Blog Post)

BareStack highlighted an important distinction around prefetching:

Prefetching pays when the data graph is small and read-heavy like Issues. Most applications have a larger graph with read/write collisions, so prefetched views may re-fetch after landing. The reusable pattern is the shell-first render + cache-hit hydration, not prefetching itself.

Oguz Guven also pointed out another important performance lesson:

Shifting from the p99 tail to distribution quality is the real engineering maturity here.

The caching model follows a stale-while-revalidate approach. When users revisit previously accessed content, the application can display locally stored data without waiting for a server response. The system then performs background synchronization to update cached information and maintain consistency with backend data.

GitHub introduced preheating to improve cache effectiveness by preparing likely required data before users request it, using navigation patterns to populate relevant cache entries. The team also extended the approach with service workers that intercept browser requests and check for locally available resources. Cached data can be rendered immediately while background updates synchronize newer information. Requests for unavailable or stale data continue through the normal backend path.

Service worker request flow (Source: GitHub Blog Post)

The architecture required balancing responsiveness with data freshness. Instead of waiting for every interaction to receive the latest server state before rendering, GitHub allowed some content to be displayed immediately and updated asynchronously. This approach reduces user waiting time while preserving synchronization with backend systems.

Alexander Lelidis, senior software engineer at GitHub, explained that the team viewed latency as more than a measurement, stating,

Latency isn’t just a metric. It’s a context switch.

GitHub measured improvements across navigation latency distributions. P10 latency decreased from approximately 600 milliseconds to 70 milliseconds, P25 from 800 milliseconds to 120 milliseconds, and median latency from 1,200 milliseconds to 700 milliseconds. P75 and P90 latency also improved, decreasing from 1,800 to 1,400 milliseconds and 2,400 to 2,100 milliseconds, respectively.

About the Author

Leela Kumili