分析网页中JavaScriptBundle的大小并限制网页中JavaScript的数量可以减少浏览器解析、编译和执行JavaScript的时间。这可以加快浏览器开始响应用户交互的速度，从而改善几个重要的性能指标，例如首次输入延迟和最大内容绘制。在本文中，让我们看一下分析网页中JavaScriptBundle的几种方法。查看JavaScript文件使用ChromeDevtools中的网络仪表板是查看页面上下载的所有JavaScript的最简单方法。Mac上按Ctrl+Shift+J或Command+Options+J打开Devtools：然后打开网络看板，打开看板刷新页面，点击JS过滤项，过滤掉所有JavaScript文件。可以看出这是一个很简单的网页，里面的代码执行逻辑也很简单，但是如果是一个JS文件，把所有的依赖和代码逻辑都打包在一起，就没那么容易分析了，里面的逻辑会很混乱，你很难看清里面的代码逻辑。下面是一个网站，里面封装了很多自己站点的第三方库和js模块：下面我们来看看分析这段代码的方法：ShowCoverageMac上按Ctrl+Shift+P或者Command+Options+PP打开命令菜单，搜索Coverage并选择ShowCoverage命令：然后重新加载网页，在下拉菜单中选择JavaScript：在表格中，我们可以清楚地看到每个文件中有多少未使用的JavaScript，您也可以点击任意URL用于逐行分析。Webpack虽然上面的方法可以让我们看到有多少未使用的JavaScript，但是要分析出组成Bundles的模块仍然不是一件容易的事。如果你的网站打包过JS，那么你一定用过webpack、rpllup等模块打包器，其中很多工具都为我们提供了非常好的分析模块的方法。让我们看一个例子，如果你使用的是Webpack，那么你可以生成一个stats.json文件，其中包含所有捆绑模块的统计信息。虽然直接看这个文件就可以知道包含了哪些模块，但是社区中的一些工具可以帮助我们更好的可视化和分析模块信息：比如webpack-bundle-analyzer，它可以分析Webpack打包后的产品，并将其映射到stats.json中的模块名称，并创建打包工件的交互式树可视化。显示每个模块的大小、其Gzip解析后的大小以及它们之间的关系。SourceMap的这些packagers提供的可视化工具很棒，但是都是packager-specifictools。对于任何网站，无论使用哪种打包器，都可以使用SourceMap将打包后的代码还原为原始代码。这非常有用，因为它允许我们还原在构建过程中被混淆和转换的代码。在缩小或捆绑的JavaScript文件中，通过注释指向SourceMap文件的位置。所有较新的浏览器都支持sourcemaps，而对于Chrome，你可以在Devtools中启用它：当Chrome检测到一个SourceMap可用时，它可以恢复源代码：source-map-expolersource-map-expoler可以通过SourceMap生成打包树产品的可视化关系，通过查看这些模块关系，我们可以发现一些问题：比如上面的moment和lodash这两个库，在整个文件中所占的比例非常大，其规模远远超过了它们的使用价值.我们可以把它们都转换成ES模块，它们可以做得更小，更优化。Lighthouse使用Lighthouse，我们还可以通过SourceMap分析我们打包后的产品中未使用的JavaScript代码。还有一个功能正在探索中，可以使用SourceMap来分析新浏览器中不需要的打包产品中的polifill代码。以上就是分析JavaScript打包产品的几种工具和方法，用它们来优化你的JavaScript打包产品吧！
