Improve performance on production by reducing JS payloads

[julianguyen]

Description

We've already done some significant work to improve performance (please note on production) including

• Code splitting in Webpack 4
• Inline rendering of CSS and Rails JS assets
• Deferring JS assets from React
• Using async on third party JS scripts
• Gzipping
• Minifying CSS in both Rails and React
• Caching

The Audit tool in Google developer console is super rad (you should check it out if you haven't already). Our performance score went from ~3 to ~40 on mobile and ~0 to ~36 on desktop on the signed in home page (Simulated Fast 3G, 4x CPU slowdown).

There is still significant work we can do with cutting down on reducing JS payloads. See screenshots below for more details.

Screenshots

Mobile

Desktop

Payload Stats

---

Please assign yourself (via the Assignees dropdown), if you do want to work on this issue. Can't find yourself? You need to join our organization.

Check out our Picking Up Issues guide if you haven't already!

[julianguyen]

@geppy Just checking in, how is this going? :)

[geppy]

I worked out where our JavaScript bytes are coming from, then planned out some straightforward changes that'd make a huge difference.

My day job's been too pointlessly dramatic for me to want to work on projects when I get home, but it should start calming down temporarily. And I took off the rest of this week.

I'll try to work on this in PR-sized chunks, in this order:

• [ ] rewrite Header component
  • only user-visible change should be improved performance
  • taking out react-render-html might save 200+ kB (10%+ of the app's entire JavaScript payload)
• [ ] change how localizations are loaded
  • modularizing locale-specific data could save 500+ kB (30-40% of the app's entire JavaScript payload)
• [ ] load polyfills only when necessary
  • would often save another 100+ kB
• [x] adjust charts (load less of chart.js, or render charts another way)
  • might save another 100+ kB

I can start on the header component, but could we chat about the others?

[julianguyen]

Thanks for following up @geppy!I"m sorry to hear your day job is a source of drama :/ I'm glad you took time off, and I hope it was a good break.

No worries for not working on this immediately and not pressure either. I totally understand.

Good idea on breaking out this PR into chunks 🙌 I think starting off with the header component makes sense!

Let's chat about the others too, we can schedule a time on Slack! An existing issue was created for modularizing locale data if that's helpful.