How many font files should a page load?

As few as the design allows, and the tool's verdict calls one or two files lean and anything past four heavy. Each file is a request on the critical path, so a plan with six weights across two families is twelve requests unless the weights are consolidated into a variable file or dropped.

What should be preloaded?

Only the files used above the fold, usually a single body weight and sometimes one heading weight. Preload tells the browser to start the request immediately and at high priority, so adding more files to that list competes with the images and scripts the first screen also needs.

How much does subsetting save?

The tool uses typical figures: about a third of the size for latin only, a little over half for latin extended, and around 40 per cent for a unicode-range split. The real saving depends on the file, so the estimate is there to justify the work rather than to replace measuring the result.

Why is a third-party font host a bigger decision than it looks?

Because it adds a domain to resolve and a connection to open before the font can arrive, and the page's rendering then depends on someone else's uptime and response headers. Preconnect mitigates the handshake but not the dependency, which is why self-hosting is worth costing out at the same time.

Which display policy fits an e-commerce page?

Swap in most cases, because readable text immediately is worth one re-render, and a product name that is invisible for a moment costs more than a change of letterforms. Optional is worth considering where any movement is unacceptable, accepting that a slow connection may never show the webfont.

Font Loading Strategy Builder

Budget

Families

Weights per family

Average file sizeKB

Files preloaded

Subsettingfont-displayHostingExample font path

Font files requested6

Total if unsubsetted132 KB

After subsetting46 KB

Preloaded (blocking)1 file(s)

Verdictheavy — consider consolidating weights or subsetting further

Self-hosting removes the third-party connection and gives you full control of caching and headers.

Strategy table

Concern	Decision	Why
Above the fold	preload 1 file(s)	preload is a hint that the request must start immediately
Everything else	normal discovery via @font-face	unused weights should not compete with the critical path
Swap period	font-display: swap	readable text immediately, one re-render
Character set	latin	subsetting is the single largest size reduction available
Layout shift	match fallback metrics with the override descriptors	the fallback is what most first visits see

HTML head

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<!-- preload only what is used above the fold (1 of 6 file(s)) -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/racira-sans-400-300.woff2" crossorigin />

@font-face set

/* One @font-face per weight — each is a separate file the page must fetch. */
@font-face {
  font-family: "Racira Sans";
  src: url("/fonts/racira-sans-300.woff2") format("woff2");
  font-weight: 300;
  font-display: swap;
}

@font-face {
  font-family: "Racira Sans";
  src: url("/fonts/racira-sans-400.woff2") format("woff2");
  font-weight: 400;
  font-display: swap;
}

@font-face {
  font-family: "Racira Sans";
  src: url("/fonts/racira-sans-500.woff2") format("woff2");
  font-weight: 500;
  font-display: swap;
}

/* Defer the weights the first screen does not use. */
@media print { .deferred-fonts { font-family: serif; } }

You Might Also Need

@font-face Generator

Generate @font-face rules

CSS Variable Font Builder

Build variable font CSS

System Font Stack Generator

Generate system font stacks

Google Fonts CSS Generator

Generate Google Fonts links

The font loading strategy builder does the arithmetic a font plan depends on: how many files a page asks for, how much they weigh, how many can be preloaded, and which of the loading trade-offs the project is choosing. Every extra weight is another request on the critical path.

What is Font Loading Strategy Builder?

The font loading strategy builder turns a font plan into numbers. Families multiplied by weights gives the file count, the file count multiplied by the average file size gives the transfer, and a subsetting factor applied to that gives what the visitor actually downloads.

Five decisions are made explicitly rather than left to default.

How many files are preloaded, which should be the ones used above the fold and nothing more, since preload is a hint that the request must start immediately.
The font-display policy, which decides what the visitor reads while the files arrive.
The subsetting approach, with typical reductions stated: latin only at roughly 35 per cent of the full size, latin extended at 55 per cent, and a unicode-range split at about 40 per cent, against no subsetting at all.
Where the files are hosted, self-hosted or through a third-party service.
The average file size, which is the one figure only the project can supply and the one that makes the total honest.

The verdict bands are deliberately blunt. One or two files with a single preload is lean. Up to four files is acceptable as long as the preload list stays at one or two. Beyond that the plan is heavy, and the advice is to consolidate weights or subset further rather than to add preloads. The tool also states the reason self-hosting is worth considering: a third-party host adds a DNS lookup and a TLS handshake on the critical path, and the service's availability becomes part of the page's. When a third-party host is chosen anyway, the preconnect hints become mandatory rather than optional, and the generated head markup includes them.

The outputs are the two blocks a page actually needs. The head markup contains the preconnect for the file host, a comment naming how many of the total files are being preloaded, and one preload link per chosen file with the font type and the crossorigin attribute. The style block writes one declaration per weight, each with its own URL, weight and display policy, and adds a character range when the unicode-range split was chosen. A strategy table then restates the plan as decisions with their reasons, which is the part to keep when the numbers change.

What the tool cannot do is measure, and the plan is only as good as the figures entered.

The average file size is an estimate typed by hand, so the totals describe the assumption rather than the build.
The subsetting factors are typical reductions — roughly 35 per cent for latin, 55 for latin extended and 40 for a unicode-range split — rather than measurements of the project's own files.
Nothing checks that the paths in the generated markup exist, or that a preloaded file is the one the first screen actually uses.
The display policy is recorded as a decision with its trade-off rather than verified, so the result still has to be watched on a slow connection.
Layout shift is described rather than measured, since removing it depends on matching the fallback metrics in the declarations themselves.

How to use Font Loading Strategy Builder

Enter the families and weights the design really uses, since the file count is their product and is the first thing the verdict reacts to.
Enter an average file size from the project's own files rather than the default, so the totals describe this site.
Choose subsetting and the display policy, then read the verdict and the totals before and after subsetting.
Set how many files are preloaded — the above-the-fold ones only — and copy the head markup before the style block.

When to use Font Loading Strategy Builder vs related tools

Reach for it when a page has accumulated weights over several iterations and nobody has counted the files, when a product decision about a third-party font host has to be argued with numbers, or when subsetting is being considered and the size reduction needs an estimate before the work. The file count is the number to watch. For the declarations themselves the font-face generator writes them one at a time, the CSS variable font builder collapses several weights into one file, and the system font stack generator removes the requests entirely.

Privacy & Security

This tool runs entirely in your browser — no data ever leaves your device. There is no server round-trip, no upload, no logging, and no account required. Your input is processed locally using client-side JavaScript and is never stored, transmitted, or accessible to anyone else. When you close the tab, everything disappears.