我叫 Paul Kinlan，负责 Chrome 开发技术推广团队，在我的工作中，我将与一支充满热情的网络拥护者团队合作，他们致力于为我们的产品和工程团队提供真实开发者的视角，并借助目标指标提高开发者满意度。
我们深知，“满意度”是一项需要跟踪和改进的主观指标，因此在关注开发者需求的同时，我们不断探索如何发挥影响力。我们发现，以下指导原则是非常实用的：“随时随地触达开发者”。最近的一项 Stack Overflow 研究表明，75% 的开发者表示使用了框架或某种抽象概念。因此，我们一直问自己，如何为已经做出决定或无法控制其技术栈的开发者提供最佳服务？如何在不增加额外开销的情况下提高其效率？
Chrome 的一支小型团队一直在开展一个名为 Aurora 的项目，目标是使用 Web 平台的第三方抽象概念，例如框架和库。他们的目标是帮助将性能提升直接引入这些抽象，而不是让他们的客户（Web 开发者）承担责任。
在第三期的《Chrome Dev Insider》中，我采访了 Aurora 项目团队的 Addy Osmani、Kara Erickson 和 Houssein Djirdeh，详细了解了他们对这个项目的进展情况以及未来的发展方向。
内部消息：与第三方框架合作
我们先从此项目的根源说起。它是怎么来的？
Addy：Aurora 的想法很简单：我们先满足开发者的现状，帮助他们达成目标。例如，为他们选择的热门技术栈提供帮助，帮助他们提升性能。如今，许多应用开发者会使用 React、Vue 或 Angular（或者 Next.js 和 Nuxt 等元框架*）来构建应用（当然还有许多其他... Svelte、Lit、Preact、Astro。不一而足！）。我们不希望这些开发者成为深厚的专家（例如，性能方面的专家），而是默认将更多最佳实践融入到这些堆栈中，从而确保他们陷入成功。因此，单纯为网站构建网站，虽然网站质量更好，但也会带来负面影响。
Aurora 会选择一些广泛使用的框架和元框架进行合作，并记录了我们的经验（例如，如何构建良好的图像组件），以便其他人可以快速效仿，并通过 Chrome 框架基金 (Chrome Frameworks Fund) 尝试通过其他框架和工具进行扩展。虽然使用浏览器可以提升网络体验的质量，但我们认为，这一目标也可以（在某些情况下）通过框架实现。我们希望这能帮助我们实现为所有人打造更优质的网络环境的目标。
Kara：更详细地说，我们的想法是通过改善开发者体验来提高网站性能。仅仅宣传效果方面的最佳实践是不够的，因为这些最佳实践经常会发生变化，而且公司很难跟上这些最佳实践。他们有自己的业务优先事项，而这些优先事项可能先于取得成效。
因此，我们的想法是，如果开发者投入到性能上的时间有限，那我们就让开发者更轻松、更快速地构建出高性能应用。如果我们与热门 Web 框架合作，就位于正确的抽象层，通过更高级别的组件、一致性警告等来改善开发者体验。使用这些热门工具的任何人都可以享受这些好处。从理论上说，如果推荐的建议发生变化，我们可以在后台更新组件，而开发者无需为持续更新而担心。
Houssein：我加入 Google 时是一名开发技术推广工程师，几年后又转到软件工程职位。我之前的大部分工作都是向 Web 开发者传授构建出色用户体验的多种不同方法。该指南多次提供不同的版本，以提醒开发者注意那些可能影响其网站性能和易用性的常见问题。当我们开始考虑 Aurora 项目时，就问自己：我们能否朝着一个永远不需要告诉开发者要做的方向，因为他们的工具链会替他们处理一切？
如果我理解没错，你们是一个由六名工程师组成的团队，我敢打赌，您不能使用所有可能的框架或库。那么，您如何选择与谁合作呢？他们是谁？
Addy：网络在许多方面都如同狂野的西部。您可以选择所需的几乎任何框架、捆绑器、库和第三方。这会带来若干复杂程度的复杂程度，可影响性能的优劣。改进性能的最佳方式之一是让这些层能够自以为主，并添加更多意见。
例如，Web 框架（Next.js、Nuxt.js，在某种程度上 Angular）会尝试纳入更多观点和默认做法，而不是更手动的解决方法。这也是我们喜欢与他们合作的原因之一！在这些模型中，为如何加载图片、字体和脚本设定更严格的默认设置有助于改进 Core Web Vitals。
这也有助于确认现代最佳实践的可行性或是否需要重新考虑，并且有助于让整个生态系统了解如何解决优化问题。
Kara：事实上，我们还要考虑受欢迎程度。如果我们希望产生尽可能大的 Web 影响，那么与已经拥有庞大的开发者社区的框架和库合作是理想的方式。通过这种方式，我们可以吸引更多开发者并推广更多应用。但这不能只是热门程度。归根结底，它是热门程度、库的专业性以及我们可以使用的功能集的交集。
例如，如果只看热门程度，React、Vue 和 Angular 就是需要考虑的“三大因素”。但我们最常与 Next.js、Nuxt 和 Angular 合作。这是因为 React 和 Vue 等视图库主要侧重于渲染，因此不可能将我们想要的所有功能直接构建到它们中。因此，我们与基于这些框架构建的专业元框架（Next.js 和 Nuxt）展开了更密切的合作。在此抽象级别，我们可以创建内置组件。它们还具有内置服务器，因此我们可以纳入服务器端优化措施。
您可能会注意到，Angular 位于这一深度合作伙伴关系列表中，但并不是元框架。Angular 在某种程度上属于特殊情况，因为它很受欢迎，但没有 React 和 Vue 那样具有补充的元框架。因此，我们直接与它们合作，并尽可能通过它们的 CLI 贡献功能。
值得注意的是，我们与 Gatsby 等其他项目有持续的合作关系，我们会定期对设计进行同步，但不会积极贡献代码。
那么，这在实践中是怎样的呢？您采用什么方法解决这个问题？
Kara：在实践中，我们与几个框架密切合作。我们将花些时间分析使用该框架的应用，并找出常见的性能痛点。然后，我们与框架团队合作设计实验性功能以解决这些痛点，并直接向 OSS 代码库贡献代码以实现这些功能。
我们必须验证性能影响是否符合我们的预测，这一点非常重要，因此我们还与外部公司合作，在生产环境中进行性能测试。如果结果令人鼓舞，我们会帮助该功能变为“稳定”状态，并可能将其设为默认功能。
这一切都不可能像您说的那样简单。到目前为止，您遇到过哪些挑战或收获了哪些经验？
Houssein：我们会尽最大努力为热门开源代码库做出贡献，但这些代码库有许多相互冲突的优先事项，这一点很重要。虽然我们是 Google 团队，但这并不一定意味着我们会优先考虑我们的功能。因此，我们会尽最大努力与建议和发布新功能的典型流程保持一致，而不会强制任何人这样做。我们非常幸运地与 Next.js、Nuxt 和 Angular 生态系统中的接收性维护人员合作。我们非常感激他们乐于倾听我们对于网络生态系统的担忧，并愿意通过多种方式与我们合作。
在我们使用的许多框架中，我们的整体使命是相同的：开发者如何在获得开箱即用的用户体验的同时，获得出色的开发者体验？我们认识并尊重，有数百名（甚至是数千名）的社区贡献者和框架维护者在从事彼此交叉的不同项目。
Kara：此外，由于我们非常重视验证效果影响并根据数据采取行动，所以这个过程需要更多时间。我们处于未知的领域，所以有时我们会尝试优化功能，但结果不会成功，我们最终也未打造出计划推出的功能。即使某个功能最终走向成功，但评估性能的这几个额外步骤也需要时间并需要更长的时间。
而寻找制作合作伙伴来测试我们的功能也并非易事。正如前面提到的，他们都是公司，有自己的优先要务，因此，如果它们不能很好地配合必须优先考虑的现有项目，那么他们很难采用新的计划。此外，最感兴趣的公司往往已经花时间投资提升效果，因此他们并不是我们的目标受众群体。我们正尝试从广大社区中收集反馈，这些人无法在效果方面投入精力，但也不太可能与我们联系。
接下来，您关注哪些优化措施？
Houssein：在分析数千个应用后，我们发现最大的性能问题通常是应用代码中的反模式导致的，而不是框架本身造成的。例如，发布不必要的大型图片、加载自定义字体太晚、提取过多会阻塞主线程的第三方请求，以及未处理异步内容如何导致网页上其他内容发生变化。无论你使用什么工具，都可能会出现这些问题。因此，我们想：是否可以加入一些默认的优化措施，在妥善处理这些问题的同时，为他们的框架工具提供恰到好处的开发者体验？
秉承这一理念，我们已经推出了：
- Next.js 图片组件。
- Next.js 脚本组件。
- Next.js 构建流程中的自动字体内嵌。
- Angular 图片指令。
- Next.js 一致性 ESLint 插件：为开发者提供切实可行的指导。
我们的工作启发了其他框架和工具实现类似的优化。其中包括但不限于：
- Nuxt 图片模块
- Nuxt 字体指标替换值
- Nuxt 脚本组件（进行中）
- Gatsby 脚本组件
您能否与部分参与者分享自己的工作成果？
Houssein：由于我们实施了各种优化措施，很多网站的性能得到了提升。我最喜欢的一个例子是 Leboncoin，他在切换到 Next.js 图片组件后，将 LCP 从 2.4 秒降低到了 1.7 秒。目前还有许多其他产品尚处于实验和测试阶段，我们将继续在此处分享经验教训和成果。
好的，我知道您的重点是最受欢迎的框架或库，但那些您未主动合作的其他框架或库是否也会受益于其他方法？
Addy：Aurora 协作进行的许多性能优化都可以由任何框架复制。我们来看一下图片组件或脚本组件的设计工作，例如，他们通常会将一套现有的最佳实践标准化。我们尝试记录构建此类组件的“方式”及其在每个框架中的外观。希望这是一个良好的开端，让我们得以照搬创意。
我们已经从一个生态系统（例如 React 和 Next.js）中汲取经验并运用到了其他生态系统中，取得了很好的成效。例如，新的 Angular 图片指令（根据我们构建 Next.js 图片组件的经验构建）或 Gatsby 将我们的精细 JavaScript 分块方法付诸实践。
与此同时，我们理解，并非每个框架都有足够的带宽或资金来支持贡献者构建类似的性能功能，或投资于他们认为对用户重要的其他优化。我们可以通过 Chrome Web 框架基金为 JavaScript 生态系统中的绩效工作提供资助，让项目能够向贡献者支付报酬，并使绩效工作能够在该生态系统中进一步扩展。
您的团队未来有哪些计划？
Kara：接下来会有很多令人兴奋的项目！改版后的网站具有以下亮点：
- 减少与字体相关的 CLS：在加载网页字体并替换回退字体时，出现布局偏移的情况是很常见的。我们正在探索如何使用字体指标替换项和“size-adjust”属性在 Next.js 中默认减少与字体相关的 CLS。我们也一直在与 Nuxt 团队就此问题进行商讨，并计划明年将此想法推广到更多框架。
- 调试 INP：现在，Interaction to Next Paint (INP) 指标已发布，我们正在与框架合作，为社区调查导致 INP 问题的最常见根本原因，并提出修复建议。我们一直在与 Angular 合作，并希望很快能与大家分享一些成果！
- 优化常见的第三方脚本：在错误的时间加载第三方脚本可能会对性能产生重大不利影响。由于有一些非常常见的第三方，我们正在研究是否可以为这些第三方提供一些封装容器，以确保它们通过框架以最佳方式加载，并且不会阻塞主线程。我们将使用构建的 Next.js 脚本组件作为此次调查的起点。
开发者可以在此网站上跟踪我们的进度。
资讯
在结束之前，我想先为大家介绍几个关于 Google 框架领域的有趣更新。
7 月，Chrome 团队宣布为框架和工具基金提供最新一轮 50 万美元的资金，用于资助旨在改善 Web 性能、用户体验和开发者体验的项目。未来我们将考虑新项目，因此请务必提交申请。
当然，社区中也有很多令人惊叹的事情。这个生态系统已经成熟，拥有诸如 Deno 的 Fresh 等新框架，以及 Svelte 的新手入门教程等很棒的体验，该教程不仅在浏览器中演示，还使用 Web Container API 在浏览器中以原生方式运行 Node.js。有这么多好东西！
看到整个生态系统齐聚一堂、推动浏览器实现无限可能，并帮助开发者打造适合所有人的产品，我感到非常兴奋。这是一个激动人心的 Web 开发者时刻。
直到下一位达人“哈利·弗尔”才知道。
您对这一期的《Chrome Dev Insider》有何看法？欢迎分享反馈。