在生产中使用 css/javascript 源映射的性能影响？答案

【问题标题】：Performance impact of using css / javascript source-maps in production?在生产中使用 css/javascript 源映射的性能影响？
【发布时间】：2014-07-13 22:37:44
【问题描述】：

应该在生产环境中使用源映射吗？除了调试之外，它们还有什么好处吗？
由于额外的服务器往返，它们会影响应用程序加载时间吗？浏览器是否足够智能，可以在应用加载和渲染后加载 .map 资产？
如果浏览器找不到.map 资产（404 错误），会不会影响性能？我应该关心修复它吗？

请注意，如果存在复杂的 concat / minify 构建步骤，修复最后一个可能不像提供 .map 资产那么容易。

【问题讨论】：

嗯，一个毫无意义的 HTTP 请求肯定需要时间和带宽。
我错过了什么吗？源映射不是用于调试的吗，您最终不会在生产代码中删除它们吗？
因为源映射位于 cmets 中，我会假设浏览器会忽略它们，直到它们被特别请求，例如在开发者控制台中。
@Wex 源图可以内联或作为单独的.map 文件提供； @others，也许我问这个只是为了澄清除了调试之外没有其他好处。然而，既然这么多 js 库都在期待 .map，比如 AngularJS，我们是否只是通过发明 sourcemaps 给 Web 增加了过多的负担？
@Wex 这也是我的想法，但如果有一个明确的答案会很好。是否仅在开发人员打开开发人员工具时才请求外部 .map 资产？那么内联源映射呢？

标签： javascript css httprequest production-environment source-maps

【解决方案1】：

使用Charles Web Proxy 进行的快速测试表明，仅在打开开发人员工具时才加载源地图。如果您在没有打开开发工具的情况下加载页面，则没有对源映射的 http 请求。

Chrome 43 和 Firefox 38 中的行为相同。

所以看起来它们对生产环境没有影响。

【讨论】：

【解决方案2】：

来自 HTML5 Rocks：

基本上，这是一种将组合/缩小文件映射回未建状态。当您为生产而构建时，以及缩小和结合您的 JavaScript 文件，您会生成一个源映射，其中包含有关您的原始文件的信息。当你查询某一行时和生成的 JavaScript 中的列号，您可以在其中进行查找返回原始位置的源地图。开发者工具（目前 WebKit nightly builds、Google Chrome 或 Firefox 23+）可以自动解析源映射并让它看起来好像你是运行未压缩和未合并的文件。

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

【讨论】：

这根本没有回答问题，它只是在解释什么是源映射。