Get visibility over web performance metrics

[36degrees]

What

Get visibility over the performance metrics of GOV.UK Frontend, over time but ideally at the point a change is made (for example, surfacing them when raising a pull request).

As this is quite a broad story, the first step will be to scope this work.

Why

This came up as part of a 'tech & ops health check' exercise the team ran in November 2020, as part of the 'frontend performance' practise.

We scored ourselves as 'OK' for that practise, but said that we were 'moderately concerned' about it as we know there are some areas that could be improved.

Getting visibility over performance metrics was highlighted as one area we'd like to add to GOV.UK Frontend. We believe that it will make us more aware of the impact that changes to GOV.UK Frontend have on performance, and help us avoid shipping a release that for example significantly increases the size of the CSS or JavaScript.

Who needs to know about this

Done when

• Agree scope of this work and update the 'done when' criteria
• Run any new tooling past IA/privacy

[36degrees]

This might be useful for surfacing basic metrics about changes to the package – though seems to rely on using Webpack: https://relative-ci.com/

[vanitabarrett]

We spoke about potentially picking this up as part of the JavaScript work - we might want to get this in place before we start making substantial changes to our JavaScript code and set-up so we can assess the impact on file size (if any). We could do an MVP thing for this - could just be something basic tied into our existing Github Actions for now.

[lfdebrux]

Might be misunderstanding this, is this not the same as what SpeedCurve currently does for us?

[vanitabarrett]

@lfdebrux This story is quite vague. For the JS work, we discussed having visibility over the size of the JS and CSS we ship. I'm not sure if that's something we get from SpeedCurve, but if it is, seeing as we have that currently (and don't look at it) it might be more about documenting it and/or fitting that into a process somewhere. Or exploring alternatives that fit into our build pipeline so we get visibility of it when we do a release (for example)

[36degrees]

We could set SpeedCurve up with a budget and alerts etc, but even then it would only tell us about the impact of a change after we've shipped a release. It's also harder to distinguish whether a change has occurred because of a change in GOV.UK Frontend or a change to the Design System.

I think a good solution in this space would:

• help us understand the impact of merging an individual pull request before it's merged by comparing to the baseline ('adds n kilobytes to the compiled CSS'; 'adds 0.3s to time to interactive')
• give us visibility over longer-term trends (how the core metrics have changed over the last year; so we can see what general direction we're heading in)

[romaricpascal]

Closing in favour of #3279