Optimization: Serve static assets with an efficient cache policy

[rfultz]

Background

Looking to optimize the site's performance and that of the homepage specifically, the Lighthouse tool in Chromium browsers has made some suggestions. Some of these will have repercussions throughout the app so we're going to make them their own tickets.

Recommendation: Serve static assets with an efficient cache policy

A long cache lifetime can speed up repeat visits to your page. details

Overview

Increasing the cache setting will mean users can lean on browser caching longer

Benefit (the 80 of 80/20)

• Noticeable for fonts!
• Noticeable for visitors who'd see files that don't change often (images)
• Irrelevant for our css and js files which are named with a new hash with each deploy

Effort (the 20 of 80/20)

Moderate

Complications

• Will changing the cache-control max-age affect files we don't want it to?

Related tickets

• Preload key requests
• Remove unused JavaScript
• Remove unused CSS
• Preconnect to required origins
• Eliminate render-blocking resources
• Ensure text remains visible during webfont load
• Reduce the impact of third-party code
• Does not use passive listeners to improve scrolling performance
• Image elements do not have explicit width and height
• Minimize main-thread work
• Avoid an excessive DOM size
• Reduce JavaScript execution time
• Avoid enormous network payloads
• [aria-hidden="true"] elements contain focusable descendents
• Elements with an ARIA [role] that require children to contain a specific [role] are missing some or all of those required children
• [aria-*] attributes do not have valid values
• ARIA IDs are not unique
• Lists do not contain only
• elements and script supporting elements (<script> and )
• [user-scalable="no"] is used in the element or the [maximum-scale] attribute is less than 5
• Links to cross-origin destinations are unsafe
• Serves images with low resolution

[lbeaufort]

Django behavior means that the regular response header logic doesn't seem to work for staticfiles. I think we might want to do this on the nginx side https://serverfault.com/a/733567. The static assets currently have a 60 second cache vs the default 5 min cache for the rest of the application, so this is a big opportunity for improvement.

curl 'https://www.fec.gov/static/img/angle-arrow-down-primary.svg' -I
...
cache-control: public, max-age=60

Update: jcarroll wrote: I get max-age=600 when running this command ( tried from two different ISPs. to be sure)

[rfultz]

Just noting that, regardless of how often the servers cache various files, our site's optimization (Lighthouse) scores will only be affected by how long browsers are told they should cache our files.

• Things like our images that never really change (logo, etc) could be cached* for a year.
• Because our JavaScript and CSS files are named with a hash that changes each time we build the site, that cache* could be forever since any replacement file will have a different name. (No reason to pollute browsers' storage with files that no longer exist).
• For most of our content, we could look into telling browsers that they can cache* for two weeks (usually the next build, though Innovation sprints complicate that)
• Would there be a way to tell browsers when the files should be refreshed? (like 00:00 the morning after the next deployment)

As far as server caches, though, basically every js, css, and non-blog images could be cached until the next deployment. Same with non-blog pages like data.

*cached by a user's browser

[johnnyporkchops]

@rfultz Regarding the second bullet above, How would telling the browser ti cache a files with a hash forever avoid polluting the browser's storage?

If the file gets a new name (with the prepended hash) then won't cacheing it forever actually do the the opposite because we would be cacheing every time a new hash-name is created?

[johnnyporkchops]

We are meeting with cloud.gov for supplemental support hours to pair on this on Tuesday 05/18 at 3:00 pm. Let @johnnyporkchops know if you would like to be added to invite.

[lbeaufort]

For testing, we added the public route back to the CMS app in the dev space. We should remove that public route in dev before closing this ticket.

What we ran to add the public route:

cf map-route cms app.cloud.gov --hostname fec-dev-cms
cf unmap-route proxy-redirect app.cloud.gov --hostname fec-dev-cms

What we should run to remove it:

cf unmap-route cms app.cloud.gov --hostname fec-dev-cms
cf map-route proxy-redirect app.cloud.gov --hostname fec-dev-cms

Some very basic notes I took from the pairing session with cloud.gov: https://docs.google.com/document/d/15uvsItbGTvvukkLbEd50wLvfucq0AoekCXpf1R4qS4Q/edit