Plan Font Glyph Budgets for Performance Targets

A display face the design team loved projected over a 35 KB heading budget even at Latin Basic. That's the analyser doing its job — it killed a bad choice before it reached the critical path and hurt LCP.

Candidate: Display-Bold.woff2
current_woff2_estimate_bytes: 96000
budget (heading): 35000

Latin Basic projection: ~21 KB  -> fits? would, BUT
the brand needs Latin Extended (Polish + Czech market):
Latin Extended projection: ~52 KB -> over budget by 17 KB

Verdict: too heavy for this market. Pick a lighter display face
or drop a weight from the budget.

A 1 MB page budget allocating 75 KB to fonts, spread over body, heading, and mono. Each candidate is analysed; the projections have to sum under 75 KB.

Allocation: 75 KB total for fonts.
  Body  (Inter, Latin Basic):     ~22 KB
  Head  (Fraunces, Latin Basic):  ~28 KB
  Mono  (JetBrains, Latin Basic): ~20 KB
  -----------------------------------------
  Sum: ~70 KB  -> under 75 KB budget. Ship.

If the sum had exceeded 75 KB: drop mono to a system stack with
the system font stack generator, reclaiming ~20 KB.

The analyser projected 22 KB for the body font's Latin subset; the real subset came out at 19 KB. The 1.25× overhead factor makes the projection lean high, so budgets set against it rarely blow when the real file ships.

Projection (analyser): estimated_woff2_bytes = 22000
Real subset (font-subsetter output):        19100

Delta: -13%  (real file UNDER projection)

Lesson: set the budget at the projection. If the real file lands
under it, you have headroom for a foundry update later.

Run the analyser through the runner API on each build and fail if the full-font baseline grew beyond what your subset budget can absorb. Empty schema means you just POST the file.

#!/usr/bin/env bash
set -e
JSON=$(curl -sS -X POST \
  http://127.0.0.1:9789/v1/tools/glyph-count-analyzer/run \
  -F 'files=@public/fonts/Body.woff2')
LATIN=$(echo "$JSON" | jq '.projections[]
  | select(.subset|startswith("Latin Basic"))
  | .estimated_woff2_bytes')
if [ "$LATIN" -gt 24000 ]; then
  echo "Body Latin subset projects ${LATIN}B > 24KB budget"; exit 1
fi

A family needs four weights. The analyser shows the variable file's glyph total is the same as one static, but the variable WOFF2 replaces four files. Compare the variable size to the sum of four static subsets to decide.

Four static Latin subsets:  4 x ~20 KB = ~80 KB
One variable Latin subset:  ~38 KB (one file, all weights)

Variable wins the budget at 3+ weights. Freeze unused axes first
with the variable font freezer, subset, then re-analyse to confirm
the single-file size fits the per-family budget.

The proportion × 1.25 factor inflates the projection to account for per-glyph table overhead, and the real subset usually comes out a bit under. That's intentional for budgeting: a budget set at the projected number gives you a small safety margin. The risk is the other direction — for complex scripts the projection can under-shoot — so verify the real subset before locking a tight budget.

If you analyse the source TTF instead of the built WOFF2, the baseline is sfnt × 0.55, a guess. A font with heavy hinting compresses worse than 0.55× and your projections under-state the real size — dangerous for a tight budget. Always feed the analyser the actual WOFF2 you intend to ship so the baseline, and every projection scaled off it, reflects real bytes.

A common error is comparing the budget to current_woff2_estimate_bytes (the full font) and concluding the font is too heavy. The budget should be compared to the projected size of the subset you'll actually ship. A 90 KB full font that projects 18 KB at Latin Basic fits a 30 KB budget fine — you just have to subset it. Read the projection row, not the headline.

total_glyphs includes small-caps, oldstyle figures, and other OpenType-feature glyphs you may not ship. If your subset strips those features, the real file is lighter than a naive read of the glyph count suggests — but the projection already works off codepoint coverage, not the raw total, so the projected size is closer to reality than the total glyph count would imply. Don't budget off total_glyphs directly; budget off the per-subset estimated_woff2_bytes.

If a page renders both Latin and Cyrillic, you can't pick one subset — you ship both, and the budget must cover the sum (or a single combined subset). The analyser projects each independently; add the rows for the scripts you actually render. Better: ship separate unicode-range @font-face blocks so each visitor downloads only the script on their page, and budget per-script.

Icon fonts map into the Private Use Area, which none of the six subsets cover, so every projection shows ~100% savings and a near-floor size. That would suggest a near-free budget, but subsetting to "latin" would delete every icon. For icon fonts, ignore the subset projections and budget against the whitelisted-glyph build from the character whitelist builder.

A font above the active tier's size limit (free 5 MB / pro 50 MB / developer 1 GB) is refused with "exceeds the {tier} tier per-job limit" before parsing — you can't even get a projection. Large CJK fonts hit this routinely on the free tier. For those, see the CJK considerations guide, which covers the size realities up front.

Budget is about bytes; LCP is about bytes plus when they're fetched. The analyser only gives you the bytes. A font that fits the budget can still hurt LCP if it's discovered late — <link rel=preload> and font-display: swap fix the timing. Plan the byte budget here, then plan the timing with the preload tag builder and the font-display strategy tool.