Explain how to use `defer` to avoid render-blocking when using this library

[bradmorton1]

https://www.webpagetest.org/video/compare.php?tests=190916_BZ_60f228bdf766f4f0a23e7be389decabe,190917_71_be05e3ef5dd8be1a16448425cd8b641d

This test proves that loading the cookie consent script interferes with loading the main content of the page. On a 3G quality connection or older, the load time increase is significant

[mikemonteith]

We should add some guidance to our docs about when to use the async attribute etc.

[chrimesdev]

From Harry Roberts:

According to WPT, cookie-content.js adds 2.9s to our Start Render event. This is a huge amount of time to lose, especially considering in relative terms it represents a 1.8× degradation in performance.

The attached video shows the users’ experience, and this waterfall comparison shows the technical differences.

Can we defer it and stick it near the closing </body>?

[chrimesdev]

I believe this isn't as simple as just adding the defer tag to the cookie banner JavaScript. When trying it on the NHS website, the cookie banner works OK but the toggle page where you change your answers doesn't work properly. I think some code will need changing in the cookie consent solution.

[mikemonteith]

The NHS.UK toggle code isn't compatible with a defered cookie-consent script, but we could fix that.

[tomdoughty]

The banner can be defered as long as any interaction with the cookie banner's exposed API is wrapped in a load event to prevent a race condition. This is the case everywhere it is used on NHS.UK. We have multiple apps which do defer the banner with no issues.

Further discussion and example implementation is in this merge request

[mikemonteith]

I think this issue is just a matter of explaining this best practice in the docs, as there's no code change needed. I'm going to change the issue title