编写高性能代码并不是那么重要，因为对于宏观计划通常没有什么影响。50k ops/s 听起来好于 1k ops/s，但在大多数情况下整体时间并不会有所改变。
解析、编译和执行
从根本上说，大多数 JavaScript 的性能问题，并不在于运行代码本身，而是在代码开始执行之前必须采取的一系列步骤。
我们在这里讨论抽象层次的问题。计算机上运行的大多数代码都是编译后的二进制格式。意思是说，除了所有的操作系统级别的抽象外，代码都可以在硬件上本地运行，不需要准备工作。
JavaScript 代码不是预编译的，它在浏览器上是可读的。
JavaScript 代码首先会被解析，也就是读取并转换成可用于编译的计算机索引的结构，然后再被编译成字节码，最后被编译成机器码，用于设备/浏览器执行。
另一个非常重要的方面是：JavaScript 是单线程的，并且在浏览器的主线程上运行。这意味着一次只能运行一个进程。如果你的 DevTools 性能时间线充满黄色峰值，同时 CPU 占用率达到100%，则将出现丢帧的情况。这是滚动操作常出现的，也是很讨厌的一种情况。
在 JavaScript 代码运行之前，需要完成所有的这些解析、编译和执行工作。在 ChromeV8 引擎中，解析和编译占 JavaScript 执行总时间的50％左右。
所以在这部分中，应该了解两件事情：
1. 虽然 JavaScript 解析的时间长度和包的大小不是完全线性的，但是需要处理的 JavaScript 越少，则所花时间越少。
2. 你使用的每一个 JavaScript 框架（React，Vue，Angular，Preact ...）都是另一个抽象层次（除非它是一个预编译的）。这不仅会增加你的包的大小，而且会让你的代码变慢，因为你不是直接与浏览器通信的。
有些方法可以缓解这种情况，比如使用 service workers 在后台的另一个线程中执行部分工作，或者使用 asm.js 编写更容易编译机器指令的代码。
我们所能做的，就是避免使用 JavaScript 动画库。只有在使用常规的 CSS 转换和动画完全无法实现时，才去使用这些库。
即使这些 JavaScript 动画库使用 CSS 转换，合成属性和 requestAnimationFrame( )，但是它们仍然运行在 JavaScript 的主线程上。基本上这些库会使用内联样式每16ms访问一次 DOM。你需要确保所有的 JavaScript 都在每帧8ms以内完成，才能保持动画的平滑性。