微软Edge浏览器放弃 React,性能大幅提升?

3 views

微软Edge浏览器放弃 React,性能大幅提升?

在过去的一个月里,您可能已经注意到 Edge 的一些功能变得更快、响应更灵敏。 这是因为 Edge 正在努力从我们的一些最新功能和核心功能开始,让浏览器中的所有用户交互都变得异常快速。

从 Edge 122 开始,Browser Essentials UI 现在的响应速度更快了。 现在,Edge 用户的 UI速度提高了 42% ,而对于使用不带 SSD 或 RAM 低于 8GB 的​​设备的用户来说,UI速度提高了 76% !

收藏夹 是 Edge 的另一项功能,它在 Edge 124 中改进了 UI 响应能力。无论收藏夹是展开还是折叠,体验都应加快 40%。

这只是冰山一角。 在接下来的几个月中,我们将继续改进更多 Edge 功能的响应能力,包括历史记录、下载、钱包等。

我们希望您尝试 Microsoft Edge 并让我们知道您的想法。 告诉我们您使用 Edge 中的反馈工具的体验:单击”设置及更多(…)”> “帮助和反馈” > “发送反馈” 。

1.监控 UI 响应能力

Edge 的 UI 响应能力改进始于了解您(我们的用户)所经历的情况。 Edge 通过从最终用户计算机收集的遥测数据来监控其 UI 响应能力。 我们有意为 Edge UI 的所有部分进行此收集,而不仅仅是我们渲染的网页。 我们从这些数据中学到了什么?

  • 研究表明,用户必须满足某些绝对响应能力目标才能快速感知 UI,并且数据显示我们的 UI 可以更快地响应。

  • 我们有机会提高资源较低设备的响应能力。

我们不断了解如何提高 Edge UI 的性能,并且通过使用这些数据,我们发现了一些需要改进的领域。 例如,我们观察到许多组件使用的代码包太大。 我们意识到这是由于两个主要原因:

  • 我们在 Edge 中组织 UI 代码的方式不够模块化。 处理不同组件的团队共享公共捆绑包,即使这并不是绝对必要的。 这导致 UI 代码的一部分由于共享不必要的内容而减慢了另一部分的速度。

  • 我们的很多代码都使用依赖 JavaScript 的框架来呈现 UI。 这称为客户端渲染,在过去十年中一直是 Web 开发人员中的流行趋势,因为它帮助 Web 开发人员提高工作效率并实现更动态的 UI 体验。

按照预期渲染 Web UI

我们为什么要分享这个古老的消息? 毕竟,很多网页多年来一直在客户端呈现。 事实证明,JavaScript 必须被下载,然后通过 JIT 编译器运行(即使您不使用它),然后执行,并且所有这一切都必须在任何 JavaScript 开始渲染 UI 之前完成。 这会在用户看到 UI 之前引入大量延迟,尤其是在低端设备上。

如果你把时间机器倒转到 Web 2.0 时代之前,你会发现 Web 内容的呈现方式是使用 HTML 和 CSS。 这通常称为服务器端渲染,因为客户端以准备渲染的形式获取内容。 只要您不让 JavaScript 妨碍,现代浏览器引擎渲染此内容的速度非常快。

基于这一认识,我们的问题变成了:

  • 我们能否保持 JavaScript 框架为我们提供的开发人员生产力,同时生成快速呈现 UI 的代码?
  • 浏览器能成为它自己最好的客户吗?
  • 如果我们删除该框架并仅使用 Web 平台构建 UI,我们的制作速度有多快?

这些问题的答案是”是”、“是”和”非常快”。

WebUI 2.0 简介

微软 Edge 团队在博客文章里也承认,现代 JavaScript 框架在一些方面确实很不错,比如提高了开发者的生产力。但是他们发现,这种便捷的代价是最终用户体验的下降,浏览器速度变慢。 于是他们决定改变思路:

“我们的很多代码都使用了一个依赖于 JavaScript 来渲染 UI 的框架。这被称为客户端渲染,过去十年来,这在 Web 开发者中很流行,因为它帮助开发者提高生产力,并实现了更动态的 UI 体验。

所以,我们问自己,如果我们移除这个框架,只使用 Web 平台构建 UI,可以有多快?”

“我们希望更多网站开始朝这个方向发展:以标记为主、包体积小,并且减少用于渲染 UI 的 JavaScript 代码。” — 微软 Edge 团队

这就是 WebUI 2.0 的诞生,它是一种全新的以标记为主的架构,减少了代码包的大小,以及在 UI 初始化路径中运行的 JavaScript 代码量。

新架构更模块化,它依赖于“针对现代 Web 引擎性能进行调整的 Web Components 库”。

微软 Edge 团队也希望这种新的方向能被更多网站所采用:以标记为主、包体积小,减少用于渲染 UI 的 JavaScript 代码。

Web Components 优势是什么?

Web Components 是一套不同的技术,允许开发者创建可重用的自定义元素 —— 并且它们的功能性在 Web 上是封装的 —— 这可以在 Web 应用中使用,而不需要担心内部代码会影响到页面的其他部分或者相反。Web Components 主要由三项主要技术组成:自定义元素(Custom Elements)、阴影 DOM(Shadow DOM)和 HTML 模板(HTML Templates)。

Web Components 建立在 Web 标准之上,它们将可以在所有支持 Web 生态系统中工作,这也决定了它有巨大的优势。

Web Components 的优势包括:

  1. 封装性:通过 Shadow DOM,Web Components 的样式和脚本可以封装起来,避免与页面上的其他元素发生冲突。

  2. 重用性:开发者可以创建具有明确接口的自定义元素,这些元素可以在不同的项目和上下文中重复使用,减少重复代码的编写。

  3. 维护性:封装的组件更容易维护和更新,因为改变组件的内部实现不会影响到使用它的代码。

  4. 互操作性:Web Components 设计用于跨框架工作,这意味着你可以在不同的前端框架中使用同样的组件,如 React、Angular 或 Vue。

  5. 标准化:作为 Web 标准的一部分,Web Components 受到主流浏览器的支持,不需要额外的库或框架即可运行。

  6. 性能:由于 Web Components 是原生支持的,因此通常可以提供比传统 JavaScript 库或框架更好的性能。

  7. 简洁的 DOM:使用 Web Components 可以减少 DOM 的复杂性,因为你可以将复杂的结构和行为封装在自定义元素内部。

  8. 更好的可测试性:封装后的组件可以独立于应用的其他部分进行测试,这使得单元测试和端到端测试更加容易实施。

然而,尽管有这么多优势,Web Components 也存在一些挑战,比如浏览器兼容性问题、与现有框架的集成问题以及开发者对这一新技术的熟悉度等。随着 Web 标准的不断发展和浏览器支持的改进,这些挑战正在逐渐被克服。