Fonts in the shop: licensing, self-hosting, load behaviour

A font rarely arrives in a shop on its own. It brings a licence text, a handful of files, a rule in the stylesheet and, in the unfavourable case, a connection to somebody else's machine. Web fonts were found on roughly 88 per cent of the websites examined in 2025, and around 72 per cent serve at least one font file from their own origin (HTTP Archive Web Almanac). Between those two figures sits exactly the part of a shop this article is about: who owns the font, where it is served from, and in which order it reaches the customer. Clarifying those three questions in that order saves two discussions at once – the one about PageSpeed and the one about data protection.

Why fonts hurt in two places at the same time

A web font is a design asset, licensed software and a network resource in one. Three separate checks follow from that triple role, and in day-to-day work they tend to merge into one. The licence says whether the file may sit on a web server at all, and for how many page views. The place of delivery determines whose server sees the customer's request, and therefore whose privacy notice applies. And the way it is embedded decides whether body text is readable straight away or only once a file has arrived over the network. Anyone who looks only at the third question speeds up a chain whose first link may not hold up legally.

Technically the font sits at the end of a sequence. The browser loads the HTML, finds the stylesheet in it, loads that, discovers an @font-face rule and only then works out which file it needs. It is requested later still – once an element actually uses that font family. Those are three consecutive network round trips before the first byte of the font is on its way, and during that time the text either stays invisible or appears in a fallback font. If the file also comes from a foreign origin, name resolution and a fresh TLS handshake are added, both of which the shop's own server has long since completed.

A font does not block the page. It blocks the text - and the text is the reason the customer came.

XICTRON development team

In a shop this weighs more heavily than on a brochure page. Price, availability and shipping information sit in the body text, not in an image. If that text shifts while the customer is reading it, the button underneath shifts too. The effect is measurable and feeds into the Core Web Vitals, but it is above all unpleasant at checkout: a click that lands on nothing is rarely repeated. That is precisely why fonts belong in the discussion of load behaviour and not solely in the design column.

The licence comes before the technology

Fonts are licensed, not bought. A desktop licence typically permits use on workstations, meaning the setting of adverts, labels or a catalogue. As a rule it does not cover the file being delivered to unknown third parties over a web server – that is what the web font licence is for, and it is a separate contractual object. Anyone copying a font file from the design folder into the web directory has changed the purpose of use without adjusting the contract. That is the most frequent licensing mistake in the shop environment, and experience shows it only comes to light when somebody asks.

Web font licences are often measured in page views. Some licensors count monthly, some grant a one-off allowance, some sell perpetual use for one domain. For a shop whose reach grows over the years, that is a figure with an expiry date: what fitted at the time of the order may sit outside the licensed scope three seasons later. The licence scope therefore belongs not only in the designer's folder but in the same place as domain contracts and certificates – with term, allowance and contact person.

• Does the licence cover delivery over the web? A desktop licence is as a rule not sufficient for this, even though the file works technically.
• How many page views does the allowance cover? Note the figure together with its period, plus the place where current consumption can be read off.
• Is transfer to service providers permitted? Agency, host and development environment touch the file as well; some contracts require separate consent for that.
• May the file be subsetted? Subsetting produces a modified file. Some licences permit this explicitly, others prohibit any modification.
• Does the licence apply to all environments? Preview, staging and live are three domains; whoever licensed only the live domain is serving without cover elsewhere.
• Where is the proof? Invoice, licence text and date belong in the project directory, not in a mailbox.

The second licence breach happens at handover. If the shop changes agency or moves to a new server, the font files naturally travel with it – the licence contract, by contrast, often stays with whoever signed it. If the licence is issued to an agency rather than to the merchant, the right of use ends with the working relationship while the files continue to be served. When taking over an existing shop it is therefore worth asking a question that is rarely asked: in whose name is the font licence, and is the contract available?

Self-hosting: the origin decides

Technically a font from a foreign server is an entirely ordinary resource – with one difference: the browser opens a separate connection for it and in doing so transmits the visitor's IP address to a machine that does not belong to the shop operator. This happens without the customer doing anything, before they have clicked on anything at all, and it cannot be prevented with the browser's own means. It is exactly at this point that a design decision turns into processing of personal data, for which a legal basis is required.

How seriously that is taken is shown by a decision of the Regional Court of Munich I of 20 January 2022 (case no. 3 O 17493/20). The court awarded a website visitor 100 euros because, when a page was called up, the font was loaded dynamically from an external provider and the IP address was transmitted in the process (LG München I). The decision is a single first-instance judgment and not a supreme court standard. Its practical effect lies less in the sum than in the line of reasoning that has appeared in many warning letters since: the dynamic embedding was avoidable, because local delivery of the same font would have been possible.

