我觉得这真的很有用对吧

rmruhul

为你的字面意思是我们想要测量用户进行的第一次交互的延迟和交互性，但它确实缺乏一点上下文，对吧？因为有些……很多事情都会影响它，因为它不一定总是与 JavaScript 相关。第一个输入延迟可能代表聚焦表单字段所引起的延迟，对吧？那种类型的东西，HTML 中的东西。我认为这些指标……诸如首次输入延迟之类的指标可以……如果您可以将它们与长任务 API 中的条目、元素计时以及这些类型的事物结合起来，那么它们可能会很有用。我最终认为，核心网络生命力的未来将证明它将有助于衡量良好的用户体验。这是我个人的看法。

德鲁：我想是的，这是你总是可以衡量自己的事情之一，衡量你自己 电报号码数据 的进步，或者如果你的分数发生变化，你的体验是否会变得更糟，不要太关心交通信号灯，而是关心你对交通灯的了解您网站的上下文以及更改如何带来改进。

杰里米：我认为诸如累积布局偏移之类的指标非常好，但它们也可以从一点点改进中受益。就目前而言，累积布局偏移主要测量加载期间发生的布局偏移。我们知道，当用户访问页面并登陆页面时，布局随时可能发生变化，对吧？因此，我认为肯定可以做一些工作来改善我们观察这种现象的方式。

德鲁：我认为布局稳定性是当您使用渐进增强时实际上更难实现的事情之一。有时，当您加载服务器渲染的页面然后开始在客户端中增强它时，可能会存在创建此类布局转换的危险，不是吗？

杰里米：绝对地。这就是组件水合变得有点棘手的地方，因为该组件的尺寸可能会因多种原因而改变。就像客户端组件中存在的内容可能不会在服务器上呈现一样，因为在客户端上执行之前不会评估状态。这是一个极其困难的问题。我不会坐在这里假装我已经找到了解决这个问题的灵丹妙药。



德鲁：我想谈谈动态导入和代码分割，这两种技术都是针对在体验开始时预先下载和执行大量 JavaScript 问题的不同技术。提出大量小请求是否存在过度优化的风险，特别是在最简单的小型项目上，或者从一开始就预防您将遇到这些问题而实施这种做法绝对没有坏处？或者您应该等到真正看到性能问题后再考虑这些事情吗？

杰里米：所以我建议你刚才所说的尾部是一个很好的引导方式。我们不应该尝试过早优化，除非这些优化可以非常快速、轻松地实现，但是如果在早期并没有真正存在很多性能问题的情况下花费大量精力进行优化，我认为代码分割可能是不必要发生的事情。您可能可以预先加载该功能。

杰里米：但例如，我在书中谈到了这一点。如果您有一个由大段 JavaScript 驱动的高价值交互，对我来说，大段 JavaScript 可能意味着 20 KB，因为通过网络进行压缩，最终可能会变成 60 KB 的 JavaScript 块。然后，如果您可以将其放在主捆绑包或无数捆绑包中的任何一个上，您的网站可能会发布，您将有助于提高启动性能。