A report page uses a custom heading font declared inside an external stylesheet. The browser normally has to download and read that stylesheet before finding the font URL. A targeted font preload can expose that same URL earlier. It helps only if the page actually needs the font; preloading every font weight can compete with the report's other downloads.
Match the preload to the resource that consumes it
This original example assumes the page and assets are served over HTTP or HTTPS, with the font available at the shown path:
<link rel="preload"
href="/assets/report-heading.woff2"
as="font"
type="font/woff2"
crossorigin>
<link rel="stylesheet" href="/assets/report.css">
The stylesheet still defines and uses the font:
@font-face {
font-family: ReportHeading;
src: url('/assets/report-heading.woff2') format('woff2');
font-weight: 600;
font-display: swap;
}
h1 { font-family: ReportHeading, sans-serif; font-weight: 600; }
The preload's URL and the CSS URL refer to the same file. The anonymous CORS mode selected by the empty crossorigin attribute matches font fetching, including a font on the page's own origin. A cross-origin font server must also allow the request through its CORS response headers. Font preload requirements
as="font" identifies the destination. type="font/woff2" identifies the format so a browser can skip an unsupported resource. Neither value creates an @font-face rule or selects the font for a heading.
Choose the file that the page really uses
A hero illustration has AVIF, WebP, and JPEG alternatives. Preloading all three starts work for files that a single visit will not need. Preload only a justified candidate and leave the actual image selection intact. For a responsive image, the preload also needs to agree with the resource the image element selects; a desktop URL forced onto every phone can waste a download.
For a stylesheet already linked immediately next to the preload in the head, the browser may discover both at nearly the same time. Start by looking for a late-discovered resource, such as the font inside CSS, rather than adding a preload beside every existing link.
For JavaScript modules, use the module-specific loading mechanism instead of treating all scripts as interchangeable. Preloading a classic script does not execute it. The eventual script element still controls execution.
Check reuse before keeping the hint
In Chrome DevTools, open Network before reloading the actual HTTP page. Filter for report-heading.woff2, inspect its initiator, and check that the heading uses the intended font. Compare a fresh load with and without the hint under the same conditions. A warm cache or existing connection can hide the difference; do not treat one fast reload as proof of a lasting improvement.
If a font appears to load twice, compare the resolved URLs, request modes, credentials, and destinations. A small URL difference or missing CORS setting can prevent the later consumer from reusing the preload. A console warning about an unused preload calls for checking whether that resource is needed promptly on this route.
If the request is blocked by policy, an earlier request will still be blocked. The Content Security Policy guide explains that separate permission check. If the problem is choosing CORS request mode, see the crossorigin attribute.
Keep the hint when it advances a resource the report actually consumes. Remove it when the page no longer uses that font or the loading order no longer benefits from requesting it early.