The practical answer is unspectacular: the file is downloaded, placed in a directory of your own shop and served from there. That removes the transmission, the consent question no longer arises for the font, and the file falls under the same rules as any other image or script in the shop. How far a shop can detach itself from foreign requests overall is described in the article on running a shop without a consent banner. For fonts the route there is the shortest, because no functionality is lost along the way.

Font inventory in an existing shop

A count comes before the first change. In shops that have grown over time, fonts sit in more places than expected: in the theme, in two extensions, in an old page builder, in the icon font of the navigation and frequently once more in the administration interface. Each of these places loads its own files, often in different weights of the same family. Optimising without that count means shrinking one file and overlooking four others – and then wondering why the measurement barely moves.

The count has two parts. The first is static: which files sit in the project, which @font-face rules exist, which families are called up in the CSS at all? The second is dynamic: which files does the browser actually request on a real page view, in what order and from which origin? Together they produce the work list. The static part shows what is present, the dynamic part shows what of it costs loading time. Experience shows these two sets overlap only partly.

1. Find the files: list all font files in the project tree, with path, format and size. Duplicate families in different directories are the usual finding.
2. Find the rules: collect all @font-face blocks, including those in extensions and in the page builder. Each rule names a family, a weight and at least one source.
3. Check usage: for each family determine which rule actually applies it. Families without usage are the quickest win, because they can simply be dropped.
4. Measure origins: load a real page and log every font request with its origin. Foreign origins go on the list, regardless of format.
5. Count the weights: record for each family which stroke weights and slants really occur in the layout. Four weights are four files.
6. Check icon fonts: icon fonts are fonts with their own side effects and belong on the same list, see accessibility in the shop.

Icon fonts deserve separate consideration here. They carry meaning through glyphs that a screen reader cannot output meaningfully, and they fail when the font does not load – what remains in that spot is an empty rectangle or a random character. For the few symbols a shop actually needs, a small collection of SVG graphics is usually the calmer route: it loads with the HTML, has no fallback rendering and carries its meaning in a title. The side effect is one file less in the load chain.

Format and subsetting: WOFF2 and character ranges

For delivery on the web there has been exactly one sensible format for years. WOFF2 packs the font data with Brotli plus a preprocessing step that removes redundancy in the font's tables; the W3C specification names exactly those two sources of gain. The accompanying evaluation report puts the advantage over WOFF 1.0 for fonts with TTF outlines at a median of 23.94 per cent in one and 26.79 per cent in the other corpus examined, and for fonts with CFF outlines at 13.51 per cent (W3C). In practice, around 65 per cent of all font requests in 2025 were WOFF2 (HTTP Archive Web Almanac) – among self-hosted fonts on mobile pages it was around 74 per cent, alongside roughly 18 per cent WOFF and around 8 per cent raw TTF (HTTP Archive Web Almanac). That remainder is where a gain is available without any change to the design.

How much there is to gain is shown by a look at the median: font files typically weigh around 35 to 36 kilobytes in the middle field, with hardly any difference between mobile and desktop requests (HTTP Archive Web Almanac). Four weights of an unsubsetted family quickly reach a multiple of that, while subsetting to the character set actually required often lands at a fraction. Because WOFF2 is already packed, additional compression by the server gains nothing here – unlike with CSS and JavaScript, where it pays off, as the article on Brotli compression shows.

Load behaviour: font-display, preloading, fallback metrics

The font-display descriptor decides what the browser does while the font is in transit. With block the text stays invisible briefly, with swap it appears immediately in the fallback font and is exchanged later, with optional the browser skips the exchange entirely on a slow connection. In the 2025 crawl, swap appeared on around 49.6 per cent of desktop pages and around 50.1 per cent of mobile pages (HTTP Archive Web Almanac), making it the widespread choice. For a shop it is usually also the right one, because price and availability should be readable before the design is complete.

A fallback font with different metrics from the target font shifts the layout at exactly the moment the customer is already reading.

XICTRON development team

The price of swap is the visible jump at the exchange. It can largely be caught by trimming the fallback font to the metrics of the target font. There are four descriptors for this: size-adjust scales the character width, while ascent-override, descent-override and line-gap-override set the vertical metrics. A fallback family prepared this way occupies the same space as the later target font, and the exchange becomes barely noticeable. The gain shows up directly in the layout shift measured by the Core Web Vitals.

