从延迟到即时：现代化 GitHub Issues 导航性能

分享：
[](https://x.com/share?text=从延迟到瞬时%3A%20提升%20GitHub%20Issues%20导航性能的现代化实践&url=https%3A%2F%2Fgithub.blog%2Fengineering%2Farchitecture-optimization%2Ffrom-latency-to-instant-modernizing-github-issues-navigation-performance%2F)
[](https://www.facebook.com/sharer/sharer.php?t=从延迟到瞬时%3A%20提升%20GitHub%20Issues%20导航性能的现代化实践&u=https%3A%2F%2Fgithub.blog%2Fengineering%2Farchitecture-optimization%2Ffrom-latency-to-instant-modernizing-github-issues-navigation-performance%2F)
[](https://www.linkedin.com/shareArticle?title=从延迟到瞬时%3A%20提升%20GitHub%20Issues%20导航性能的现代化实践&url=https%3A%2F%2Fgithub.blog%2Fengineering%2Farchitecture-optimization%2Ffrom-latency-to-instant-modernizing-github-issues-navigation-performance%2F)

当你正在处理积压任务——打开一个问题、跳转至关联讨论、再返回列表——延迟早已不只是一个技术指标；它本质上是一次上下文切换。即使微小的延迟也会不断累积，并且恰恰在开发者最需要保持专注流（flow）的关键时刻打断工作节奏。GitHub Issues 单独来看并非“缓慢”，问题在于太多导航操作仍需重复获取数据，一次次地破坏开发者的专注流。

今年早些时候，我们决定从根本上解决这一问题——不追求边际效益有限的后端优化，而是重构 Issue 页面端到端的加载方式。我们的策略是将更多工作前移至客户端，并聚焦于感知延迟（perceived latency）的优化：优先使用本地已有数据即时渲染页面，随后在后台异步校验数据有效性。为实现该目标，我们构建了一套基于 IndexedDB 的客户端缓存层，设计了智能预热（preheating）策略以提升缓存命中率，同时避免请求泛滥；并引入 Service Worker，确保即便在强制刷新或硬导航（hard navigation）场景下，缓存数据依然可用。

本文将详细阐述该系统的运行机制及实际变化：我们将介绍所优化的核心指标；解析缓存与预热的整体架构；说明 Service Worker 如何加速原本缓慢的导航路径；展示真实用户场景下的性能提升效果；同时深入探讨其中的权衡取舍——因为这种方案并非零成本——以及未来还需完成哪些工作，才能让“快速响应”成为所有进入 Issues 路径的默认体验。如果你正在构建数据密集型 Web 应用，这些模式可直接复用：你无需等待一次彻底重写，即可在自己的系统中应用相同模型，显著降低用户的感知延迟。

思维的速度：2026 年的 Web 性能标准

在 2026 年，“足够快”已不再是具备竞争力的门槛。对开发者工具而言，延迟即产品品质。当用户正在排查多个问题、评审功能需求或提交缺陷报告时，任何本可避免的等待都会打断其专注流。

得益于现代“本地优先”（local-first）工具和极致优化的客户端，行业标准已从“一秒内加载完成”跃升至“感觉瞬时响应”。在此背景下，用户不会拿我们与老旧 Web 应用作对比；他们衡量我们的标尺，是自己每天所体验过的最快交互。

GitHub Issues 并非轻量级产品。每周，全球数百万用户依赖 Issues 维持代码库稳定运行。随着 Issues 同时演进为 AI 辅助工作的规划层，感知性能变得愈发关键：若用户意图与系统反馈之间的闭环过慢，整个系统都将显得迟滞。

无论是内部团队还是开源社区，我们都听到了一致的声音：相比那些将速度置于首位构建的工具，Issues 显得过于笨重。瓶颈并非功能深度或逻辑正确性，而在于架构设计与请求生命周期管理——大量常见导航路径仍需承担完整的服务器端渲染、网络请求与客户端启动开销，即便相关数据实际上早已被访问过。

Issues 性能团队的核心使命，正是弥合这一差距。目标清晰而务实：重构数据流与导航行为，使产品在默认状态下即具备“瞬时响应”的体验。

在调整架构之前，我们必须首先就“快”在用户视角中的定义达成共识，并明确如何量化它。通用页面指标虽有参考价值，但面对 Issues 这类复杂产品界面，它们远远不够。

我们采用 HPC（Highest Priority Content，最高优先级内容）这一内部指标——其设计高度契合 Web Vitals 中的 LCP（最大内容绘制），用于衡量页面核心内容（即用户真正关心的内容）首次渲染的时间点。与 LCP 类似，HPC 锚定于浏览器选定的一个 HTML 元素；在 Issue 页面中，该元素通常为 Issue 标题或 Issue 正文。只要该元素快速呈现，即便非关键区域仍在加载，整体体验也已具备良好的响应感。

在实际运营中，我们依据 HPC 指标阈值对各类导航行为进行归类：

即时：HPC < 200 毫秒
快速：HPC < 1000 毫秒
缓慢：HPC ≥ 1000 毫秒

这些阈值为我们提供了一个衡量用户感知速度的实用模型，而不仅仅是后端原始延迟。小于 200 毫秒的区间对应真实工作流中用户感觉“即时响应”的交互；而小于 1000 毫秒的区间则涵盖了仍可接受、但已不再对用户“透明”的体验。

也正是在此阶段，我们的测量理念发生了演进。过去，我们投入大量精力追踪 HPC 的第 90 百分位（p90）和第 99 百分位（p99），并致力于最小化分布尾部最差的延迟。这项工作依然重要，但它本身并不能确保大多数用户的实际体验足够快。我们完全可能提升了 HPC 的 p99，却仍让中位数体验显得迟缓。

因此，在本次优化计划中，我们将重心转向分布质量：在整个用户群体中，有多少次页面导航落入了“快速”与“即时”这两个性能区间？目标不只是减少极差的异常值，更是要让“快速”成为绝大多数会话的默认路径。

基线：尚未做任何改动前的导航构成

在实施任何优化之前，我们必须先清晰了解用户实际是如何抵达 issues#show（查看 Issue 的路由）的。若将所有导航方式笼统视为同一类流量，真实瓶颈就会被掩盖。

我们识别出三种主要导航类型：

硬导航（Hard navigation）：完整的浏览器加载（冷启动或刷新），需承担全部开销——网络请求、服务端渲染、静态资源加载、JavaScript 启动及 React 水合（hydration）。
Turbo 导航（Turbo navigation）：基于 Rails Turbo 的过渡，仅更新页面指定区域，无需整页重载。它规避了部分硬导航开销，但仍高度依赖服务端渲染的响应。
软导航（React）（Soft navigation）：在现有 React 运行时内完成的客户端跳转，通常可避免整页启动成本。

我们在优化启动初期测得的导航构成如下：

图 9：issues#show 路由的导航构成图（57.6% 硬导航，37.5% React 软导航）

该分布揭示了一个关键事实：占比最高的路径，恰恰也是最慢的路径。若策略仅聚焦于 React 软导航优化，虽能改善部分体验，却无法单独推动整体感知性能达到显著提升。

图 10：按导航类型划分的 HPC 分布图（硬导航 2.05 秒，Turbo 1.76 秒，React 1.04 秒）

这一基线数据直接塑造了我们后续的架构决策：一方面提升“快速路径”的性能，另一方面降低硬导航的性能惩罚——因为绝大多数用户正承受着此处的高延迟。

需要特别说明的是：GitHub 当前仍处于从 Rails 渲染页面向 React 前端迁移的过程中。在此过渡期，许多用户操作会跨越 Rails 与 React 的边界。例如，当用户从一个 Rails 页面跳转至 Issues 页时，浏览器往往不得不执行一次完整的硬导航与冷启动。这种跨边界的跳转，正是基线中硬导航占比最高的主要原因。

我们预期，随着越来越多界面原生支持 React，硬导航的占比将逐步下降。但仅依赖平台迁移无法及时解决当前问题。因此，我们选择首先优化 React 软导航——这是我们在架构上最具即刻掌控力、且能最快交付改进效果的切入点。

在明确目标后，我们的策略也变得清晰：构建一种以本地优先（local-first） 为核心的应用模型，并采用 stale-while-revalidate（陈旧时重新验证） 策略。这意味着：优先利用本地已有数据立即渲染，最大限度降低用户可见延迟；随后异步向服务端发起校验请求，并在发现新数据时同步更新 UI。

第一步：基于 IndexedDB 的客户端缓存

我们从最具杠杆效应、同时也是未来希望承载最多流量的路径入手：React 软导航。在此路径下，运行时已处于活跃状态，主导开销通常是数据获取延迟，而非应用启动耗时。若能在重复访问时消除网络请求，即可将大量流量推入“即时”区间。

前期分析显示存在明显的重复访问模式：用户在问题排查与协作流程中，频繁重新打开相同的 Issue。基于该行为，我们预估 issues#show 的缓存命中率约为 30%，并以此作为初始可行性门槛。

具体实现是在现有内存存储基础上，扩展一层持久化的客户端缓存，底层使用 IndexedDB。

我们选择 IndexedDB 的原因如下：

提供持久化浏览器存储能力，可跨标签页关闭与浏览器重启存活，远优于纯内存存储；
采用带索引的对象存储模型，支持针对 Issue 查询负载的高效键值查找；
实际可用配额远大于 localStorage，足以支撑真实场景下的工作集规模。

在此存储层之上，我们实现了 stale-while-revalidate 语义：

读取路径：软导航时，优先尝试从本地缓存恢复数据并立即渲染；
重新验证路径：后台发起网络请求校验数据新鲜度；若服务端返回更新内容，则同步修正内存中的数据状态；
失败处理机制：在网络状况不佳时，用户仍能从缓存获得可用页面；待连接恢复后，再自动完成新鲜度校验与状态同步，由此引入了一种全新的优雅降级模型。

该架构设计的核心在于：它并非“缓存 vs 正确性”的二选一，而是以延迟优先渲染为前提，辅以同一次导航内异步一致性校验。

初期生产结果验证了该模型的有效性。在向所有用户全面推广后，约 22% 的 React 导航变为“即时”——相较上线前的 4% 显著提升——这部分导航约占总请求量的 15%。实际观测到的缓存命中率约为三分之一（~33%），与此前基于用户回访行为的分析结果一致。

主要权衡在于可控的陈旧性（staleness）。我们测得服务端与缓存之间的数据差异约为 4.7%，并将其明确界定为可接受的操作边界：对于软导航（soft navigations）所换取的显著速度提升而言，这一程度的数据不一致是可容忍的；同时我们设置了多重保障机制，以严格限制用户可见的不一致现象。

提升缓存命中率：关键突破

缓存的价值完全取决于其命中率。基于 IndexedDB 实现的 SWR（Stale-While-Revalidate，陈旧时刷新）层为我们打下了坚实基础，但三分之一的命中率也暴露了下一重瓶颈：大多数导航请求仍会在所需数据抵达客户端之前就已触发。

最直观的应对方案显而易见：尽早预取所有可能跳转的下一个议题（issue）。我们曾探索该方向，却迅速触达了真正的约束条件——问题并非实现复杂度，而是系统容量。在高扇出（high-fanout）界面（如议题列表、仪表盘、项目页及依赖关系视图）上，激进的预取会大幅增加请求数量、引发类似 N+1 的访问模式，并将大量用户最终未必打开的页面所对应的计算负载强加于系统之上。

因此，我们重新定义了优化目标：不再追求预取数据始终新鲜，而是聚焦于一个成本更低、更具扩展性的目标——确保用户点击导航链接时，已有可用数据驻留在本地。

图 13：预热（preheating）流程图。步骤包括：查看议题索引 → 对列表中每个议题触发预热请求 → 检查缓存中是否存在对应数据？若存在，则写入 IndexedDB；若不存在，则先发起网络请求获取数据，再写入 IndexedDB。

这就是“预热”（preheating）。预热会主动遍历高意图（high-intent）的议题引用，在用户导航前预先填充缓存条目；但它仅在议题数据尚未存在于客户端缓存中时才发起网络请求。一旦本地已有可用数据，预热即刻终止。这使其从根本上区别于传统预加载（preload）：它是一种缓存填充逻辑（cache-population logic），而非保新逻辑（freshness-enforcement logic）。

这是对“数据新鲜度”与“资源消耗”之间的一次显式权衡。我们愿意提供略微陈旧的数据，以换取导航本身近乎瞬时完成；因为一旦用户真正打开议题页，我们仍可在后台异步重新验证，并最终收敛至服务端最新状态。

为高效支撑该模型，我们在 IndexedDB 前引入了一层内存缓存（in-memory cache）。IndexedDB 能跨标签页与会话持久化存储，但其异步特性意味着它在关键路径上并非零开销。而内存缓存层位于活跃内存存储与持久化存储之间，使得热门议题的数据载荷可被同步读取，甚至无需支付 IndexedDB 的读取成本。实践中，这进一步消除了软导航中的一道异步边界，显著提升了直接从内存渲染页面的概率。

在运行层面，预热由高意图界面（如议题列表、仪表盘、项目页及依赖关系视图）触发。相关请求运行于低优先级 Worker 中，受到严格的速率限制，并由熔断器（circuit breaker）保护——当系统承压时，该机制会自动退避。用户主动发起的操作永远优先于推测性请求，从而避免“噪声邻居”（noisy-neighbor）问题，在保障系统稳定的同时，切实提升真实用户导航的缓存命中率。

最终效果显著：预热全面上线后，issues#show 页面的即时导航比例整体提升至约 30%；其中针对 React 导航，该比例更高达约 70%；缓存命中率则跃升至约 96%。

这一权衡完全可接受：我们仅投入少量、受控的后台资源，便将绝大多数真实用户导航彻底移出了网络延迟主导的路径。

拓展快速路径：优化 Turbo 导航与硬导航（hard navigations）

React 导航性能的提升令人欣喜，但软导航并非全部。即便 GitHub 越来越多地从 Rails 迁移至 React，硬导航（hard navigations）仍将长期存在——例如页面刷新、新开标签页、直接输入 URL 或通过外部链接进入等场景。这些“冷启动”依然至关重要，因此我们也希望缓存数据能在此类场景中发挥作用。

我们选择的机制是 Service Worker（服务工作线程）。

Service Worker 是一种由浏览器托管、独立于网页运行的脚本，可在网络请求抵达服务器前对其进行拦截。从概念上讲，它作为可编程中间人，位于浏览器与源站（origin）之间。这使其成为极少数无需依赖页面 JavaScript 运行时即可影响硬导航行为的 Web 平台原语之一。

对于 issues#show 页面，我们的 Service Worker 延续了为 React 导航构建的“本地优先”（local-first）模型。当浏览器发起某个议题页面的导航请求时，Service Worker 将首先拦截该请求，并检查议题数据是否已存在于本地缓存中。若存在，Worker 会在发出的请求中添加特定 HTTP 头，告知服务端可跳过大量冗余处理工作。

当 Service Worker 检测到缓存命中时，它会通过请求头向服务器发出信号。随后，页面导航将分为两条路径：

缓存命中路径：返回一个轻量级 HTML Shell（含布局、极简标记及 JavaScript），由 React 利用本地缓存的 Issue 数据载荷完成渲染。
缓存未命中路径：返回标准响应（服务器加载数据并执行服务端渲染 SSR）。

这是一种严格的优化策略：若缓存为空、过期，或 Service Worker 不可用，则行为自动回退至标准的服务端渲染路径。

该优化对 Turbo 导航效果尤为显著，因为 Turbo 路径仍高度受限于服务端响应时间。一旦 Service Worker 能够明确告知服务器“Issue 数据已就绪”，服务器便无需再耗时计算应用片段，从而大幅缩短后端处理时间；Turbo 几乎能立即从中受益。

图 17：Service Worker 上线后 Turbo 导航的 HPC 分布图。

硬导航（Hard Navigation）的性能提升真实存在，但其效果不如 Turbo 导航那样立竿见影：在缓存命中的硬导航中，我们以客户端渲染替代了服务端渲染。此时关键路径转变为 JavaScript 的下载与执行。

为降低这一开销，我们借助 React.lazy 实现按路由拆分代码，并结合动态路由预加载，确保仅在初始阶段获取当前路由所需的代码。我们在组件粒度上也贯彻相同原则——仅加载首屏必需的内容，非关键模块则延迟加载。例如，仅当用户进入编辑模式时才加载 Issue 编辑器代码包；同时采用基于用户意图的预取策略（如悬停触发），在不增大初始包体积的前提下隐藏加载延迟。

实际效果

在部署上述变更后，我们退后一步，整体评估其累积影响。我们分析了整个上线周期内的 HPC 指标——从最初的 IndexedDB 缓存，到预热（preheating）、内存层（in-memory layering），再到 Service Worker 的引入——趋势清晰且持续：分布正稳定地向“快速”区间偏移。

我们并未刻意挑选某一周表现优异的数据，而是考察了完整的时间窗口，以呈现近几个月来切实取得的成果。以下是所有 issues#show 流量的 HPC 百分位数据：

P10：约 600 ms → 70 ms —— 最快的导航已稳稳落入“瞬时”区间（远低于 200 ms）。
P25：约 800 ms → 120 ms —— 四分之一的导航现在可在 120 ms 内完成，相较此前接近整整一秒大幅缩短。
P50：约 1200 ms → 700 ms —— 中位数体验已跌破 1 秒门槛，从“慢速”区间跃升至“快速”区间。
P75：1800 ms → 1400 ms —— 上四分位数下降超 400 ms，显著压缩了可感知延迟的长尾。
P90：2400 ms → 2100 ms —— 即便是最慢的导航也有所改善，不过该尾部仍是下一步优化工作的最明确信号。

最突出的规律是低百分位点（P10、P25）的大幅提升。这是因为缓存命中与预热导航已主导该区间。中位数虽有实质性改善，但仍受冷启动流量影响；而高百分位尾部虽已优化，却反映出硬导航路径中 JavaScript 启动与客户端渲染已成为新的瓶颈——这正是我们下一阶段的重点攻坚方向。

数字讲述着优化的故事，但最终决定成败的是用户体验。下方视频展示了这些变更在真实会话中的实际感受——以全速在多个 Issue 间无缝切换：

后续工作

如今的 GitHub Issues 比以往任何时候都更快。无论是软导航、预热路径，还是 Service Worker 加速流程，我们都实质性地改变了用户感知延迟的分布，并将更大比例的流量推入“瞬时”区间。

与此同时，我们的工作尚未结束。依赖 SSR 的冷启动仍是现实挑战，尤其当服务端工作量减少后，客户端启动与 JavaScript 执行成本便成为主导瓶颈。

下一阶段的目标是推动更重大的变革。我们计划有针对性地重构部分后端栈，使其专为低延迟交付而优化；同时投资构建更靠近边缘（edge）的现代化 UI 分发层，进一步减少往返延迟、提升响应速度。

性能优化是一项持续的系统性投入，而非一次性项目。架构在演进，瓶颈在迁移，我们将持续迭代，直至“快速”成为所有导航路径的默认体验。

立即查阅 [GitHub Issues 快速入门指南 >](https://docs.github.com/issues/tracking-your-work-with-issues/learning-about-issues/quickstart)

* *

作者

[Alexander Lelidis](https://github.blog/author/alexus37/)

@alexus37

Alexander 是 GitHub Issues 团队的高级软件工程师，拥有计算机图形学、机器学习和地理空间软件等多元技术背景。他目前最享受的工作部分，是探索创新方式，让日常开发者工作流真正“秒开”。

更多关于 [工程](https://github.blog/tag/engineering/) 的内容

[面向无障碍的持续 AI：GitHub 如何将反馈转化为包容性](https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/)

AI 自动化处理无障碍相关反馈的初步分类，使我们能专注于修复障碍——将混乱的待办事项清单转变为持续、快速的问题解决流程。

[Carie Fisher](https://github.blog/author/cehfisher/ "Carie Fisher 的文章")

[如何成为一名出色的初级工程师：实用建议与洞见](https://github.blog/developer-skills/career-growth/how-to-thrive-as-a-junior-engineer-tips-and-insights/)

此外，还介绍了团队成员与领导者如何更好地担任新同事的导师。

[Yelyzaveta Kramarenko](https://github.blog/author/lisakr/ "Yelyzaveta Kramarenko 的文章")

探索更多 GitHub 内容

文档

掌握 GitHub 所需的一切，尽在此处。

前往文档

GitHub

在 GitHub 上构建未来——无论你来自何地、身份如何，皆可在此构建任何事物。

立即开始构建

客户案例

认识那些借助 GitHub 构建产品的公司与工程团队。

了解更多

GitHub 播客

收听 GitHub 播客——一档专注开源开发者社区内技术趋势、真实故事与文化生态的播客节目。

立即收听

我们也提供邮件通讯服务

在专为开发者打造的双周刊邮件通讯中，获取实用技巧、技术指南与最佳实践。

您的电子邮箱地址

*您的电子邮箱地址

[x] 是的，请允许 GitHub 及其关联公司使用我的信息，用于个性化沟通、定向广告及活动效果评估。详情请参阅 GitHub 隐私声明。

全站链接

[](https://github.com/)

产品

平台

支持

公司

服务条款
隐私政策
管理 Cookie
不共享我的个人信息

从延迟到即时：现代化 GitHub Issues 导航性能

TL;DR · AI 摘要

核心要点

结构提纲

思维导图

金句 / Highlights