Guide 12 · Developer docs

Performance, caching, deployment and go-live

How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.

L2–L3
Unit 02 · Making pages fast

Fonts and third-party scripts

Making pages fast Page 13 of 34 Updated

Two costs that never show up in your own bundle: web fonts and the layout shift they cause, and scripts added through a tag manager after launch. The technical fix for each, and the governance one for the second.

Who this is for. Theme developers setting up a site's head, and whoever agrees with the client how marketing tags get added. Afterwards you can load fonts without invisible text or a jumping page, and keep third-party scripts inside a budget a year after launch.

Fonts and third-party scripts have one thing in common: they are easy to add and nobody measures them. A font that swaps in late moves every line of text on the page; a tag added in a tag manager on a Friday afternoon can double the JavaScript a page runs. The first is a technical problem with a technical answer. The second needs a technical answer and a rule about who may add what.

Loading fonts

Four decisions cover almost all of it:

  1. Self-host woff2 files in the theme. The platform serves .woff and .woff2 from the site folder without any configuration, a font on the site's own origin needs no extra connection, and browsers keep it for a year like any theme file.
  2. Use font-display: swap on every @font-face, so text is shown at once in a fallback font and swapped when the web font arrives, instead of staying invisible.
  3. Preload only the fonts the first screen uses, usually the body weight and one heading weight. Every preload competes with the hero image and the stylesheet for the first moments of bandwidth.
  4. Load fewer weights. Each weight and style is a separate file. Four weights of one family is usually two too many.

A production store on Core dna does exactly this: every @font-face uses swap, and the base template preloads two text weights and the icon font, leaving the other weights to load when used.

Template code templates/includes/base-template.html, in the head 
<link rel="preload" as="font" type="font/woff2" href="/static/fonts/brand-regular.woff2" crossorigin>
<link rel="preload" as="font" type="font/woff2" href="/static/fonts/brand-bold.woff2" crossorigin>
<link rel="stylesheet" href="/static/css/styles.css?v={$_currentSite->getLastVcsHash()}">
<link rel="preload" as="font" type="font/woff2" href="/static/fonts/brand-regular.woff2" crossorigin>
<link rel="preload" as="font" type="font/woff2" href="/static/fonts/brand-bold.woff2" crossorigin>
<link rel="stylesheet" href="/static/css/styles.css?v={{ _currentSite.getLastVcsHash() }}">

A preloaded font needs crossorigin even on the same origin, because browsers fetch fonts in CORS mode; without it the preload is wasted and the font is downloaded twice.

The layout shift a font causes

swap trades invisible text for a moment of movement: the fallback font has different widths and line heights, so when the web font arrives every line can reflow and push the page down. To keep the swap small, give the fallback the web font's proportions with a second @font-face that adjusts a local font:

CSS 
@font-face {
  font-family: 'Brand fallback';
  src: local('Arial');
  size-adjust: 105%;
  ascent-override: 92%;
  descent-override: 24%;
  line-gap-override: 0%;
}
body { font-family: 'Brand', 'Brand fallback', sans-serif; }

Take the four values from the web font's own metrics (font tools and several online generators produce them), then check the result in the browser's Performance panel, which reports the layout shift and the element that caused it. Icon fonts shift too, as a box of the wrong width; giving icons a fixed width in CSS prevents it.

Third-party scripts and the tag manager problem

A tag manager lets marketing add analytics, chat widgets, heat maps and advertising pixels without a deploy. That is its purpose, and it is also why those scripts are outside your build, your budget and your review. On a site that has been live for a year, the tag manager often loads more JavaScript than the theme, and none of it is in the repository.

Two facts on Core dna shape how it is set up:

  • The content security policy is a setting. Security › CSP policy defaults to script-src 'self' https://cdnjs.cloudflare.com 'nonce-%nonce%': scripts from the site itself, from cdnjs, and inline scripts that carry the page's nonce. Every domain a tag loads a script from must be added there, or the browser refuses it and reports the refusal in the console. Each new vendor is therefore a settings change, which is a natural review point.
  • Inline snippets need the nonce, the same as your own scripts:
Template code 
<script nonce="{$_inlineScriptNonce}">
  (function (w, d, s, l, i) { /* the vendor's loader, unchanged */ })(window, document, 'script', 'dataLayer', 'GTM-XXXXXXX');
</script>
<script nonce="{{ _inlineScriptNonce }}">
  (function (w, d, s, l, i) { /* the vendor's loader, unchanged */ })(window, document, 'script', 'dataLayer', 'GTM-XXXXXXX');
</script>

Technically: load the container with async, add a <link rel="preconnect"> for its domain, and configure the tags that are not needed at once, chat and heat maps above all, to fire after the page has loaded or on the first interaction rather than on page view.

Governance: the answer that lasts

The technical measures last until the next tag. What keeps a site fast a year after launch is an agreement, made at handover, about how tags get added:

  • One named owner for the tag manager on the client's side, and changes published only by them.
  • A list of approved tags, each with its purpose and its weight in kilobytes, kept with the site's documentation.
  • A budget for third-party JavaScript, set like the theme's (a budget per page type). A new tag that breaks it replaces an old one or is not added.
  • Changes tested on staging first, in the tag manager's preview or a staging container, because a broken tag can break the checkout as easily as your own code.
  • A quarterly check: load the main page types signed out, group the waterfall by domain, and compare with the approved list. Remove what nobody can explain.

Write this into the handover pack rather than leaving it to good intentions (Handover). An agency is judged on how fast the site is in a year, not on how fast it was on launch day.

Go deeper
GuideThe CSP nonce GuideHandover GuideBundle size How-toRegister a page-specific JS bundle with a CSP nonce

Was this page helpful?

Your answer goes to the docs team.