3rd Party Scripts
Core principles
Third party scripts concern the additional JS that an application will need to download, parse and execute, in order to work with 3rd party services. This might be error logging, managing cookie consent, experimentation platforms, and tools like HotJar which allow you to see how users interact with your site. This might take the shape of a script tag but the same consideration can be taken with NPM packages which will pull in information and scripts from elsewhere.
The general rule of thumb is the fewer 3rd party scripts that you can get away with, the better. The faster every page load will be, the smaller the surface area for bugs and security issues, less is generally more.
Every time you add a 3rd party script it should be scrutinised:
- Do I need it?
- Do I trust where it comes from?
- Can I lazy load this or will it be render blocking?
- If it's render blocking, do I have evidence to support it's value? Is the impact to rendering less than the value this script will bring? Are the stakeholders aware of the trade-offs?
- What holes do I need to cut in the content security policy to get this script to work?
- Is there away to make this script as small as possible?
- What other scripts do I have running, will this clash?
- Will the script be executed as if you'd authored it with access to local scope like session storage, or would it have it's own isolated scope?
Cookie consent
Cancer Research has a moral and legal obligation to protect the privacy of our supporters. We are the custodians of information given to us by our supporters and we honour supporter preferences for what they allow us to track. We state in our privacy and cookie policy the tracking options selected for cookies also represents the level of consent that we apply to all tracking technologies even ones that aren't cookie based.