GitHub 近期重构了 Issues 模块的导航架构，通过将更多计算负载迁移至客户端，显著降低了开发者感知的延迟。工程团队引入客户端缓存、预测性预取及基于 Service Worker 的请求处理机制，使即时导航体验占比从 4% 提升至 22%。该方案有效解决了大型 Web 应用在高频重复工作流中，因重复网络请求和客户端初始化导致的延迟痛点。
本地优先架构与多层缓存策略
针对 GitHub Issues 用户频繁在列表、详情页及相关视图间切换的场景，新架构采用“本地优先（local-first）”策略：浏览器优先利用本地已有数据进行渲染，后台进程按需异步获取更新信息，避免了对后端服务的重复依赖。
该架构构建了多层客户端存储体系：利用 IndexedDB 进行持久化存储，同时结合内存缓存处理活跃会话期间的高频访问数据。
GitHub Issues 客户端架构
BareStack 指出，预取（prefetching）策略适用于数据图规模较小且以读取为主的场景（如 Issues）。对于数据图庞大且存在读写冲突的大多数应用，更通用的优化模式是“优先渲染页面外壳 + 基于缓存命中填充数据”，而非单纯依赖预取。
Oguz Guven 强调，工程成熟度的体现在于从关注 p99 尾部延迟转向关注整体延迟分布的质量。
Stale-while-revalidate 与预热机制
缓存模型采用 stale-while-revalidate（过期后重新验证）策略。当用户回访已加载内容时，应用直接展示本地数据，无需等待服务器响应，随后在后台同步更新以确保数据一致性。
为进一步提升缓存命中率，GitHub 引入了“预热（preheating）”机制。系统根据用户导航模式，在请求发起前提前准备数据并填充缓存。配合 Service Worker 拦截浏览器请求并检查本地资源，实现了数据的即时渲染与后台静默更新。若本地数据不可用或过期，请求将自动回退至标准后端路径。
Service Worker 请求流程
该架构在响应速度与数据新鲜度之间取得了平衡：允许部分内容立即展示并通过异步方式完成更新，既降低了用户等待时间，又保留了与后端系统的数据同步能力。
性能优化成果
GitHub 高级软件工程师 Alexander Lelidis 表示：“延迟不仅仅是一个指标，它是一种上下文切换。”团队对导航延迟分布进行了深度优化，各项指标显著提升：
- P10 延迟：从约 600ms 降至 70ms
- P25 延迟：从 800ms 降至 120ms
- 中位延迟：从 1,200ms 降至 700ms
- P75 延迟：从 1,800ms 降至 1,400ms
- P90 延迟：从 2,400ms 降至 2,100ms
原文连接：https://www.infoq.com/news/2026/07/github-issues-navigation/