Learn how to preload fonts with the right link tag, crossorigin setting and format choices, so your web fonts load sooner without wasting bandwidth today.
A custom typeface can make a site feel polished. It can also cause a flash of unstyled text, a late layout shift, or a suspiciously blank heading while the browser waits for a font file. Knowing how to preload fonts helps you prioritise the files needed for above-the-fold content, rather than leaving the browser to find them halfway through parsing your CSS.
The key word is prioritise. Font preloading is useful, but it is not a performance glitter cannon. Preload too much and you can delay images, CSS, JavaScript, or the actual content your visitor came for. Nobody has ever celebrated a fast font on a page that forgot to load its hero image.
A preload hint tells the browser: “You will need this resource soon. Start fetching it now.” For fonts, that means adding a “ element in the document “ before the browser discovers the same file through `@font-face` in your stylesheet.
Without preloading, the browser usually follows a chain like this: download HTML, discover CSS, download CSS, parse CSS, find `@font-face`, then request the font. That is sensible, but it can be late for a font used in the first visible screen of the page.
With a preload hint, the font request can begin while the stylesheet is still being processed. The browser still needs the matching `@font-face` rule to use the font. Preloading fetches the file early; it does not magically apply typography to the page.
For a self-hosted WOFF2 font, place this in the “ of your HTML:
“`html “`
Each attribute earns its place. `rel=”preload”` creates the high-priority fetch. `as=”font”` tells the browser what kind of resource it is, helping it apply the right priority and request settings. `type=”font/woff2″` lets supporting browsers handle the resource efficiently. `crossorigin` is the bit people often omit, then wonder why they see two font requests in DevTools.
Even when the font is served from your own domain, font requests are generally made using CORS mode. The preload request must match the request made by `@font-face`. Adding the empty `crossorigin` attribute uses anonymous CORS, which is normally what you want.
Your CSS then needs to reference the exact same file:
“`css @font-face { font-family: “Inter”; src: url(“/fonts/inter-roman-latin.woff2”) format(“woff2”); font-style: normal; font-weight: 100 900; font-display: swap; } “`
The URL matters more than it looks. `/fonts/inter.woff2` and `/fonts/inter.woff2?v=1` may be treated as separate resources. If the preload URL and the CSS URL differ, you risk downloading the font twice. That is less “performance optimisation” and more “paying for the same sandwich twice”.
WOFF2 is the modern default for web fonts. It is well supported and typically smaller than older formats. If you only support modern browsers, preload WOFF2 and keep your setup simple.
Older fallback formats may still exist in a legacy codebase, but avoid preloading every format listed in `src`. The browser only needs one. Preloading WOFF2 while allowing CSS to choose WOFF or TTF elsewhere can create duplicate downloads and defeat the point.
Preload fonts used immediately in the initial viewport: perhaps the primary body font, the main heading font, or one variable font file that covers both. Start small. For many sites, one or two font preloads are enough.
A font used only in a footer, a modal, a code sample, or a page section far below the fold does not need an urgent network request. Let normal CSS discovery handle it. Likewise, an italic face or bold weight should not be preloaded merely because it exists in your design system.
Think in terms of what a real visitor sees first. If your homepage opens with a large display heading in a branded font and body copy in a system font, preload the display face only if it is central to the visual experience. If your page is text-heavy and uses one font throughout, preloading the Latin subset for the normal style may be worthwhile.
Variable fonts can simplify this decision. One variable font may cover a range of weights, reducing the number of files you need to request. But a variable file is not automatically smaller than every collection of static files. Check the actual transfer sizes for the weights and character sets you use.
Preloading controls when the request starts. `font-display` controls what the visitor sees while that request is in progress. They solve related problems, not the same problem.
For most content sites, `font-display: swap` is a practical default. It lets text render quickly using a fallback font, then swaps to the web font when ready. The trade-off is potential layout shift if your fallback metrics differ sharply from the final typeface.
`font-display: optional` can be a good choice when speed matters more than perfect typographic consistency. On a slow connection, the browser may keep the fallback font rather than spending precious bandwidth on a late font. That can be the right call for an article site, especially when readable content matters more than a very particular lowercase “g”.
You can also reduce layout movement with font metric overrides such as `size-adjust`, `ascent-override`, `descent-override`, and `line-gap-override`. These let you tune the fallback font so it occupies similar space to the custom one. It is a more advanced step, but it can make `swap` feel far less jumpy.
A font file can contain far more glyphs than a page needs. Latin, Cyrillic, Greek, Vietnamese, symbols, and other scripts may be split into subsets. If your audience primarily reads English, preloading a Latin subset rather than a full multi-script file can save a meaningful amount of data.
The CSS often uses `unicode-range` to describe which file covers which characters. For example, a Latin font face might be limited to a defined range while another file handles extended characters. Your preload should point to the subset most likely needed for the first render.
Be careful with assumptions here. An English-language site can still have names, code examples, or user-generated content containing characters outside a basic Latin range. The goal is not to remove support. It is to avoid making every first visit download every possible glyph.
The most common mistake is preloading every weight and style. A family with regular, medium, semibold, bold, italic, bold italic, and several language subsets can easily create a wall of high-priority requests. The browser has limited attention, just like the rest of us before coffee.
Another is omitting `crossorigin`, which can lead to a second request for the same file. A third is preloading a font that CSS never uses on that page. This often happens when a global HTML template contains preload hints for a component font used on only one route.
Also watch for preload warnings in browser DevTools. A warning that a preloaded resource was not used shortly after the page load does not always mean disaster, but it is a useful prompt. Ask whether that resource genuinely belongs in the critical path.
Finally, do not use font preloading to compensate for a bloated font strategy. If you are shipping several megabytes of typefaces, the answer is probably fewer files, better subsetting, or a system-font fallback – not more eager requests.
Open the Network panel in browser DevTools, reload with the cache disabled, and filter by Font. A properly configured preloaded font should start early and should appear only once. Check its initiator as well: you want the preload and CSS usage to resolve to the same cached resource, not competing downloads.
Then test on a throttled connection. Fast local broadband hides bad decisions beautifully. On a slower mobile profile, look at when meaningful text appears and whether swapping causes noticeable movement. Performance is about the visitor’s experience, not winning a tidy-looking waterfall chart.
Measure before and after using your usual performance tooling, paying particular attention to Largest Contentful Paint and Cumulative Layout Shift when the main heading is involved. If preloading improves neither and adds network pressure, remove it. A preload hint is optional, not a badge of honour.
The best font preload is the one your first-screen content actually needs. Start with one file, make sure the request matches your CSS exactly, and let the results decide whether a second one has earned its place.