Building a Zero-Latency Navigation System: A Guide to Client-Side Caching and Service Workers for Web Apps

Overview

In modern web applications, every millisecond of delay can break a user's flow—especially in tools like GitHub Issues where developers rapidly navigate between lists, details, and linked threads. Traditional server-side rendering and full network fetches for each navigation add cumulative latency, turning a simple context switch into a frustrating wait. The solution isn't to optimize the backend in isolation but to shift work to the client, leveraging local storage and background revalidation to make navigations feel instant.

This guide walks you through a production-tested pattern for reducing perceived latency: a client-side caching layer backed by IndexedDB, a preheating strategy to boost cache hit rates, and a service worker to ensure cached data remains available even on hard navigations. By the end, you'll be able to apply these techniques to any data-heavy web app, transforming sluggish page loads into near-instant transitions.

Prerequisites

Before diving in, you should have:

• Basic knowledge of web performance metrics – understanding of Time to First Byte (TTFB), First Contentful Paint (FCP), and perceived latency.
• Familiarity with JavaScript and browser APIs – especially IndexedDB, Service Workers, and Fetch.
• A modern web app – preferably one with list/detail navigation patterns and data that can be cached client-side.
• Developer tools experience – for profiling and debugging (e.g., Chrome DevTools Application panel).

Step-by-Step Instructions

1. Identify Navigation Pain Points and Define Metrics

Start by measuring your current navigation performance. Focus on the time to interactive for common user flows—opening an item, going back to a list, following a link. In GitHub Issues, the team observed that even small delays (~200ms) compound across multiple navigations, breaking concentration. Define a primary metric like perceived navigation latency (time from click to content visible) and set a target (e.g., <100ms). Use the Performance API to capture real user monitoring data.

2. Design a Client-Side Caching Layer with IndexedDB

IndexedDB is your best bet for storing structured data locally with high capacity. Create a database with object stores for each type of entity (e.g., issues, comments). Write functions to read and write cached responses, including timestamps for staleness checks. Example structure:

const db = await openDB('issues-cache', 1, {
  upgrade(db) {
    db.createObjectStore('issues', { keyPath: 'id' });
  }
});

async function cacheIssue(issue) {
  await db.put('issues', { ...issue, cachedAt: Date.now() });
}

async function getCachedIssue(id) {
  return await db.get('issues', id);
}

Cache only data that is relatively stable (e.g., issue title, body) and exclude highly dynamic fields like real-time comment counts.

3. Implement a Preheating Strategy

Preheating means loading data into the cache before the user explicitly requests it—without spamming requests. One effective approach: when a user hovers over a link for more than 100ms, prefetch the related resource and store it. In GitHub Issues, they identified common patterns like linked issue references and preheated those. Use an IntersectionObserver or hover events to trigger preloading. Example:

document.addEventListener('mouseover', (e) => {
  const link = e.target.closest('a[data-preheat]');
  if (link && !link.dataset.preheated) {
    link.dataset.preheated = 'true';
    const url = link.href;
    fetch(url).then(res => res.json()).then(data => cacheIssue(data));
  }
});

4. Integrate a Service Worker for Hard Navigation Resilience

A service worker intercepts all network requests and can serve cached responses instantly, even on full page reloads. Register the service worker in your app's entry point. In the fetch event, implement a cache-first strategy for known resource URLs, falling back to network and updating the cache. For navigation requests, check the IndexedDB cache first. If found and fresh, serve it; otherwise fetch from network and cache. Example:

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then(cachedResponse => {
      if (cachedResponse) return cachedResponse;
      return fetch(event.request).then(networkResponse => {
        return caches.open('cache-v1').then(cache => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
      });
    })
  );
});

Combine this with IndexedDB: the service worker can read from IDB for complex data (e.g., issue details) and serve a rendered page from the cache.

5. Implement Background Revalidation

To keep data fresh, after rendering from cache, kick off a background fetch to the server and update the cache with the latest data. This way the user sees instant content, and within a few hundred milliseconds the page updates if anything changed. Use navigator.serviceWorker.ready to post a message to the service worker to revalidate. Alternatively, a simple fetch after render and update the DOM and IDB.

6. Measure and Iterate

After implementation, run A/B tests or use RUM (Real User Monitoring) to compare perceived navigation latency. In GitHub's case, they saw a reduction from ~300ms to under 50ms for common navigation paths. Track cache hit ratios (should be above 80% for preheated paths) and adjust preheating heuristics based on user behavior.

Common Mistakes

Over-fetching or Caching Too Much

Caching stale or bulky data can lead to memory bloat and outdated UI. Only cache the essential fields needed to render the initial view. Use a maximum age per entity type (e.g., 5 minutes for issue lists, 30 seconds for live status).

Ignoring Cache Invalidation

If the user performs a write (e.g., updates an issue), you must invalidate the related cached entries immediately. Implement a publish/subscribe pattern where mutations trigger cache deletions.

Service Worker Scope Issues

Service workers only intercept requests within their scope. Ensure the worker is registered at the root or a path that covers all app routes. Otherwise, some navigations bypass the cache.

Not Handling Errors Gracefully

If preheating fails (network error), don't block the user. Fail silently and rely on the default fetch on navigation. Use .catch() on preheating requests.

Summary

By shifting data fetching to the client with IndexedDB, preheating likely next navigations, and hardening the system with a service worker, you can dramatically reduce perceived latency in data-heavy web apps. This pattern—render from cache, revalidate in background—transforms context-switching navigation into a seamless flow. The techniques used in modernizing GitHub Issues are directly transferable; start small, measure impacts, and iterate. Your users will notice the difference between “fast enough” and “feels instant.”