如何使用 GitLab CI 和 Hoodoo of GitLab Artifacts 使性能可见
仅仅优化应用程序是不够的。您需要防止性能下降，而要做到这一点的第一步就是让性能变化可见。在本文中，Anton Nemtsev 展示了几种在 GitLab 合并请求中显示它们的方法。 性能下降是我们每天面临的问题。我们可以努力让应用程序快速运行，但我们很快就会回到开始的地方。发生这种情况是因为添加了新功能，并且我们有时不会重新考虑不断添加和更新的包，或者考虑代码的复杂性。一般都是小事，但还是都是小事。 我们无法承受缓慢的应用程序。绩效是一种竞争优势，可以带来并留住客户。我们不能经常花时间重新优化应用程序。它成本高昂且复杂。这意味着，尽管从业务角度来看，性能带来了所有好处，但它几乎无法盈利。作为解决任何问题的第一步，我们需要让问题变得可见。本文将帮助您解决这一问题。
注意：如果您对有基本的了解
并且关心应用程序的性能或它可以带来的业务优势，那么我们就可以开始了。 如何为项目创建绩效预算 # 我们应该问自己的第一个问题是： “什么是绩效项目？” “我应该使用哪些指标？” “这些指标的哪些值是可以接受的？” 指标选择超出了本文的范围，并且在很大程度上取决于项目上下文，但我建议您首先阅读Philip Walton撰写的以用户为中心的绩效指标。 从我的角度来看，使用 澳大利亚手机号码列表 库的大小（以千字节为单位）作为 npm 包的度量是一个好主意。为什么？嗯，这是因为如果其他人将您的代码包含在他们的项目中，他们可能希望最大限度地减少您的代码对其应用程序最终大小的影响。 对于该站点，我将第一个字节的时间 (TTFB)视为一个指标。该指标显示服务器响应某些内容所需的时间。这个指标很重要，但相当模糊，因为它可以包括任何内容——从服务器渲染时间开始到延迟问题结束。因此，最好将它与服务器计时或OpenTracing结合使用，以找出它到底包含什么。 您还应该考虑交互时间 (TTI)和首次有意义的绘制（后者很快将被最大内容绘制 (LCP)取代）等指标。我认为从感知绩效的角度来看，这两点都是最重要的。 但请记住：指标始终与上下文相关，因此请不要认为这是理所当然的。考虑一下在您的具体情况下什么是重要的。
下在您的具体情况下什么是重要的
是利用您的竞争对手，甚至您自己。此外，有时，诸如性能预算计算器之类的工具可能会派上用场 – 只需稍微使用一下即可。 性能下降是我们每天面临的问题。我们可以努力让应用程序快速运行，但很快我们就会回到开始的地方。 “ 利用竞争对手为您谋取利益 # 如果你曾经碰巧逃离了一只狂喜过度兴奋的熊，那么你已经知道，你不需要成为跑步奥运会冠军来摆脱这个麻烦。你只需要比其他人快一点就可以了。 所以列一个竞争对手名单。如果这些是相同类型的项目，那么它们通常由彼此相似的页面类型组成。例如，对于网上商店，它可能是包含产品列表、产品详细信息页面、购物车、结账等的页面。 衡量竞争对手项目的每种类型页面上所选指标的值； 在您 AERO领先 的项目上衡量相同的指标； 在竞争对手的项目中找到比您的值更接近的每个指标。添加 20% 并设定为您的下一个目标。 为什么是20%？这是一个神奇的数字，据说意味着肉眼可以明显看出差异。
