是否值得在Chrome扩展程序中压缩JavaScript文件？

Question

是否有任何理由通过chrome扩展程序gzip本地加载的大型js文件？它会增加还是降低负载速度？为什么？

Google建议使用Gzip压缩文件.但这只是在通过网络传输文件时才有意义吗？或者在本地处理gzip压缩文件也更快？

Answer 1

加载脚本时,至少有两个阶段会影响脚本加载的速度:数据传输时间和解析/评估时间.

当通过网络请求脚本时,数据传输当然受原始服务器和浏览器之间的网络链接速度的影响.在这种情况下,数据传输时间几乎总是超过解析/评估时间,使得gzip通常在减少总加载时间方面是一个胜利:gzip略微增加了解析/评估时间,但可以显着减少数据传输时间.

我认为问题的关键在于,当数据传输来自本地磁盘时,这是否仍然存在.本地磁盘通常比网络更快,因此问题是本地磁盘是否比网络更快,gzip解压缩的额外处理时间开始高于从未压缩文件中读取额外字节的成本磁盘.

答案肯定取决于磁盘和CPU,所以没有明确的答案.但是,您可以通过尝试这两个选项并使用Chrome开发人员工具在此处做出有根据的选择,这些工具可用于扩展程序和常规网页使用的后台页面.您可以通过访问该chrome://extensions页面并单击"检查视图"旁边的背景页面链接找到后台页面的开发人员工具,此屏幕截图显示为"background.html":

尝试使用开发人员工具回答的问题是:

• 这两种选择是否需要足够长的时间才能进一步深入研究？如果两种方法都导致后台页面的加载速度足以满足您的需求,那么您也可以为开发工作流程做最简单的事情.
• 这两个选项之间是否存在显着的时间差异？当然,什么是"重要"将取决于您的用例,但如果差异很小,那么您可以再选择最方便的方法.
• 假设时间差是显著,这是更快？

一个好的起点是在后台页面的开发人员工具中选择"时间轴"选项卡,然后按F5刷新后台页面并捕获有关初始加载期间资源使用情况的信息:

中间条带中的每个水平条表示Chrome在加载此背景页面期间执行特定操作所花费的时间.与您的问题最相关的事件是:

• 您正在考虑的JavaScript文件的"发送请求".这将是可视化中的一个非常小的"条形",因为Chrome认为这是一个瞬时事件,它开始一个未显示的后台任务.
• 对于同一文件,"完成加载"."发送请求"和"完成加载"之间的时差是从磁盘读取文件所花费的时间.
• 此文件的"评估脚本".(请注意,gzip解码通常与从网络/磁盘加载数据同时进行,因此gzip时间可能包含在"发送请求"/"完成加载"之间的空间中,而不是包含在此"评估脚本"块中.)

为了您的问题,重要的时间是"发送请求"开头和"评估脚本"结束之间的时差.在我的示例中,使用Google Cast扩展程序:

• "发送请求"始于95.2毫秒
• "评估脚本"从103.1ms开始并运行174ms,因此以277.1ms结束
• 因此,花费的总时间为277.1-95.2 = 181.9ms

通过使用未压缩JS的扩展和具有相同JS gzip的扩展来尝试此操作,您可以获得两个计时值并回答上述问题,从而找到原始问题的答案,即压缩JS是否值得.

这种分析要记住的一个重要事项是,必须牢记应用程序的性能需求.对于Chrome扩展程序的后台页面,用户实际上并不直接看到加载所需的时间,因此可能会在启动时获得一些自由.除非花费大量时间来加载和解析JavaScript文件,并且该延迟具有用户可见的影响,否则尝试优化此过程所花费的时间可能会浪费时间.

对于Google Cast扩展程序,其脚本在181ms内加载,整个页面在500ms内初始化.作为此扩展的用户,我没有抱怨它需要500毫秒进行初始化,并且我是这个扩展的开发者,我希望我不会再尝试优化其启动时间.