Include fingerprints in filename for image assets

[36degrees]

What

Include a fingerprint in the filename for all of our image assets to make it easy for service teams to treat them as immutable and cache them indefinitely.

Update the page template and references in the stylesheet to point to the new images.

Why

Although we allow customisation of the location of the images in both Sass (by setting $govuk-images-path) and Nunjucks (by setting the assetPath variable) it's non-trivial to change the filenames themselves – you'd need to either creatae a function that rewrites the filename in Sass or re-implement the entire headIcons block in Nunjucks.

Although there are only a handful of images in GOV.UK Frontend, the difficulty in adding fingerprints to them may cause issues for services with more images that are fingerprinted, preventing them from having a blanket caching strategy for all of their images.

It could also cause issues where the majority of images do have fingerprinted and teams are caching images indefinitely, without realising that our images do not have fingerprints.

Further details

Note that if we use a hash of the file contents as part of the filename that would mean that any change to an image (including e.g. optimisations) could be a breaking change as teams would need to update the paths in their templates etc.

We could mitigate this by keeping previous versions of images between major releases, or consider using an alternative identifier that only changes if the image changes in a meaningful way (like a version number)

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

• [ ] Image assets in GOV.UK can be cached indefinitely (for example because they include a fingerprint in their filename that changes when the file contents change)
• [ ] References to those images have been updated
• [ ] We understand the impact on future changes to those images and what it means for versioning

[36degrees]

There might be a way to do this as a non-breaking change if we keep the existing files in place and use a feature flag to roll it out?

[romaricpascal]

We'll need to make sure to consider tools that would fingerprint assets themselves (eg. Rails assets pipeline, but potentially other build tools) to make sure adding hashes ourselves doesn't mess things up for services using such tools (by assets being fingerprinted a second time, possibly with a different hashing mechanism, but code referencing file names with the first fingerprint which wouldn't be found).

[querkmachine]

IIRC when the favicon changes were being rolled out, there was some mention that a lot of teams have build processes that copy these static assets—presumably through some file name or path reference—rather than using them directly from the npm package, and which can rename them as part of doing so.

Probably worth having a look/ask around to see if there's any common methods that need to be accounted for.

[romaricpascal]

IIRC when the favicon changes were being rolled out, there was some mention that a lot of teams have build processes that copy these static assets—presumably through some file name or path reference—rather than using them directly from the npm package, and which can rename them as part of doing so.

Sounds like what @MartinJJones showed me yesterday, where Rails assets pipeline would add a hash in the name of our image files when it compiles it, but the manifest.json keeps referencing non-hashed paths.