Investigate & optimize webpack build

[emcniece]

The recent removal of jQuery (#37) resulted in a size reduction of content.js from 2.62MB to 1.96MB. It's a step in the right direction, but 2MB for a JS bundle is still huge.

The only major imports are winston and idb, and it's surprising that these two libraries would include so much code. I suspect that Webpack is polyfilling a lot of code, which may be unnecessary given that the deploy target is an update-enforced ES6-compatible browser.

Webpack should produce a smaller build if the compile target is changed, and if compression and minification for distribution builds are enabled.

[sabjorn]

@emcniece I am under the impression that we have limited options for magnification because of the review process for the extension.

compression is likely possible BUT is there an advantage to shrinking this plugin down?

[emcniece]

Sure, bundle size impacts performance, particularly load and parse times. It's minimal given that the browser loads the file from disk, but it's usually a good idea to be a conscientious developer in shared environments.

With regard to the Webpack polyfill features: they may be redundant as Chrome supports ES6 patterns since version 42, ~2015.

Looks like there are some rules around Chrome extension optimization, but these things are allowed:

• Removal of whitespace, newlines, code comments, and block delimiters
• Shortening of variable and function names
• Collapsing files together

Despite this clarification, they don't explain what "obfuscated" means... super helpful. 😕 I suspect it means doing things like intentionally destructuring variable names into strings then using eval() to re-strutcure and execute.

[sabjorn]

@emcniece it looks like webpack is mininfying code for production output:

npm run build
cat dist/main.js