Preloading helps because it shortens the chain. A preload hint in the head of the page (rel=preload, as=font, type=font/woff2, crossorigin) starts the request before the stylesheet has been evaluated. It is not yet widespread: in 2025 around 12.0 per cent of desktop pages used a preload hint and around 18.3 per cent an early connection setup; on mobile pages the shares were around 11.7 and around 17.7 per cent (HTTP Archive Web Almanac). Two points belong with it. First, a preload hint is only sensible for the one or two files needed in the first screen area – every further line pushes something else out of the queue. Second, the line needs the crossorigin attribute, even when serving from your own origin; without it the browser loads the file a second time.

The rules in the stylesheet

Put together, this yields a manageable configuration: one file per weight, one format, one subset with a matching character range, font-display: swap, a trimmed fallback family and a preload hint for the weight that becomes visible first. The following example shows the complete block for a family with two weights. The values of the fallback metrics are example values; they are determined once per font pair and do not change afterwards.

/* One weight, one format, one character range. */
@font-face {
  font-family: "Shop Font";
  src: url("/assets/fonts/shopschrift-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF, U+0131, U+2000-206F, U+20AC, U+2122;
}

@font-face {
  font-family: "Shop Font";
  src: url("/assets/fonts/shopschrift-700.woff2") format("woff2");
  font-weight: 700;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF, U+0131, U+2000-206F, U+20AC, U+2122;
}

/* Fallback family, trimmed to the metrics of the target font. */
@font-face {
  font-family: "Shop Font Fallback";
  src: local("Systemschrift"); /* replace with the name of the font available locally */
  size-adjust: 97.4%;
  ascent-override: 92.8%;
  descent-override: 24.4%;
  line-gap-override: 0%;
}

:root {
  --font-text: "Shop Font", "Shop Font Fallback", system-ui, sans-serif;
}

body {
  font-family: var(--font-text);
}

Three details in this block are, in our experience, the ones that get lost when it is rebuilt elsewhere. The character range has to match the subset of the file – if a range is declared that the file does not contain, the browser loads it anyway and then does not find the characters. The fallback family has to sit before the generic names in the font list, otherwise it does not take effect. And the preload hint belongs in the head only for the weight that actually occurs at the top of the page; for the bold emphasis in the footer it is wasted.

The measurement afterwards consists of two views. The first goes into the network panel of a real page view: how many font files are requested, from which origin, how large are they and when do they start? The second goes to the field data, because in the lab a fast connection looks different from a request over a mobile network on a station platform. Why that difference matters and how the two can be brought together is set out in the article on field data over lab scores.

• Number of font requests per page type: count home page, category, product, basket and checkout separately; the checkout often carries components of its own.
• Origin of every request: every request that does not go to your own domain belongs on the list – including those from embedded components.
• Start time of the first font file: it shows whether the preload hint takes effect or whether the file is requested only after the stylesheet.
• Layout shift at the exchange: measure before and after trimming the fallback font, otherwise the effect remains an assertion.
• Transferred size per file: the figure from the network panel counts, not the file size on disk.

What goes wrong in daily operation

The changeover itself is done in a morning. What costs time are the places that undo it again. Almost all of them have the same cause: a font is configured not in one place but in several, and those places do not know about each other. Six cases keep coming up.

• The update brings the foreign embedding back: a theme or extension update overwrites the adjusted template. The adjustment therefore belongs in a child theme or an extension of your own, not in the delivered file.
• The administration interface loads differently from the shop: it is not public, but it processes staff data. Anyone ordering access rights there anyway can take the font requests along – fitting with the article on roles and permissions in the backend.
• Embedded components bring their own fonts: review displays, map sections and video embeds load fonts of their own. They fall under the same consideration as other third-party scripts in the shop.
• The file sits among the images: fonts belong in their own directory with their own naming, otherwise they end up in the clean-up runs of media management.
• The cache holds the old file: after subsetting, the new file carries the same name and is not reloaded. A name component with a version number solves that permanently.
• The email template uses the same family: order confirmations cannot load a web font. A list of system fonts belongs there, otherwise the appearance differs between shop and mailbox.

Procedure and sign-off

In the order in which it pays off: first count, then clarify the licence, then move delivery to your own origin, then unify and subset the format, then order the load behaviour and finally measure. This order is not arbitrary. Starting with preloading may well speed up a file that is not allowed to be served at all once the licence has been checked, and tunes a chain that is going to be rebuilt afterwards anyway.

The work is signed off when four statements are evidenced: for every font file served there is a proof of licence. No page type requests a font from a foreign origin. Every file is present as WOFF2 with the character set the shop actually needs. And the layout shift at the font exchange has been measured before and after. Writing those four points into a short log produces at the same time the record for the next development round and for every query from data protection. How the step fits into ongoing e-commerce support and what it means in combination with hosting and operations is settled faster on the existing system than on the drawing board – the entry point for that is a survey of the load chain.