Performance testing

[lindsayplatt]

I've attached the two reports I ran using the node version of lighthouse. I have also attached the report I ran on my GitHub profile for reference. I do this because I think of GitHub as a very performant page and that only scored a 68 on performance with a first contentful paint time of 3.6 seconds, which I was surprised by.

2020_10_29_reports_3.zip

You can get the node version by installing using npm and then running with lighthouse followed by your URL. You will need Node.js >= 10.0.

npm install -g lighthouse

lighthouse https://github.com/lindsayplatt --view

[lindsayplatt]

Preload key requests

One of the first things that seems easy and could result in some gains are for us to specify preload requests. This should be as simple as adding <link rel=preload> to a few resources. The idea behind this is that there are some features that we want to prioritize in the load queue that we know will be needed. These are things that wait for something else to load before they are loaded, but are needed in order for us to properly view the other parts. I think Vue may be obscuring the filenames, but here is how they show up in the Lighthouse report:

Across both the main page and monitoring page:

• fonts/sourcesanspro-regular-webfont.d67b548b.woff2
• fonts/sourcesanspro-bold-webfont.f12f6a2f.woff2

Main page only:

• css/intromap.cee9c45d.css

Monitoring page only:

• css/chunk-7618aa00.dde73ffe.css

Remove unused stuff

The report recommended removing unused Javascript and removing unused CSS. Again, I think these names are obscured by Vue. I'm assuming some minification is happening during the build and deploy phase of the site and so it may be more difficult to track these sources down than I thought. Supposedly, none of this is being used.

Across both main and monitoring pages:

• js/chunk-vendors.d75f2312.js
• css/chunk-vendors.2ee642f0.css

Monitoring only:

• js/chunk-7618aa00.84ac6ac0.js

Enable text compression

We will be ignoring this for now because compression should be enabled when we go to other tiers where cloudfront is enabled.

[hcorson-dosch-usgs]

FYI I wrote this just as Lindsay was posting her very helpful suggestions, so disregard this

Wow, these... don't seem good? I'm finding it a bit hard to deduce what's actually slowing down the page loading here. It does reference several of the data files under the heading 'enable text compression', so maybe those are still an issue, even having reduced their sizes?

[lindsayplatt]

I spent some time this morning attempting to hunt down these resources that it talked about preloading and how that translated to Vue. It appears to be a setting from webpack that you can adjust to either preload or prefetch a component. This article was also helpful in order to learn more about what preload and prefetch do. However, I tried implementing and didn't really see any differences on the Network waterfall page in terms of loading times for the intromap component (the one I was trying to get to load higher up). Although, the files it shows for local builds are different than what is on test (e.g. there are files 0.js, 1.js, etc locally but not online. I think those have to do with router.js?). So, maybe it would make a difference?

Kept my changes in a branch on my fork for now.

Locally:

On test:

[lindsayplatt]

It might be worth pushing out to beta and running a performance test there to see what kind of difference cloudfront caching makes and if any of this resource preloading will even matter.

[hcorson-dosch-usgs]

Thanks for digging into this more, Lindsay. I think you may be right that it would make sense to push to beta so that we can really evaluate things. I'll ask Jordan if that would be ok. Also - In my check-in meeting w/ Jordan he thought there was a way in Vue to temporally disable the minification, with the idea that we could run a performance test on the un-minified site to better see which files are causing load issues.

[hcorson-dosch-usgs]

Just to follow up here - pushing to beta has been approved by Jordan, so we can re-assess the loading issues once the site is up on beta

[lindsayplatt]

Re-running performance tests using beta URL.

Importance page (desktop)

Overall a pretty decent score! Cloudfront caching really does make a significant difference.

Still opportunities to improve if we use preload techniques.

Monitoring page (desktop)

Hmmm performance here is not as good as it is on that first page, but maybe that's OK? Less people will start their journey on this page so the time required to load and interact can probably be less good than that initial page.

Preloading still looks like something that would help, but I'm not sure how we can specify to preload this component only when someone ends up on this router page vs preloading it when someone opens up the home nav

DOM size and execution of JS seem to be a limiting factor here. I imagine this is because of the multiple maps and charts that are interactive and need to be drawn on load.

No mobile tests yet.

I will wait for mobile stuff since we are still working on implementing the approach there.

[lindsayplatt]

Post-meeting ideas:

1. Lindsay implemented preload for the footer things. That seemed to improve load times even locally, so we will push those up.
2. @hcorson-dosch will look into separating out the first map and bar so that they load before everything else. It looks like they are waiting for the full callback fxn to finish before displaying (see results from performance tab below of Chrome developer tools). We decided this can wait a bit longer and could be worked on even as the viz is being reviewed.

[lindsayplatt]

I just tried loading the test URL and looked at the monitoring page. Even though @hcorson-dosch edited the javascript to load the components in separate callbacks (see #81), it doesn't seem like that translated into when they are drawn. The first map is still waiting until the rest are ready before you can see it.

[hcorson-dosch-usgs]

Ahhhh now I realize the issue. The test URL is SUPER out of date. Not sure why it hasn't been rebuilding.

I can tell immediately that it's out of date b/c the text is still between the maps and the matrices:

I think it was ~27 days ago that I changed the ch2 text so that nothing is between the maps and matrices?!

[lindsayplatt]

Oh, good!!!!! Well, not that it isn't building but that it will likely be fixed once it does :)