Find the Fonts Your Pages Declare, Download, and Actually Render

A reliable website font loading audit needs two passes. First, inventory font declarations and file references in the source. Then execute the page in a browser to verify which files are requested, which faces render visible characters, and whether delayed or failed delivery changes the layout.

Keep those evidence types separate: a declaration does not prove a download, and a downloaded file does not prove visible use.

Quick start: run the audit in two passes

Use this six-step checklist:

1. Choose representative pages and states. Include major templates, desktop and phone layouts, supported languages, and relevant consent, authentication, or interactive states.
2. Inventory source declarations. Record provider links, @font-face rules, family stacks, variants, properties, and file references.
3. Capture runtime font requests. Execute each test state and observe which font resources the browser requests, when requests begin, and whether files come from cache.
4. Inspect fonts rendered on visible text. Check important headings, body copy, emphasized text, interface controls, and representative characters.
5. Test delayed or failed delivery. Compare fallback rendering with the final state under cold-cache, constrained-delivery, and font-failure conditions.
6. Document findings and validate changes. Attach a confidence level to each finding, implement only evidence-backed changes, and repeat the same test conditions.

This is a proposed audit method assembled from source-inspection capabilities and runtime-verification cautions. It is not a standardized testing protocol.

Organize the evidence into three categories:

Declared in source	Requested by browser	Rendered on visible elements
CSS rules, provider includes, family stacks, and file URLs	Actual requests, timing, cache behavior, and response format	Faces supplying visible characters, including fallbacks
Useful for discovery	Confirms delivery activity	Confirms user-visible relevance
Does not prove a download	Does not prove visible use	Can vary by element, character, state, or browser

For every observation, preserve the page or state, viewport, browser, cache state, connection condition, and relevant interaction. “The heading used Font A” is difficult to reproduce. “The article heading used Font A at this viewport during a cold-cache constrained run” is actionable evidence.

Pass 1: build the source-level font inventory

Search public HTML and accessible stylesheets for:

• Google Fonts links.
• Adobe Fonts or Typekit includes.
• Self-hosted font references.
• @font-face rules.
• font-family declarations.
• Recognizable font-file URLs, including WOFF2 and WOFF.
• Preload directives targeting font files.
• Variables or utility classes that resolve to font stacks.

For each entry, record the family name, ordered fallback stack, provider, source URL, format, weight, style, and any indicated subset or variation. Keep individual faces distinct: a regular face, an italic face, and a variable file covering a range of weights are separate audit entries.

Also capture properties that can alter font selection or rendering:

• font-synthesis
• font-variant properties
• font-feature-settings
• font-variation-settings
• font-optical-sizing
• font-language-override

The font-family property is inherited and contains an ordered list of named or generic families. If it is not explicitly set, its initial value depends on the user agent. Other font properties can affect which face supplies a character and how that face behaves, as described in the CSS Fonts Module Level 4 draft.

A non-executing scan is an inventory aid, not a rendering test. It may miss fonts loaded by JavaScript, gated by consent or authentication, hidden in inaccessible stylesheets, selected only under certain conditions, or referenced through unusual URLs. Commercial source scanners similarly caution that inspecting HTML and CSS cannot compute the live cascade or confirm rendered use; the Web Aloha font checker documentation describes both the source categories it inspects and those limitations.

Do not label a font “used” merely because its family name appears in CSS, and do not assume that a discovered URL serves visible text. Pass 1 produces candidates for runtime investigation.

Pass 2: reconcile declared, requested, and rendered fonts

Load each selected page and state in an executed browser session. Use the browser’s network and rendered-style inspection capabilities to answer two separate questions:

1. Which font resources did the browser request?
2. Which faces supplied the characters visitors could see?

Keep the procedure tool-neutral. Browser interfaces and labels change, but the required evidence remains the same.

Use a worksheet containing:

• Page or state: Route, template, consent status, authentication state, and interaction.
• Visible element: Heading, navigation item, body paragraph, button, caption, or other text.
• Declared stack: The applicable ordered font-family value.
• Requested file: Exact resource URL and format.
• Rendered face: The face reported for the selected text or characters.
• Request timing: When the request began and completed relative to initial rendering.
• Cache observation: Transferred, memory-cached, disk-cached, or otherwise reused.
• Confidence: Source-only suspicion, runtime-confirmed request, or rendered-use confirmation.

Inspect important above-the-fold text first, but do not stop there. Check headings, body copy, bold and italic text, interface controls, punctuation, symbols, and characters from supported languages.

When the three evidence categories disagree, investigate the cause rather than combining them into an ambiguous conclusion. Possible explanations include:

• An inherited family overrides the rule initially inspected.
• Conditional CSS changes the stack at a breakpoint.
• A font downloads for a component that is not currently visible.
• The browser falls back because a requested face fails or lacks a glyph.
• JavaScript applies a class or inline style after initial rendering.
• Text is drawn into a canvas instead of represented by an ordinary element.
• Consent, authentication, or interaction activates another stylesheet or provider.

Repeat material checks across desktop and phone layouts and every state capable of changing font delivery. Before deleting a supposedly unused font, test additional routes, languages, breakpoints, and interactions. One recording can establish only that the font was not observed under that condition—not that it is unused across the site.

Test late arrival, fallback behavior, and layout movement

A font can be visibly important even when the final page looks correct. Compare the initial fallback state with the page after downloadable fonts arrive. Watch for changes in:

• Line wrapping.
• Paragraph and heading height.
• Button or navigation-item width.
• Clipping or overflow.
• The position of nearby elements.
• Missing glyphs or synthesized styles.

