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?
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:
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:
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:
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.