GitHub 工程团队重构 Issues 导航架构，引入客户端缓存、预测性预取与 Service Worker 拦截机制，将即时导航体验比例从 4% 提升到 22%，中位延迟从 1.2 秒压缩至 700 毫秒——这是一次把"等服务器"改成"先用本地"的范式切换。
GitHub 测量了导航延迟的完整分布。改善并非均匀——越快的场景降幅越大，P10 降幅达 88%，而 P90 仅 12.5%。这说明架构改造主要消除了"本不该慢却慢了"的冗余请求，对真正受限于数据量的尾部场景帮助有限。
注：柱形按改造前最大值（2,400ms）等比缩放，非零起点。具体数值：P10 600→70ms，P25 800→120ms，P50 1,200→700ms，P75 1,800→1,400ms，P90 2,400→2,100ms。
核心变化是一次请求顺序的翻转：过去每次导航都先问后端拿最新数据再渲染；现在先用本地缓存渲染页面外壳，后台同步更新。用户看到的不再是空白加载，而是"先有内容，再悄悄刷新"。
每次导航 → 请求后端 → 等响应 → 渲染。重复访问同一 Issue 也要重新走完整网络链路。
导航 → 查本地缓存 → 立即渲染 → 后台异步校验更新。已访问过的内容秒开，过期数据后台静默刷新。
这套架构依赖三层组件协同：
其中预热机制会根据用户导航模式提前准备可能需要的数据；Service Worker 则在浏览器层面拦截请求，先查本地资源——命中就立即返回，未命中或过期才走正常后端路径。缓存策略采用 stale-while-revalidate：先展示可能过期的本地数据，后台同步更新后悄悄替换。
这套架构并非万能。两位外部工程师分别指出了适用边界与度量哲学两个层面的关键点：
BareStack 的结论是：真正可复用的模式不是"预取"，而是"优先渲染页面外壳 + 基于缓存命中进行数据填充"。预取只是这个模式在特定数据形态下的副产品。
这与 GitHub 实际测量的分布吻合：P10 改善 88% 而 P90 仅 12.5%——团队选择把工程精力压在覆盖更多场景进入"快"区间，而非把最慢的场景再压一点。GitHub 高级软件工程师 Alexander Lelidis 给出了团队内部的认知锚点：
本文事实数据主要源自 GitHub 工程团队的单方披露，延迟分布与即时导航比例均未见过第三方独立复测，读者宜将其视为"团队自述的优化结果"而非中立基准测试。报道本身亦未披露测试样本量、运行环境与统计口径——这些是评估性能数据可靠性的必要前提。
值得留意的支线：BareStack 提到的"小数据图 + 读多写少"是预取生效的前提，意味着这套方案不能直接外推到任意 Web 应用——GitHub Issues 的数据形态恰好命中了它的甜区。
改造已上线 GitHub Issues 线上环境，登录后在 Issue 列表与详情间切换即可感知变化。原始工程报道与架构图见下方链接。
阅读原始报道 → InfoQ