Research: Improve homepage load time (currently ~1.9 seconds)

[lbeaufort]

User story As a first-time visitor to fec.gov, I'm more likely to give up and leave if the homepage takes more than a second to load.

We should identify easy ways to improve the homepage load time. At 1.9 seconds, Pingdom gives us a C grade and has an interesting report.

Not an exclusive list of things to check:

• Compare load with caching vs no caching (hypothesis: slower with caching)
• Look at both mobile and desktop
• Look at CDN
• Look at webpack
• create separate ticket to address Webpack configuration and approach as mentioned in this comment below

Pingdom

https://my.pingdom.com/app/reports/rbc/5304992

Google speed test

https://developers.google.com/speed/pagespeed/insights/?url=www.fec.gov

Action item

• break ticket into independent smaller tickets and prioritize accordingly.

Completion criteria:

• Quick wins are identified and followup tickets are created to address those quick wins

[johnnyporkchops]

The two data visualizations(election search and raising/spending ) that we load below-the-fold on the homepage, may be effecting performance. They are loaded via Django templatetags.
We can consider using these debug tools to evaluate:
Django debug toolbar: https://django-debug-toolbar.readthedocs.io/en/latest/index.html
Update on below toolbar plugin: Unfortunately the below only supports <= Django 1.11
Template-Timings toolbar: https://github.com/orf/django-debug-toolbar-template-timings

[johnnyporkchops]

Since I was unable to use the Django template-timing-toolbar to test the performance of the visualizations on the homepage, a less scientific test was to remove them and push to feature and do a Pingdom test. This change does increase load time and raises the performance grade to a B, but the small difference shows that these visualizations are likely not a main issue in load-speed

[johnnyporkchops]

Addressing inefficiencies in our JS and Webpack configuration and approach is a heavy task that should probably be spun off into another ticket. (The below list of possible corrective measures, is by no means, exhaustive)

The size of our compiled Javascript creates a possible opportunity or performance improvement for the homepage and other pages based on the the Google insights results. (First screenshot below) and running Webpack analyzer locally, (second screenshot below).

Based on research using Webpack Analyzer and previous Innovation sprint research done by @rfultz, there is no one change to webpack.config that would improve performance significantly, but more granular reconfiguring may help.

Possible webpack changes
Remove unnecessary calls to scripts based on templates and/or find a more granular way to split compiled scripts into smaller pieces to only be loaded where needed.
- Once we can upgrade to Webpack 5 (related issue), the commonschunk plugin that we are using now is built in to the functionality, but we would have to reconfigure the way we are identifying entrypoints.

For homepage:
Possibly create one entrypoint for homepage that only loads what we need there (including JS for the data visualizations)
- Does homepage need D3? This is big portion of the dataviz common loaded there now
- Does homepage need Juery.dataTables.js ? , another big portion of dataviz-common loaded there.
- If homeapge needs Juery.dataTables.js There are two calls to Juery.dataTables.js (datatables.net-responsive and datatables.net.js. Are these essentially duplicates?
- we could sequence load JS, CSS, Fonts, other assets after initial page load, Then load the other assets like dataviz and init later

For other pages:

• Look at redefining entrypoints -- possibly based on templates used in /data for example
• Point to CDNs for vendor files. Or even consider CDNs for our files. This would mean that we can take advantage of cacheing because we would not have to load a new hashed-version file for unchanging assets.

Google Insights https://developers.google.com/speed/pagespeed/insights/?url=www.fec.gov:

Webpack analyzer plugin running locally, looking at homepage (fec.gov):

[rfultz]

I've created tickets based on my findings and experiments ☝️

[rfultz]

Closing this as the other tickets have been created. For the record, there's a branch of code whose name starts with feature/3711 where I've committed different experiments and samples