后端开发教程 - Java、Spring Boot 实战 - msg200.com
如何说服客户关注 Web 性能：案例研究
构建概念验证（PoC）
结论
对于我在Netcentric工作的客户来说，Web 性能确实是我每天关注的问题之一。
有时说服他们关注网络性能并非易事：我们永远不清楚与我们付出的努力相比会获得什么收益，而且您可能已经知道，网络性能完全取决于测量。
当我们决定为客户实现某项功能时，可能需要数周时间才能看到其实际效果并最终衡量改进效果，并且总是存在回报不如我们预期的风险。
我想向一位客户表明，我们应该专注于优化<head>他们页面中某个部分的内容，但我又一次无法凭着自己的“感觉”认为这会对他们的业绩有好处。我想向他们展示一些真实的数据，帮助他们相信这是一个重要的话题。
幸运的是，今天我找到了一套可以帮助我实现目标的工具。
构建概念验证（PoC）
谈到 Web 性能时，首先要做的就是了解当前状态，这样我们才能轻松地看到工作前后的比较。
Chrome DevTools 的“性能”选项卡提供了许多非常有趣的信息，但有时可能很难理解，特别是对于不太懂技术的人来说，它提供的所有信息如下：
因此，我决定使用性能 API的一些自定义指标来大致了解我正在审核的页面上哪些地方耗时。
第一步是转到我们客户端的主页并使用 Chrome 的 Overrides 功能注入我自己的 Javascript。
首先，我打开 Chrome DevTools，转到“ Sources ”选项卡，然后转到“ Overrides ”面板：
从这里，我点击“ +选择要覆盖的文件夹”并选择我刚刚创建的空文件夹（您也可以直接从对话框中创建一个新文件夹）。
一旦选择，Chrome 会提示您允许访问该文件夹，因此请不要忘记点击“允许”按钮：
然后，从“来源”选项卡，我转到“页面”面板并打开我的主要 HTML 文件（在我的情况下为 en.html）：
在右侧，我可以注入 JavaScript 代码来获取自定义指标。我使用了两个函数：performance.mark()和performance.measure()。
Performance API 非常容易使用，例如：
// Start your measure
performance.mark('begin');
// Put everything you want to measure between the marks
// Stop your measure
performance.mark('end');
// Calculate the time difference between your 2 marks
performance.measure('diff', 'begin', 'end');
// View the results in the Performance tab
// or output the results in the console using:
console.log(performance.getEntriesByType("measure"));
您应该在控制台中看到类似这样的内容：
最后，我的页面的代码结构如下：
在 HTML 中注入性能标记后，我切换到“性能”选项卡，确保选择了“快速 3G ”网络和CPU “ 4 倍减速”，最后单击“开始分析并重新加载页面”：
几秒钟后，我看到了包含一些有趣信息的报告。我想检查的是“时间”面板，在这里我可以找到我的自定义指标以及 Chrome 提供的一些默认用户指标，例如首次内容绘制(FCP)、首次有意义绘制(FMP)、最大内容绘制(LCP) 等等。
我看到的是，解析该部分约 50 行<head>花费4.40 秒（CSS 1.85 秒 + JS 2.55 秒），而解析该部分约 1300 行仅花费0.97秒。<body>
这样，我就有了一个衡量改进的基准。是时候优化了！
我测试的第一个优化是defer向我的 Javascript 文件添加一个属性：
回到我的“ Sources ”选项卡，我打开 HTML 文件并添加了defer属性，然后运行了一个新的“ Performance ”测试：
再次检查“时间”面板，我现在几乎看不到 JS 解析时间，它下降到了8.66ms。总<head>时间也下降到了1.65s，其中大部分时间现在只花在了 CSS 上。
现在我想看看是否也能减少 CSS 的开发时间。于是我打开了“覆盖率”选项卡（cmd+shift+p），打开后点击了“开始检测覆盖率并重新加载页面”：
因为我只想查看 CSS 覆盖率，所以我使用了过滤器.css，结果显示我加载的 CSS 中有 92% 未被使用。（当你开始与页面交互时，未使用的字节数会实时变化）：
加载了这么多数据却毫无意义，我想知道删除未使用的 CSS 是否能带来一些好处。为了实现这一点，我找到了一些解决方案和工具，例如Purgecss、uncss或PurifyCSS，它们可以帮助我删除主页上所有未使用的 CSS。我决定使用 PurifyCSS，因为它提供了一个简单的用户界面，足以满足我的 PoC 需求。
使用这个工具，只需输入你网站的 URL，然后点击“清理 CSS ”即可。（我没有测试这个工具的准确度，因为我只是想大致了解一下我的情况）。
完成后，我点击“显示干净的 CSS 代码”按钮并复制新的 CSS。
回到我的 DevTools 和“ Sources ”选项卡，“ Page ”面板，我选择了我的 CSS 文件，粘贴了上一步中得到的清理后的 CSS 代码并保存了我的更改（ctrl+s）。
最后，我进行了另一项“性能”测试：
最终，仅经过这两项优化，解析该<head>部分仅需 0.63 秒，其中大部分时间都花在了 CSS 上（0.61 毫秒）。考虑到我们的基准指标是 4.40 秒，总优化幅度约为 85%！
结论
这个 PoC 的目标是说服我们的客户专注于 Web 性能，而无需经历需要数周时间且无法保证收益的整个内部开发过程。
我花了两个小时准备这个概念验证，但实际开发需要几周时间。由于所有基线测量都已完成，我们准备上线时可以再次进行测量，并查看最终的实际收益。
鏂囩珷鏉簮锛�https://dev.to/armelpingault/how-to-convince-your-client-to-focus-on-web-performance-a-case-study-3ma7