docs: update docs to include loading the fonts via a cdn

[roedoejet]

I separated out the cdn related info from #9 and put it all here with a jsDelivr example as well.

For a basic static HTML site, this would be how I would load the font, so I think we ought to have an example in here for this type of simpler loading.

[ty2k]

Hey @roedoejet, thanks so much for the content delivery network (CDN) link suggestions!

We (Font team in Connected Services BC's Policy Direction division) are looking into the feasibility of including a CDN option for BC Sans in the documentation.

I'm going to list some of the pros and cons of this approach here as a public place to refer people to. Hopefully folks from the community will leave comments about their own needs and concerns as well. Folks can also read Cloudflare's CDN Benefits: Why use a CDN? documentation for a good primer on what a CDN is in general.

Advantages

Benefits of browser caching

Currently, having every single application ship their own copies of the font means that a user never gets the benefit of their browser caching the font and CSS files (like they would through a common CDN link).

For example, a user who newly lands on Gov.bc.ca in search a service will have their browser download the WOFF or WOFF2 font files, depending on their device. If that user gets linked out to another BC government app/service, that's another copy of the fonts served by that app. If they land on a third app to submit a form, that's another copy of the fonts, and so on.

The current (v2.1.0) version of the font serves all of the font CSS together, meaning a user gets served 2,331 kB of WOFF or 1,305 kB of WOFF2 files. The larger/less efficient WOFF v1 format files go to the users of older and less capable devices, meaning an even worse browsing experience.

Through this lens, a common CDN link is most beneficial to people on poorer internet connections, who are more likely to notice load times. This could be particularly impactful in rural areas of BC with poor connectivity, or in situations like evacuating from a wildfire.

Non-BC government apps that choose to use a common BC government CDN link would get the same caching benefits.

To get the maximum benefit of caching, we would likely want to "choose a winner" and list a single CDN link for each version of the font as our recommended choice. We don't get the same ecosystem effect if project teams add CDN links from a wide variety of sources.

Ease of integration

Developers are already in the habit of using CDN links for resources like fonts, and we have had requests for them over the years through the BC Sans project, the B.C. Design System, and the developer community in general.

Having a single <link> tag to drop into a front-end is trivial, and means the font can easily be used in different project contexts (regardless of whether or not the project has a build systems for using packages from npm or GitHub Packages).

As Aidan mentions above, this is the go-to method for simple HTML pages without a build system.

Trade-offs

Privacy

With third party CDNs, we are at the mercy of their privacy policies and user data handling practices. For example, the Google Font Web API has a FAQ that states that they collect the user's IP address, the referring URL, and the browser user agent information. Contrast that with Bunny Fonts which is a GDPR-compliant alternative that claims no logging.

We will want the blessing of our security/privacy folks to suggest any third party CDN as a recommended choice.

Security

The current state where project teams are encouraged to ship their own copies of the fonts is preferable for some teams from a security point of view. Teams with high security needs are unlikely to want to introduce a third party <link> dependency into their site/app if they can avoid it.

Note that the integrity of the font from a third party CDN can be guaranteed using Subresource Integrity attributes. This is way of telling the browser, "Only use this third party copy of the font file if it matches what I expect its value to be".

Potential for a government-hosted or -procured CDN link

One potential solution is for us to host a common link ourselves. This might not give the same worldwide speed benefits of a third party CDN, but it would give us fine-grained control over logging and any privacy implications. In BC government development ecosystem terms, this solution might be as simple as hosting an Nginx or Caddy server in OpenShift that serves the font and CSS for everyone to use. It would likely need a Privacy Impact Assessment and/or Security Threat and Risk Assessment.

There might also be potential to procure a privacy-focused CDN solution if we decide this is not something we have time/capacity to host ourselves.

[roedoejet]

Thanks for the comprehensive reply here! I'll look forward to seeing what recommendations you make and how they're communicated on the readme. Thanks, too, as always for this critically important work!