javascript - Angular 2 如何改善 Internet Explorer 11 上的 DOM 绘制时间

Question

在 Internet Explorer 11 上提高 Angular 2 应用程序性能有什么特别的技巧吗？

我们的网站在 Chrome 和 Firefox 中都能正常运行，但 DOM 在 IE 11 上的渲染速度明显很慢。我理解其中一些是浏览器引擎的限制，但是当单个更改检测周期导致 30-40 毫秒的 DOM 绘制时IE 11，我觉得我们的实现还可以做一些其他事情。郑重声明，Chrome 绘制 DOM 的时间从不会超过 1 毫秒，因此 IE 的行为比对应的浏览器慢大约 30 到 40 倍。

这是在我们的本地主机实例上为 DOM 事件(滚动)拍摄的性能监控的 IE11 快照。

将此与同样使用 Angular 2 的 The Guardian 等网站进行比较。他们网站的 DOM 事件处理时间几乎总是低于 2 毫秒，并且他们在 DOM 上显示的内容比我们的复杂得多。

这让我想到有一些特别适合 IE 11 的优化技术。以下是我们迄今为止尝试过的事情的列表:

1. 已从 SystemJS 迁移到 Webpack。有助于提高初始加载速度，但不会影响 DOM 绘制持续时间。
2. 我们使用 core-js 而不是 es6-shim
3. 使用纯管道进行格式化并避免从模板调用任何函数。

欢迎提出任何建议。

Answer 1

不幸的是，Angular 做的不止一件事会导致 IE 出现问题。 Angular 在 DOM 树操作和子/父节点跟踪方面做了大量工作，而 IE 的 DOM 树并不是……真正的树。 Angular 在 IE 和 Edge 上的很多性能问题都来自于它的变化检测周期——这让 Angular 1.X 非常酷，但也让它因尺寸变得笨拙而臭名昭著。

Angular 2+ 为解决此问题做了很多工作，包括为开发人员提供多种选择来更改此检测策略以最适合这种情况。

变更检测策略

Here's一个很好的资源来探索这个。将 ChangeDetectorRef 服务的检测策略更改为“ChangeDetectionStrategy.OnPush”将导致 Angular 仅在组件输入 上运行更改检测。如果您在深层嵌套的组件中有很多静态信息，而没有从深层嵌套中冒出的事件，这可能是一个很大的加速——但是，您将需要在需要时手动调整更改检测或手动调用更改检测根据需要进行扫描 - 并不像听起来那么糟糕，并且会提高所有平台的性能。

分离变化检测器

更大的性能提升是在用户执行会触发大量不必要的变化检测的操作(例如单击和拖动)时完全分离变化检测器。这可以战略性地用于显着提高性能，但如何实现它会因应用程序而异。

跑到外 Angular

这可能看起来很熟悉，但是如果您有很多影响 UI 的计算量大的任务，您可以使用 NgZone 在 Angular 的“区域”之外运行逻辑。可能对 IE 没有太大影响，但仍然是一个很好的做法。

NgFor 跟踪

NgFor 比旧的 ng-repeat 性能要好很多，但它仍然不完美，尤其是在重绘方面(咳咳 IE 咳)。由于它的 DOM 树实际上并不是一棵树，因此这可能会对 IE 性能造成很大的影响。默认情况下，NgFor 会为 repeat 拆除整个 DOM 树，并在对其数据进行任何微小更改时重建它。为 NgFor 提供一个 trackBy 函数，允许它只在需要更改的地方更新 DOM，从而提高速度(尤其是当您有复杂/大量重复的元素时)。

AOT编译

比任何特定于平台的东西都更普遍，但无论如何绝对是个好主意。配置您的应用程序以进行提前编译，从构建应用程序中取出 Angular 编译器，并在构建时完全呈现模板。它可以大大减少负载和渲染时间，如果您有可以用最少的外部数据构建的大型复杂模板，它的影响力甚至会更大。使用 Webpack 或 SystemJS(与 CLI 相对)很痛苦，但值得。查看官方文档 here

其他

您的问题可能与 Angular 根本无关 - IE 在表格渲染和某些样式情况(例如在页面渲染后计算元素的动态宽度)等方面存在性能问题。请务必研究您的应用实现的任何问题。

祝你好运!