Fallback and web-font metrics can differ enough to reflow text and contribute to cumulative layout shift. A settled screenshot captures final geometry, so it can conceal a transition that occurred while a visitor was reading.

Use a proposed test matrix rather than relying on one idealized load:

Cache condition	Delivery condition	What to inspect
Cold	Normal	Initial request timing and fallback state
Warm	Normal	Cache reuse and repeat-view behavior
Cold	Constrained	Duration of fallback display and late changes
Cold	Font delayed or failed	Readability, glyphs, geometry, and synthetic styles

When available, use video, sequential screenshots, or a browser performance recording. Compare initial and final line breaks and dimensions, and measure layout-shift events if the browser exposes them. The absence of movement in a settled screenshot does not demonstrate a lower CLS value.

font-display introduces a design tradeoff rather than a universally correct setting. swap can make the intended face appear eventually, but the change may be conspicuous. optional may retain the fallback during a slow first visit, reducing the chance of a mid-read swap while accepting that the downloadable face might not appear during that visit.

Choose a value based on the typeface’s role, fallback quality, delivery timing, and measured behavior. Do not prescribe one setting for every face, and do not treat the disappearance of visible movement as proof of a numerical CLS improvement without measuring it.

Prioritize delivery changes with a decision table

Prioritize findings by confirmed visible use and observed delivery behavior—not simply by file count or source-code presence.

Finding	Evidence required	Possible response	Tradeoff and validation
Unnecessary family or variant	No rendered use across representative routes, states, languages, and breakpoints	Remove its declaration or file	Risk of breaking an untested state; repeat the coverage set
Noncritical preload	Preloaded file does not serve early visible text	Remove or defer it	Confirm that critical text and request timing do not regress
Critical font starts late	Exact file supplies important early text but is requested late	Test a matching preload	It can compete with other resources; verify exact URL, format, and early use
Weak cache behavior	Repeat navigation transfers the same unchanged file	Review cache headers and versioning	Longer reuse needs reliable invalidation; retest cold and warm visits
Legacy format	The same approved face is available in WOFF2 and supported by target browsers	Test WOFF2 delivery	Confirm rendering, coverage, licensing, bytes, and fallbacks
Oversized variable font	The variable file exceeds the combined cost of the required static variants	Compare static files or a narrower variable build	Compare total bytes, requests, axes, and cache reuse
Third-party request	Runtime evidence confirms an external provider request	Keep, replace, or self-host after review	Evaluate privacy, licensing, maintenance, and actual delivery behavior

WOFF2, effective caching, and fewer unnecessary variants are sensible review points, not automatic fixes. Likewise, preload only a genuinely critical font.

Compare a variable font with the exact static weights and styles the page needs. A variable file may consolidate several variants, but it can be larger than one or two selected static files. Include request count, compressed bytes, cache reuse, rendering behavior, and required axes in the comparison.

Self-hosting removes a third-party font request, but it is not automatically faster. It also makes the site operator responsible for license verification, updates, subsetting decisions, cache policy, and file delivery. Validate the resulting configuration under the same runtime conditions rather than treating the hosting model itself as the result.

Add privacy, licensing, and compatibility gates

Record every external font provider found in the source and confirmed at runtime. Remote font requests may expose visit-related information such as an IP address and referrer to the provider, making delivery architecture a privacy review point, as the Web Aloha guidance notes. The source inventory identifies possible providers; the browser recording establishes which requests occur.

Before copying, converting, subsetting, or self-hosting a font, verify the applicable license and the proposed use. Do not infer permission from technical access. Route uncertain terms to someone qualified to review them.

Coverage changes also require content testing. Before removing a variant or reducing a subset, check representative:

• Languages and writing systems.
• Accented characters.
• Punctuation and quotation marks.
• Currency and mathematical symbols.
• Uncommon names and editorial characters.
• Icon-font code points, if applicable.
• Bold, italic, and synthesized styles.

Standards status is another compatibility gate. CSS Fonts Module Level 4 is a W3C Working Draft dated 7 September 2026, not a finalized Recommendation. Verify advanced behavior—especially features identified as at risk—in the browser versions the site supports. Aggregate test totals can help identify areas to investigate, but they do not prove complete interoperability.

Report findings with confidence and a validation step

Each final finding should contain:

• Affected page and element
• Declared font or stack
• Runtime evidence
• User-visible symptom
• Confidence
• Proposed change
• Implementation risk
• Post-change validation

Use evidence-based confidence labels:

• Source-only suspicion: A declaration or file reference was found, but no request or visible use has been confirmed.
• Runtime-confirmed request: The browser requested the resource under a documented condition.
• Rendered-use confirmation: The face supplied visible characters on an identified element.

A useful finding might read:

On the article template at the tested phone viewport, the main heading declared Family A followed by a system fallback. The browser requested the regular Family A file after initial text appeared, and rendered-font inspection confirmed that the downloaded face supplied the heading after arrival. The heading changed line breaks during the transition. Confidence: rendered-use confirmation. Proposed change: test an earlier fetch or a better-matched fallback. Validation: repeat the same cold-cache constrained run and compare request timing, line breaks, and measured layout-shift events.

Record before-and-after observations under the same browser, viewport, cache state, connection condition, route, and interaction.

The practical sequence is straightforward: inventory the source, verify requests and rendered faces at runtime, reproduce delayed or failed loading, prioritize only evidence-backed changes, and rerun the same conditions after implementation. The goal is not to remove every font request. It is to make every visible font choice intentional, validated, and compatible with the site’s performance, privacy, licensing, and rendering requirements.