GitHub的UI最近变得越来越慢，作者通过开发工具分析发现，从“Conversation”切换到“Files changed”标签页需要超过5秒，而直接在新标签页打开“Files changed”反而快两倍。GitHub使用Turbo预加载页面以优化性能，但实际效果却适得其反，作者对此感到困惑并质疑开发团队是否注意到这一问题。

GitHub界面为何越来越慢？

最近，我不得不注意到GitHub的用户界面变得越来越慢。以前一些操作非常流畅，现在却变得异常缓慢。GitHub似乎在做一些奇怪的事情，我实在无法理解其中的原因。

GitHub的开发团队，你们也在使用GitHub进行开发吧？难道你们没有发现这个问题吗？到底发生了什么？

每当我遇到一个慢得让人抓狂的网站时，我都会打开开发者工具进行分析。谁知道呢，也许我能发现一些问题并报告，问题就能得到解决。

举一个典型的例子，当我在一个PR（Pull Request）中从“Conversation”标签切换到“Files changed”标签时，整个过程竟然需要超过5秒。在2025年，这样的速度实在是难以接受。

深入分析后，我发现GitHub使用了Turbo来预加载下一页内容，并在不重新加载页面的情况下替换内容。这通常是为了优化性能，但在这里，我们看到的却完全相反。

如果你在家尝试并操作一下，你会发现在新标签页中打开“Files changed”链接实际上要快两倍：

不仅如此，第一个分析中的客户端后处理时间实际上比从服务器加载HTML的时间还要长。这一切都毫无意义。

最让人抓狂的是新的加载进度条，它不断提醒我整个过渡过程有多慢：

伙计们...你们能不能让过渡过程变得更快，以至于根本不需要这个加载进度条？单页应用（SPA）的初衷就是为了避免这种情况。客户端路由应该是即时的。

这只是GitHub众多性能问题中的一个。以前并不是这样的。现在，浏览多个PR和问题简直是一种折磨。想象一下，你有20个PR要查看，找出哪个引入了回归问题，而每次点击都需要超过5秒才能显示内容。

更别提差异视图本身了——是的，那个在浏览大型PR时会周期性地冻结2秒的视图——也许这与它渲染了数千个带有相同内联SVG图标的不可见加号按钮有关：

或者，也许不尝试渲染100,000个DOM节点也会有所帮助。

当你调整开发者工具窗口大小时，整个窗口会冻结3秒，因为你想要分析这个问题。

这种情况会有所改善吗？🔗

也许，当一些热门问题与性能相关，而GitHub在路线图中有一个看似相关的"大规模平台协作"重点领域时，这种情况会有所改变？

让我们看看路线图，看看是否能找到任何相关的性能内容。你找到了吗？

• JavaScript风格优化大小
• 浏览器中JavaScript性能的基本规则

评论总结：

1. 性能下降：

   • 多数评论指出GitHub的性能显著下降，尤其是在React重写后，页面加载和渲染速度变慢，甚至出现功能失效的情况。
     • "Githubs performance has been rapidly degrading ever since they started rewriting everything in React." (评论2)
     • "The code viewer is completely unusable for any file longer than a hundred lines." (评论7)

2. 前端开发问题：

   • 一些评论认为前端开发团队经验不足，导致用户体验变差，尤其是SPA（单页应用）的设计问题。
     • "It’s very obvious that they’ve unleashed a bunch of very junior developers on front end." (评论3)
     • "Obviously if you use any kind of javascript on such website things go to hell." (评论16)

3. 微软收购的影响：

   • 部分评论将问题归咎于微软的收购，认为微软的服务普遍缓慢且质量不佳。
     • "Because Microsoft bought them." (评论5)
     • "Have you used any other Microsoft web services? They’re all slow and terrible." (评论9)

4. 用户体验的恶化：

   • 用户反映GitHub的UI变得迟钝，功能不稳定，甚至影响了日常使用。
     • "It’s very frustrating to have a tool that has spent 15 years fading into the background of reliable infrastructure become an intrusive, distracting mess." (评论10)
     • "My PC hangs as soon as any 'dynamic' javascript button starts to load!" (评论26)

5. 替代方案的讨论：

   • 一些用户开始寻找替代方案，如自托管Git服务或其他Git托管平台，以规避GitHub的性能问题。
     • "If you just need a place to store your code, self-hosted Gitea is very easy." (评论19)
     • "I’m building a new Git hosting service, focused on performance and using HTMX." (评论23)

6. 开发文化的反思：

   • 评论指出，前端开发文化倾向于“先发布，后优化”，导致性能问题被忽视。
     • "In web development, frontend product devs are not incentivized to make features fast." (评论27)
     • "There is a whole new paradigm in UX design now: get rid of immediate page changes and loading states." (评论28)

总结：

评论普遍认为GitHub的性能和用户体验在React重写和微软收购后显著下降，尤其是前端开发和SPA设计问题成为焦点。部分用户开始寻找替代方案，并对开发文化中的“先发布，后优化”模式提出批评。