Is it worthwhile to gzip a JavaScript file in a Chrome Extension?

Question

Is there any reason to gzip a massive js file being loaded locally by a chrome extension? Will it increase or decrease load speeds? Why?

Google recommends using Gzip to compress files. But does this only matter when files are being transferred across a network? Or is it also faster to process a gzipped file locally?

Answer 1

When loading a script there are at least two phases that can affect how quickly the script loads: data transfer time and parsing/evaluation time.

When requesting a script over the network the data transfer is of course subject to the speed of the network links between the origin server and the browser. In this situation the data transfer time will almost always exceed the parsing/evaluation time, making gzip usually a win in terms of decreasing overall load time: gzip marginally increases the parsing/evaluation time, but can significantly decrease the data transfer time.

I think the crux of your question is whether this remains true when the data transfer is instead from a local disk. Local disk will generally be faster than the network, and so the question is whether the local disk is faster enough than the network that the additional processing time of gzip decompression begins to be higher than the cost of reading the additional bytes from an uncompressed file from disk.

The answer to this must certainly depend on the disk and the CPU, so there cannot be a definitive answer. You can, however, make an educated choice here by trying both options and using the Chrome developer tools, which are available for the background pages used by extensions as well as regular web pages. You can find the developer tools for a background page by accessing the chrome://extensions page and clicking the background page link beside "Inspect views", shown in this screenshot as "background.html":

The questions to attempt to answer with the developer tools would be:

• Does either option take long enough that it's worth perusing this further? If both approaches result in a background page that loads fast enough for your needs, then you may as well just do whatever is easiest for your development workflow.
• Is there a significant time difference between the two options? Of course what is "significant" will depend on your use-case, but if the difference is small then again you can just choose the most convenient approach.
• Assuming the time difference is significant, which was faster?

A good place to start is to select the "Timeline" tab within the developer tools for your background page, and press F5 to refresh the background page and capture information about its resource usage during initial load:

Each of the horizontal bars in the middle strip represents some time that Chrome spent doing a particular action during the loading of this background page. The events that are most relevant to your question are:

• "Send Request" for the JavaScript file you're considering. This will be a very small "bar" in the visualization because Chrome considers this to be an instantaneous event that begins a background task which is not shown.
• "Finish Loading" for the same file. The time difference between "Send Request" and "Finish Loading" is the time it took to read the file from disk.
• "Evaluate Script" for this file. (note that the gzip decoding is usually done concurrently with loading the data from network/disk, so the gzip time is likely to be included in the space between "Send Request"/"Finish Loading" rather than in this "Evaluate Script" block.)

The time that matters for the sake of your question is the time difference between the beginning of "Send Request" and the end of "Evaluate Script". In my example here with the Google Cast extension:

• "Send Request" began at 95.2ms
• "Evaluate Script" began at 103.1ms and ran for 174ms, so it ended at 277.1ms
• Thus the total time spent was 277.1 - 95.2 = 181.9ms

By trying this with both an extension with uncompressed JS and an extension with the same JS gzipped you can obtain the two timing values and answer the above questions, and thus in turn find the answer to your original question of whether compressing the JS is worthwhile.

---

An important thing to keep in mind with this sort of profiling is that one must keep in mind the performance needs of the application. For the background page of a Chrome extension, the user doesn't actually directly see the time taken to load and so one can presumably take some liberties in startup time. Unless a significant amount of time is time spent loading and parsing the JavaScript file, and that delay has a user-visible impact, it is likely that time spent trying to optimize this process would be time wasted.

In the case of the Google Cast extension, its script loaded in 181ms and the whole page was initialized in 500ms. As a user of this extension I've no complaints about it taking 500ms to initialize, and were I the developer of this extension I expect I would not attempt to optimize its startup time any further.