Tracking: Improve webpack build time/size

[cezaraugusto]

• disallow uglifyJS compression feature disallow uglifyJS compression feature #11549
• allow parallel minification Upgrade webpack to 3.8 #12129
• cache babel-loader reduce webpack build time by 55% with this one simple trick #11474
• better babel config (needs investigation)
• better code split (separate about pages from app entry)

[petemill]

For the images, would it be more ideal to compress in source code since there wouldn't be any reason to have higher quality inside git, and then compress at compile-time on every build? I've often found that images used for different purposes have different compression vs quality concerns, and each use in a PR could be evaluated from a design point of view. For SVGs, when adding a new one, I always use https://jakearchibald.github.io/svgomg/

[cezaraugusto]

that's nice, please jump in here or make a new issue/PR to track image optimization!

Plus, we make use of few FA icons and likely not use new ones in the near future so it would be nice to extract only the FA SVGs we use and put them in the tool you mentioned, or just run standalone imagemin for all images and push the optimized versions. What do you think about that?

[luixxiul]

FYI: there is another tool https://github.com/svg/svgo

[petemill]

@luixxiul 👌 - the tool I linked to is just a manual GUI for SVGO. It would be interesting to try a pass on all existing SVGs with that, and then put a policy in place for future assets. We would have to test the output for quality and any over-optimization, especially if we're using CSS to style SVG elements that may have been stripped out 🖌