Reduce production file size

[dmethvin-gov]

I've added webpack-bundle-size to the starter app and it generates output into public/stats/bundle.html on each production build showing the sizes of components in the bundle. I can't upload a picture of the web page it generates (GitHub uploads are blocked) so I'll summarize the main issues here. The biggest dependencies by size are:

Component	Parsed size (KB)	Pulled in via
Total	1001
moment	227	us-forms-system
styles.css	181	us-forms-system (and USWDS)
USFS JS code	119	us-forms-system
react-dom	101	react-jsonschema-form
lodash	55	us-forms-system and others
react-jsonschema-form	53	us-forms-system
raven-js	39	us-forms-system
react-scroll	24	us-forms-system

So the sorta-good news is that most of these are direct dependencies so we possibly have the ability to shrink or remove them. Here are my notes.

• moment: (Fixed in Use date-fns instead of moment #258) One of moment's benefits is that it knows about internationalization of dates. We're pulling date localizations for every language and country yet our forms seem to be hardwired to English. We're actually using moment for almost nothing so we should be able to get rid of it with a few custom functions.

• styles.css: This is a lot of CSS and it's not that well compressed. If there are parts of it that we know we don't need for forms, it would be awesome to be able to remove them. In the case where us-forms-system is used within a larger app, that app may want to pull in styles that we don't use so it's not as simple as chopping things out. This relates in some ways to Should USWDS import from VA's design system? #65 and Discovery on best way to import USWDS images and fonts #66.

• USFS JS code: The sample app pulls in almost no widgets or definitions from us-forms-system so it's a bit worrisome that it's already so big. Not sure if there's a way to avoid this growth.

• react-dom: The only function we seem to directly use from this in production is render()but I suspect there is a lot used under the covers for JSX parsing and processing. I suppose this is 100KB that we have to swallow.

• lodash: I've already mentioned this in detail in Don't include all of lodash #131.

• react-jsonschema-form: If we extract only the parts we need, as recommended in Remove react-jsonschema-form dependency #141, this may save us a decent amount of space.

• raven-js: (Fixed in [WIP] Move Google Analytics and Sentry to hooks that apps can call #196) This is an error reporting library. See Document the ability to track form stats and errors via Google Analytics #134 for detailed discussions, but I'd prefer to have just some hooks in the library and let the app decide how much tracking they want.

• react-scroll: This seems like a lot of bytes for a library that seems to just scroll to a new position on the page. Could it be replaced with a CSS animation perhaps?

EDIT: A useful blog post series: https://www.contentful.com/blog/2017/11/13/put-your-webpack-bundle-on-a-diet-part-4/

[dmethvin-gov]

Additional links for things to reduce size, e.g. removing React propTypes:
https://github.com/GoogleChromeLabs/webpack-libs-optimizations

More tips: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

[dmethvin-gov]

At the moment it looks like we're pulling down most if not all of USWDS. We may be able to get a smaller set of styles when/if we refactor to separate forms from the navigation and other things like the footer. The eQip prototype seems to have refactored the USWDS styles for form elements into separate files so there may be something to learn from there. That avoids including any styles of form elements you don't use.

[jcmeloni-usds]

@dmethvin-gov @annekainicUSDS Is it correct to say "moment -- done w/ #258 and the rest is still an ongoing discussion"?

[annekainicUSDS]

@jcmeloni-usds yep!

In regards to lodash, I saw some discussion in one of the Vets.gov channels recently about how lodash/fp is much less efficient than regular lodash. An example they provided was if you compare a bundle that just imports lodash/fp/uniqueId vs lodash/uniqueId, the fp version is 47kb and the regular version is 2.65kb. A quick solution for reducing the bundle size of lodash is just to use the regular version instead of fp. Not sure what impact that will make, but we should investigate it!

[dmethvin-gov]

As I understand it, Redux requires any changes to the data store to be done by replacing with new data structures rather than mutating the old ones. That's how it knows whether the data changed, because it can use an inexpensive equality test to see if the objects are the same. The standard lodash mutates the incoming data for some operations so we can't use it everywhere. That difference on uniqueId is really strange though, not sure why there would be such a large difference in size.

[dmethvin-gov]

Closing for now, we'll revisit once we do the refactoring in #57, #66, and #141.