我是 Paul Kinlan，负责 Chrome 的开发者关系。作为一名 Web 倡导者，我与一支充满热情的团队合作，他们负责向产品和工程团队传达真实开发者的观点，以提高开发者满意度为首要指标。
我们知道，“满意度”是一个雄心勃勃且主观的指标，因此我们会不断迭代，在专注于开发者需求的同时，寻找有助于提升满意度的做法。我们发现，一个有用的指导原则是“满足不同开发者的需求”。Stack Overflow 最近的一项研究表明，75% 的开发者表示使用框架或某种抽象。因此，我们一直在思考如何为已做出技术栈决策或无法控制技术栈的开发者提供最优质的服务？如何在不增加开销的情况下提高他们的工作效率？
Chrome 团队中有一个小团队一直在致力于一个名为 Aurora 的项目，其目标是使用 Web 平台的第三方抽象（例如框架和库）。他们的目标是直接帮助这些抽象实现性能提升，而不是让客户（Web 开发者）承担这方面的负担。
在 Chrome 开发者内幕第 3 期中，我与 Project Aurora 团队的 Addy Osmani、Kara Erickson 和 Houssein Djirdeh 进行了对话，详细了解了他们是如何开展这项工作的，以及未来的计划。
内幕消息：使用第三方框架
我们先从该项目的起源开始。它是如何产生的？
Addy：Aurora 的初衷很简单：我们要迎合开发者的现状，帮助他们实现所需目标。例如，帮助他们选择的热门技术栈提升性能。如今，许多应用开发者都使用 React、Vue 或 Angular 构建应用，或者使用 Next.js 和 Nuxt 等元框架*（当然还有许多其他框架）。Svelte、Lit、Preact、Astro。等等）。我们可以默认在这些堆栈中内置更多最佳实践，而不是期望这些开发者成为深度专家（例如在性能方面），从而确保他们能轻松取得成功。这样一来，只需针对 Web 构建网站，就能顺便获得更优质的网站。
Aurora 会选择一些广泛使用的框架和元框架进行合作，并记录我们的学习成果（例如如何构建优质的图片组件），以便其他人可以快速跟进，并尝试通过 Chrome 框架基金通过其他框架和工具进行扩展。虽然可以通过浏览器改进 Web 体验质量，但我们认为，在某些情况下，也可以通过框架来实现这一目标。我们希望这有助于我们实现让所有人都能享受更优质网络体验的目标。
Kara：具体而言，我们的目标是通过改善开发者体验来提升 Web 性能。仅公开效果方面的最佳实践是不够的，因为这些最佳实践经常会发生变化，而企业很难跟上这些变化。他们有自己的业务重点，这些重点可能比效果更重要。
因此，我们的想法是，如果开发者投入在性能方面的时间有限，我们就应该让他们更轻松（更快）地构建高性能应用。如果我们与热门 Web 框架合作，就可以通过更高级别的组件、合规性警告等，在合适的抽象层面改善开发者体验。使用这些热门工具的任何人都可以获享这些好处。从理论上讲，如果建议的建议发生变化，我们可以在后台更新组件，开发者无需担心保持最新状态。
Houssein：我最初加入 Google 时是一名开发者倡导者，几年后转为软件工程师。我之前的大部分工作都涉及教 Web 开发者如何通过多种不同的方式打造出色的用户体验。我们反复提供相同指南的不同版本，以提醒开发者可能影响其网站性能和易用性的常见问题。在开始构思 Aurora 项目时，我们问自己：能否朝着这样的方向发展，即开发者的工具链会为他们处理一切事宜，而我们无需告诉他们该做什么？
如果我没理解错的话，你们团队有 6 位工程师，对吗？我敢打赌，您不可能使用所有可能的框架或库。那么，您如何选择合作伙伴？他们是谁？
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：在实践中，我们有几个框架需要密切协作。我们将花些时间使用该框架对应用进行性能分析，并找出常见的性能问题。然后，我们会与框架团队合作设计实验性功能来解决这些痛点，并直接向开源软件代码库提交代码以实现这些功能。
验证性能影响是否与我们预测的一致非常重要，因此我们还会与外部公司合作，在生产环境中进行性能测试。如果成效喜人，我们会帮助该功能进入“稳定”阶段，并可能将其设为默认功能。
这一切并非像您所说的那样简单。您目前为止遇到了哪些挑战或学到了哪些知识？
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 Image Directive（基于我们在构建 Next.js Image 组件时获得的经验）或 Gatsby 发布了我们的精细 JavaScript 分块方法。
同时，我们也理解，并非每个框架都有足够的带宽或资金来支持贡献者构建类似的性能功能，或投资于他们认为对用户重要的其他优化。Chrome Web 框架基金是我们赞助 JavaScript 生态系统中性能工作的方式，旨在帮助项目向其贡献者支付报酬，并让性能工作在生态系统中进一步扩展。
那么，您的团队接下来有什么计划？
Kara：我们即将推出许多令人兴奋的项目！改版后的网站具有以下亮点：
- 减少与字体相关的 CLS：在 Web 字体加载并替换后备字体时，出现布局偏移是很常见的。我们正在探索在 Next.js 中默认使用字体指标替换项和“size-adjust”属性来减少与字体相关的 CLS。我们还就此咨询了 Nuxt 团队，并计划在明年将此想法扩展到更多框架。
- 调试 INP：Interaction to Next Paint (INP) 指标现已发布，我们正在与框架合作，为其社区调查 INP 问题的最常见根本原因，并提出相应解决方法。我们一直在与 Angular 密切合作，希望很快就能分享一些成果！
- 优化常见的第三方脚本：在错误的时间加载第三方脚本可能会对性能产生重大负面影响。由于有一些第三方库非常常用，因此我们正在研究是否可以为这些库提供一些封装容器，以确保它们以最佳方式与框架加载，并且不会阻塞主线程。我们将使用我们构建的 Next.js 脚本组件作为此调查的起点。
开发者可以访问此网站，跟踪我们的进度。
新闻报道
在结束本讲之前，我想向大家介绍一些 Google 框架领域的最新动态。
7 月，Chrome 团队宣布为框架和工具基金提供最新一轮 50 万美元的资助，该基金专门用于资助旨在帮助提升网络性能、用户体验和开发者体验的项目。未来的资助将考虑新项目，因此请记得提交申请。
当然，社区中还会发生许多精彩的事情。该生态系统中充斥着 Deno 的 Fresh 等新框架，以及 Svelte 的新手入门教程等出色的体验。该教程不仅是一个浏览器内演示，还使用 Web Container API 在浏览器中原生运行 Node.js。太多好东西了！
看到整个生态系统协同发展，不断推动浏览器的可能性，并帮助开发者打造适合所有用户的产品，我感到非常兴奋。对 Web 开发者而言，这是一个令人振奋的时代。
期待下次与您见面，Hwyl fawr。
您对本期《Chrome 开发者内幕》有何看法？欢迎分享您的反馈。