作为一个开发者，我们知道结束网页的膨胀是一件简单的事情。但是加载一个页面远比传送相同大小的数据要的时间多的多。一旦流浪器下载了我们的页面脚本，他就必须解析和运行它们。在这里我就深入的来讨论JavaScript的这个阶段，为什么它会减慢应用程序的启动速度并且如何的去修复它。
从加载页面的过程中，我们观察到是在解析和编译javascript的过程中并没有花费很多的时间。我们看到死脚本立即的被解析和执行了。但是事实并非如此。下面是V8引擎的工作原理。
V8引擎工作简化视图
看看那些主要的阶段。
是什么让我们的网络应用变慢了？
解析、编译脚本和执行脚本花费了JavaScript引擎的大量时间。这延迟了我们与站点交互的时间。可以想象一下，但我们在看到一个按钮时却不可点击只能干等着，这大大的降低了用户体验。
V8引擎如何工作的简化视图。这是我们正在努力的理想化管道。
一些关键性的代码控制着启动的时间。实际过程中，在类似于facebook这样的大网站中v8花费了大量的时间在进行代码的解析与运行。
粉红色区域（JavaScript）代表在V8和Blink的C++，而橙色和黄色代表解析和编译。
一般网站的JavaScript解析和编译瓶颈是什么？
脚本的大小很重要，但是它并不能代表一切。就比如说200kb我们的js脚本!==200kb别人的js脚本解析与编译时间。代码的质量也是一个很重要的原因。
目前测量JavaScript解析和编译工具
Chrome DevTools
下面是Chrome加载的时间
0_rWkYJzc6Cp0r3Xkr.jpeg
Chrome Tracing
关于跟踪：Chrome的低级别的跟踪工具允许我们使用disabled-by-default-v8。runtime_stats范畴更深入地了解那里的V8花时间。
0_P-_pLIITtYJRikRN.jpeg
WebPageTest
image.png
WebPageTest的“处理故障”页面包括洞察V8编译，evaluatescript和函数调用的时候我们做了一个跟踪（捕捉工具开发时间表启用）。
我们现在也可以得到运行时调用属性指定
disabled-by-default-v8。runtime_stats作为自定义跟踪类
我们可以做什么来降低JavaScript解析时间呢？
- 越少的脚本需要解析的时间越少。
- 代码拆分： 只加载用户所需要的代码。实现代码懒加载，避免解析太多的javasript。
- 脚本流：在过去，V8告诉开发者使用
异步/推迟选择脚本流的解析10–20%之间时间的改进。这允许HTML解析器至少提前检测资源，将工作推送到脚本流线程，而不是停止文档解析。现在，这也是为解析器阻塞脚本所做的，我认为这里没有任何可操作的地方。V8建议早期加载较大的捆绑包，因为只有一个流光线程（稍后会详细介绍）- 库和框架。
