Managing static files

This is a relatively cheap way to

boost client performance and UX
allow sites to upgrade on their own schedule
increase fault tolerance

Branching

Recommend gitflow branching where the content of every release is reflected in a regular branch.

Build, Continuous Integration and deployments work the same with release branches as with any feature branch.

Gitflow provides conventions for hotfixes, BAU feature work and shared integration branches.

NB: gitflow is integrated into SourceTree, the Atlassian GUI git client.

Building

We want the content fingerprint to be included in the URL so we can cache files aggressively.

Here a file's fingerprint is a unique alphanumeric string based on its content.

When it changes, it will have to be downloaded from a new URL, making sure the latest version is used.

Build task has been extended to publish recursively fingerprinted assets into `/cdn` directory, meaning that logos, fonts and icons are also fingerprinted.

We should continue leveraging CI to build and deploy static assets; it may be worth investigating an alternative stack that better integrates with other Atlassian products.

Serving

A managed server would be preferable to github pages

Serve static content from a cookie-less domain or multiple
Remember enabling CORS for resources that need it (js, fonts)
Set lifetime caching for fingerprinted assets, but
Explicitly set no caching for assets without a fingerprint (on the off chance we want to link the latest version of an asset directly)
Environments mirroring development process (dev/stage/prod)
...

We should check as many performance checkboxes as practical.

Github pages may still be used for edge/latest and documentation.

CMS integration

With static content served from unique URLs, entry points referenced in the CMS would have to reference them correctly.

Build task generates a json manifest mapping resources to their fingerprinted aliases:

{
  ...
  "assets/toolkit/images/logo-wide.svg": "assets/toolkit/images/logo-wide.228a2196.svg",
  "assets/toolkit/scripts/toolkit.js": "assets/toolkit/scripts/toolkit.6056a7f4.js",
  "assets/toolkit/styles/toolkit.css": "assets/toolkit/styles/toolkit.a1325718.css",
  ...
}

Alternatively, we could extend the build task to generate html fragments linking css, javascript or logos (or any other top-level entry point).

These fragments can then be rendered into the page with Squiz tools (file/git bridge or api integration).

Third-party CDNs

Leveraging their capacities would help shave off additional time load time, but these improvements would be more meaningful once the fundamentals are taken care of.

Most work best on top of correct caching policies like the ones proposed in #building

These tools can still provide additional benefits:

superseding Varnish over the CMS as a more user-friendly html/json content caching option
optimising imagery with Polish and Mirage (CloudFlare offering)
global delivery network improving performance ranking and international UX