Webcarbon

Latest News

Case study: reducing font transfer and client work with WOFF2, variable fonts and targeted subsetting

Case study scenario and constraints

A multi region commerce site needs consistent branding across markets while supporting several writing systems and delivering fast pages on mobile networks. Designers require a primary brand family in five weights and a headline family with stylistic alternates. Business constraints prevent replacing the visual identity. The technical goal is to reduce font transfer and runtime shaping work without losing legibility or key typographic features.

High level approach

The team follows three parallel tracks. First, audit what is actually used on pages. Second, choose the right format and family strategy for each use case. Third, automate subsetting and integrate it into build and delivery so production shows repeatable savings and remains maintainable.

Audit and measurement plan

  1. Inventory fonts used across templates and locales. Record family, weights, italics, features like small caps and stylistic sets, and which pages load which files.
  2. Measure current impact with network and CPU tools. Capture requests and transferred bytes with WebPageTest or browser network panel. Use Lighthouse and CPU traces to observe time spent in font shaping and layout when fonts arrive late.
  3. Map typography needs to pages so critical pages get the smallest possible critical font set. Distinguish above the fold text from secondary content and ephemera such as third party widgets.

Key measurements to collect

Record per font file the uncompressed size, WOFF2 size if available, number of glyphs, and which languages the glyph set covers. Measure first contentful paint and total blocking time before and after font delivery changes. For emissions oriented decisions, capture bytes transferred per page view so you can convert savings into carbon metrics later using a chosen emissions model.

Format and family decision rules

Follow simple decision rules rather than one size fits all.

When to prefer WOFF2 static files

Use a WOFF2 static file for families with large glyph sets where many glyphs are required across pages. Examples include CJK families or symbol heavy fonts. WOFF2 is the current web preferred compressed format for static fonts because it combines compression and broad browser support.

When to prefer a variable font

Choose a variable font when you need multiple weights or widths across the site and the same glyph set can satisfy those uses. Variable fonts consolidate multiple static files into a single file containing one or more continuous axes. This is efficient when the glyph set is not excessively large and when weights are used dynamically in design tokens.

When to subset

Subset when many pages only use a small fraction of a family glyph set. Subsetting is most effective for Latin scripts with limited required punctuation and numerals, and for localized pages where only a specific character subset is needed. Avoid aggressive subsetting where the font is used for user generated content or for search results that may contain arbitrary characters.

Practical subsetting and build integration

The team chose FontTools pyftsubset as the core subsetting tool and WOFF2 compressors where needed. The following example commands are patterns to adapt. Keep test cases and version control for generated fonts so rollbacks are straightforward.

Example: creating a basic Latin subset

Use pyftsubset to create a focused Latin subset containing ASCII letters, digits and basic punctuation. Replace the text string with the exact characters required on a template to avoid missing glyphs at runtime.

Command

pyftsubset input/Brand-Regular.ttf –output-file=out/Brand-Regular.subset.woff2 –flavor=woff2 –text=”ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.,:;!?() %” –layout-features=’liga,kern’ –no-hinting

Notes about the command. The –text option limits the glyphs included. The layout features list should include features that the design relies on such as ligatures and kerning. The exact flags vary by version so confirm options against the pyftsubset documentation in your environment.

Example: handling a variable font

When subsetting variable fonts the team kept the variable axes intact so weight and width interpolation remained available. Use pyftsubset or the variable font tooling supported by your pipeline. Ensure you preserve axis tables and OpenType features required by design. Test the resulting file in browsers that will load it to verify interpolation and features operate as expected.

Automation and per page subsets

Generate page specific subsets during build when pages have stable, predictable content such as marketing landing pages. For dynamic pages and user content, generate per locale subsets instead of per page to avoid exploding asset counts. Store subsets with a predictable naming scheme and add a mapping from template to subset in the build manifest so serving is deterministic.

Delivery and runtime best practices

Delivery choices determine whether savings actually reach users. The team implemented a small set of guardrails.

Preload and font loading

Preload only the single most critical font file required for the initial render. Use rel preload with the crossOrigin attribute when fonts are served from a different origin. Avoid preloading every weight. Use font display swap in CSS to avoid long invisible text windows and test visual stability.

Caching and cache keys

Serve subset fonts with long cache control TTLs and a filename or path that changes when the subset changes. This lets CDNs and client caches reuse files reliably. Avoid data URL inlining for production because inline fonts cannot be cached separately from the page.

Hosting and protocol considerations

Host fonts on the same CDN or domain that provides the rest of static assets to benefit from HTTP/2 multiplexing. Ensure correct MIME types are set and that the server supports ranged requests when needed for partial downloads on browsers that request ranges for fonts.

Validation and QA

After deployment the team ran a small validation suite focused on these points.

  1. Render tests for all language pages. Look for missing glyphs and fallback substitutions. Include automated screenshots at commonly used breakpoints in the CI pipeline.
  2. Performance checks using WebPageTest to confirm fewer bytes are transferred and to spot any regressions in paint metrics from delayed fonts.
  3. Compatibility checks across supported browsers including mobile browsers to ensure the chosen WOFF2 or variable font approach works as expected.

Measuring emissions impact

Translate measured bytes saved into emissions using a consistent model rather than a single fixed factor. The team used a two step approach. First, measure median transferred bytes per page for a set of real user scenarios. Second, apply an emissions conversion method that is explicit about assumptions such as network energy per byte or grid carbon intensity for the hosting region. Document the conversion method so it can be audited and updated as better models become available.

Report emissions changes as relative improvements from the baseline and avoid absolute per visit claims unless the underlying conversion methodology and data sources are published alongside the claim.

Trade offs and decision checkpoints

Keep three decision checkpoints in mind.

  1. Visual fidelity trade offs Decide how much typographic fidelity you can remove without breaking brand intent. Some optical sizing or small cap features may be essential and should not be subset out.
  2. Operational cost Weigh per page subset proliferation against storage and CDN management complexity. Per locale subsets often hit a better operational sweet spot.
  3. Runtime complexity Consider how much client side font shaping you are shifting to the device. Subsets reduce network work but may increase CPU for complex scripts. Measure both network and device work before large rollouts.

Practical checklist for rollout

  1. Run a font inventory and identify critical pages and locales.
  2. Choose between WOFF2 static and variable fonts based on number of weights and glyph set size.
  3. Create and test subsets in a staging environment and validate renders and OpenType features.
  4. Automate subset generation in the build with clear naming and manifest mapping.
  5. Deploy with preload for the critical font only, set long cache TTLs, and monitor real user metrics for bytes and timing.
  6. Convert byte savings to emissions using an explicit conversion method and publish the assumptions used for transparency.

Operational notes and gotchas

Do not remove glyphs that may appear in user generated content or in URLs and hashes which users might copy. Test search boxes and error messages. When using variable fonts, confirm third party systems such as PDF generators or server side tools can handle the format if you use the same font files for non web outputs.

Where quality of shaping matters for complex scripts, prefer broader glyph coverage even when it increases transfer. Correct text rendering and accessibility are higher priority than minimal bytes when those conflict.

Next steps for teams

Adopt the audit and automation steps described here. Start with low risk pages such as marketing landing pages to validate build and delivery patterns and then expand to localized product pages. Keep measurements and the conversion method for emissions in source control so future audits remain reproducible.

Applying these steps helps teams make reproducible decisions about when to use WOFF2, when to adopt variable fonts and where targeted subsetting delivers a reliable return without compromising typography or operations.

Leave a Reply

Your email address will not be published. Required fields are marked *

Leave a Reply

Your email address will not be published. Required fields are marked *