Web perf: Audit and improve blocking resources

[machikoyasuda]

This ticket is part of a group of web performance tickets tracked here #2487.

Acceptance Criteria

• Read + follow recommendations from https://www.webpagetest.org/result/241029_BiDcSX_ARH/2/experiments/ and https://pagespeed.web.dev/analysis/https-benefits-calitp-org/rqzk6itbxm?form_factor=mobile - Using async defer pre-connect for our various JS/CSS third-party resources.
• Consider compressing/minifying files from server-side.

Additional context

• More Django-specific context/info: https://openfolder.sh/django-faster-speed-tutorial

[angela-tran]

After looking over the recommendations from the WebPageTest report linked above and then looking through our code, I think there are a few efforts here that are independent of one another. Each effort alone requires a decent amount of work, so I think it'd be best to split them out into separate tickets.

Small note about the WebPageTest report

The report is from before #2526 and #2523, so some of the recs in the report are a little out-of-date. I ran another test today, but note that we haven't released those changes to prod yet, so the report is the same.

I can use Lighthouse reports to analyze current performance and improvements, and the point still stands that we need to reduce the number of resources that block page rendering.

Here's what I think should be split out:

Eliminating / improving render-blocking resources

Problems:

From WebPageTest report on benefits.calitp.org

From Lighthouse report on my localhost

Improvements for loading Javascript

• Load external Javascript in a non-blocking manner
  • i.e. with either async or defer, depending on whether we need it to load in a determined order or not
  • this requires determining if there are inline scripts that depend on external Javascript (e.g. jQuery) and ensuring they do not break
• Identify inline Javascript that should be moved into their own files, and load them in a non-blocking manner
  • inline Javascript should be used sparingly since it cannot be cached and is therefore downloaded with every request to the page - see more detail at https://www.slingacademy.com/article/inline-vs-external-javascript-a-dom-perspective/
• Identify inline Javascript that doesn't need to be on every page
  • most of our templates extend base.html, so if there is some inline Javascript on base.html that is actually only needed on a few specific templates, we should move those out of base.html
• Consider removing usage of jQuery
  • I don't actually suggest we do this, but it might be nice to assess how much work it would be to rewrite our usage of JQuery to use plain Javascript instead

Improvements for loading CSS

• From Lighthouse reports of our site, we see a recommendation to load external CSS resources in a non-blocking way. Following several links leads us to the recommendation here: https://web.dev/articles/defer-non-critical-css#optimize
  • The approach is basically to make use of rel=preload so that we asynchronously load CSS and onload to set the <link>'s rel attribute to tell the document this resource is a stylesheet once the CSS has finished loading
    • (see this blog post from Filament Group, who originated this pattern I believe, for more explanation)
  • However, our CSP script-src settings do not allow inline event handlers (e.g. onload) to execute. We would need to allow unsafe-inline, but this is not recommended. An alternative would be to use unsafe-hashes so that we allow specifically this onload function, but still, this is not ideal. So then the question is: should we look into other ways of reducing the amount of render-blocking CSS?

Using compression

This ticket also mentions "compressing/minifying files" and links to a page that has a few different sections on using compression:

• Frontend: where it gets hairier
  • Serving static files from Django with WhiteNoise
  • Compressing and combining with django-compressor
• Compressing Django’s HTTP responses

Also, see #2487 (comment)

It sounds like the focus in terms of this ticket is on compressing the JS/CSS files before they are sent. I wanted to note that in Lighthouse reports of our site, there is a recommendation that we enable compression of text-based resources:

From Lighthouse report on my localhost

Learn more about text compression.

This would correspond with the section Compressing Django’s HTTP responses from that article. So just note that there are two different compression-related improvements that we could be talking about:

• Compressing/minifying JS/CSS files
• Compressing HTTP responses

[thekaveman]

RE: compressing the HTTP response...

We do have gzip enabled in the nginx.conf.

But there are many more configuration options that we could look into: https://www.slingacademy.com/article/nginx-gzip-compression-complete-guide/