A team argues that loading their webfont from a public font service such as Google Fonts is faster than self-hosting the woff2. Which part of that argument stopped being true, and what does self-hosting change about the critical path?

## The claim that expired For years the standard defence of a public font service was cache reuse: fonts are large, popular families are used everywhere, and a browser that had already fetched one on any site could serve it from cache on yours. The reasoning was sound while the HTTP cache was a single global store keyed by URL. It is not any more. Browsers partitioned the HTTP cache by top-level site to close a class of cross-site tracking and history-leak attacks: an entry cached while browsing site A is not visible while browsing site B, even for a byte-identical URL. Chrome shipped this in version 86 (2020), Firefox in 85, and Safari had partitioned for longer. The practical consequence for fonts is total — the first visit to your site downloads the font regardless of what the visitor did elsewhere, so the shared-cache benefit is zero. (This is the version-sensitive part of the answer: on a browser predating partitioning the old argument still held.) ## What the third-party path actually costs The usual integration is a `<link rel="stylesheet">` pointing at a CSS file on the service's origin. That CSS contains the `@font-face` rules, whose `src` URLs point at a *second* origin used for the binaries. So the browser's work looks like this: 1. Parse the document, discover the third-party stylesheet. 2. DNS + TCP + TLS to the stylesheet origin. 3. Download the CSS. This is a render-blocking stylesheet, so it sits on the critical path. 4. Only now are the font URLs known. 5. DNS + TCP + TLS to the *font* origin. 6. Download the font files. Two fresh connections, and — more importantly — a **serial dependency chain**: the font cannot even be discovered until a request to another host has completed. Every hop is a full round-trip cost on a mobile network, and none of it is parallel with anything. Self-hosting removes steps 2, 4 and 5. The `@font-face` rules are in your own CSS on your own origin, the font URLs are stable and known at build time, and the fetch reuses the connection the browser already opened for the document. On HTTP/2 or HTTP/3 that is a large structural saving, not a marginal one. ## What else self-hosting buys - **Control of the file.** You choose the subset, the axis range of a variable font, and whether to split by script. A service picks for you, well but generically. - **Control of cache headers.** A hashed filename plus a long-lived immutable cache policy means repeat visits never revalidate. You cannot set headers on someone else's origin. - **Stable URLs you can prioritise.** Because you know the exact file at build time, the font can be given elevated priority rather than being discovered late. - **Fewer third-party failure modes.** One less origin whose outage, latency or DNS problem shows up as your slow page. - **Jurisdictional considerations.** Sending visitor IP addresses to a third-party host has attracted regulatory attention in some jurisdictions. Not a performance argument, but it is frequently the argument that actually decides the ticket. ## What the service still does well Be fair to the other side in an interview, because a good answer is not a slogan: - It serves a **per-browser-optimal format** and, for large families, **per-script `unicode-range` slices**, without you building anything. - It has broad edge presence, so the font bytes come from nearby. - It removes maintenance: no build step, no licence file to track, no re-subsetting when the locale set grows. For a small site with no build pipeline, that convenience can outweigh the connection cost. For a product that already has a build, self-hosting is strictly better on the metrics and costs a few lines of pipeline. ## If you must keep the third party The mitigations are about the connection chain, since that is what remains: warm the connection to the font origin early, and be aware the font host must be connected to with credentials mode matching the CORS fetch fonts use — a mismatched warm-up connection does not get reused. Keep the number of families and weights requested to the minimum, since each adds to the same serial chain. ## How to answer this in an interview Lead with the cache-partitioning fact, because it is the specific piece of knowledge being probed and it retires the popular argument outright. Then describe the request chain rather than asserting "self-hosting is faster" — the chain is the mechanism, and it is what makes the answer credible.