Increase the likelihood that service teams will only include the bits of the Design System they are using

[36degrees]

Brief

Increase the likelihood that service teams will only include the bits of the Design System they are actually using in their service.

Our documentation is currently optimised for getting people started quickly. The simplest thing that a service team can do when getting started is to include all of the CSS and JavaScript from GOV.UK Frontend. Unfortunately, this is where most service teams stop.

This means that (anecdotally, of those we've looked at) most services include the code for all of the components, whether they're using them or not. For example, a simple service that's mostly basic form controls and buttons is likely to be including all of the code for tabs, accordions, character count despite not using them.

For example, we might:

• make changes to the code so that it's easier to selectively include bits of GOV.UK Frontend
• improve our documentation to better explain how to do this and what the benefits are
• explain the impact that this change can have in terms of web performance and sustainability, perhaps through blogging or talking about this at a monthly call

We think that doing this will:

• improve the overall performance of services across GOV.UK
• reduce the carbon footprint of services across GOV.UK
• reduce the impact on performance as we continue to add additional, more complicated components to the Design System

Epic lead

TBC

Driving role(s)

Developers, tech writers

Supporting roles

Content designer?

Needs awareness

If we plan to make some noise about this we may we want to involve the community designer and comms folks.

Further detail

This is an area where I think we can have a real 'multiplier impact' on web performance and sustainability across the GOV.UK estate just by gently nudging people towards optimising what they're including.

Although it'd be interesting to look at, I think we should consider the following out of scope (for now):

• splitting out individual features of components
• code splitting and dynamic imports
• improving caching strategies

Let's assume that most service teams will have a single JS / CSS file for their service that includes GOV.UK Frontend, and focus on getting that right before we optimise for individual pages within the service.

Tasks

Beta Give feedback

1. Optimise the Design System website to only include the CSS and JS for components we're using #3732
   javascript performance sass / css +3
   
2. Split up or re-organise the 'Import CSS, assets and JavaScript' page govuk-frontend-docs#435
   documentation +1
   
3. Move responsibilities from initAll to the components govuk-frontend#4945
   +0
   

   
4. Encourage only including code for things that are being used govuk-frontend-docs#436
   documentation +1
   
5. Explore ways to selectively import parts of the CSS govuk-frontend#4946
   +0
6. Explore how get started links to other sections
7. Better understand the impact of encouraging users to only import the things they are using #3745
   +0
8. Create a calculator that asks people to select the components they're actually using, and then show them how much they could shave off their file size
9. Share this work to a wider audience e.g. by blogging about it or running a Show & Tell
10. Rename any _all.scss files to _index.scss so they work as index files govuk-frontend#4960
    +0
    
11. Fix tree-shaking when importing from 'govuk-frontend' govuk-frontend#4957
    +0
    
12. Investigate tree shaking of common js utilities govuk-frontend#4964
    javascript performance +2
    
13. Review Vite integration tests govuk-frontend#4978
    small story tooling +2

[36degrees]

I'll leave defining the tasks we want to do until this epic is picked up, but a few thoughts on things we could do:

• Optimise the Design System website to only include the CSS and JS for components we're using #3732 – this would help us learn where the pain points are
• move as many responsibilities from initAll to the components (for example, the data-module selector is only defined in initAll) to make it easier to include the JS for components without initAll
• make it possible to generate a custom version of the 'dist' JS + CSS, like you could with Bootstrap in ye olde days
• improve our documentation to nudge people towards optimising what they include
• create a calculator that asks people to select the components they're actually using, and then show them how much they could shave off their file size – it could also
  • ask for approx number of sessions and calculate the impact on carbon footprint
  • allow the data to be submitted and feed into a dashboard with the estimated collective impact the changes have had
• blog about it
• show and tell about it
• run a clinic or workshop focused around it

[36degrees]

Another suggestion that came up in a recent conversation with @romaricpascal – allowing users to specify which components (or other parts of the code?) they want to include the Sass for using a Sass variable:

$govuk-included-components: (
    "button",
    "header",
    "footer"
);

@import "govuk/all";

[36degrees]

If we're revisiting our guidance on importing things, we might want to take this opportunity to split up or re-organise the 'Import CSS, assets and JavaScript' page which is becoming a bit unwieldy.

[36degrees]

Calling this done.