What is the correct order of link tags in the head?

Forum Moderators: open

What is the correct order of link tags in the head?

What comes first, preload or stylesheet link tag?

deeper

6:03 pm on Jan 28, 2026 (gmt 0)

Hi,
I want to preload three selfhosted webfonts by using a link tag with rel="preload" in the head of my HTML-Code.
In the head there is already a link tag for my external stylesheet, rel="stylesheet".

What link tag should come first?

Mozilla website has an example regarding preload feature (with webfonts), where the stylesheet link tag comes after two preload link tags:

<head>
 <meta charset="utf-8" />
 <title>Web font example</title>

 <link
 rel="preload"
 href="fonts/cicle_fina-webfont.woff2"
 as="font"
 type="font/woff2"
 crossorigin />
 <link
 rel="preload"
 href="fonts/zantroke-webfont.woff2"
 as="font"
 type="font/woff2"
 crossorigin />

 <link href="style.css" rel="stylesheet" />
</head>

But all other examples I have found so far in the www prefer the stylesheet link tag first.

What is better or doesn't it matter?

Brett_Tabke

8:23 pm on Jan 28, 2026 (gmt 0)

Firefox is right. The css will attempt to load first. If it sees the preload first, it will start to preload that at same times as css.

css first is always just legacy issues cuz that was the way we did it...

lastly, always use "crossorigin". if you omit it, some browsers will download the font twice.

deeper

10:22 pm on Jan 28, 2026 (gmt 0)

Thanks.

Yes, crossorigin is needed, as well as type and as-attributes. The mozilla example covers them all.

The href uses relative urls, but usually I'm a fan of absolute ones, for example regarding links and images.
Are there any good reasons for relative urls connecting font files in link tags?

lucy24

11:58 pm on Jan 28, 2026 (gmt 0)

Careful. There are three types of links, and only two terms to describe them :(
a href = blahblah (relative)
a href = /blahblah (I call this form �site-absolute�, faute de mieux)
a href = https://example.com/blahblah (this too is an abolute link, only more so)

My own guideline is: if a group of files always comes in a package--say, a subdirectory with its own css and images--then it makes sense to use relative links, because that way nothing needs to change if one day you decide to relocate the whole package. But if you�re linking to something elsewhere on the site, then use site-absolute links beginning in /

And if you ever come across a link in the form
../../blahblah
. . . feel free to point and snicker.

deeper

10:56 am on Jan 29, 2026 (gmt 0)

I mean normal internal links (and article images) in HTML, leading to another page of the same website. Usually I reference them with "real" absolute urls, i.e. third example in your post.

Regarding the href reference of preload resources in link tags I remember vaguely having read about a certain reason, why relative paths are better. But I'm not sure.

not2easy

3:28 pm on Jan 29, 2026 (gmt 0)

You could avoid all that in the <head> by adding a few lines to your CSS. I had to refresh my memory and look it up, but the suggestions at w3schools: [w3schools.com...] make it simple.
In your CSS file add the name and location for your font:

 @font-face {
 font-family: myFont; /* set name */
 src: url(/fonts/cicle_fina-webfont.woff2); /* url of the font */
}

The /* content */ is only instructions, it can be removed for the CSS file. There are also @font-face Descriptors to include for separate files within the font you are using. Some have bold or italic characters in separate files, the instruction at that link explain it all.

On page usage:

p {
 font-family: myFont; /* use font */
}

You can add multiple fonts as long as they have different names set in your CSS. I'd suggest using a descriptive name because it can be whatever you want to call it but a name like "ciclefina" in this case would make it simpler to manage your changes. Of course this would mean lots of editing of the content. A good editing tool can find and replace it across all your pages; more fonts, more work.

Just suggesting it because of the self-hosting. You would not need to inflict the extra bandwidth on each page if the CSS loads them once.

deeper

3:55 pm on Jan 29, 2026 (gmt 0)

You could avoid all that in the <head> by adding a few lines to your CSS

Your CSS-code I have already in my stylesheet, but this is the regular code for self-hosting webfonts (font-face and connections to it from the elements with font-family).

preload is a different additional feature, isn't it? So far I know, the font-face ect. cannot avoid or substitute the preload-tag in the head.

not2easy

5:03 pm on Jan 29, 2026 (gmt 0)

If the @font-face is in your CSS file it does not need to have a 'preload' because the CSS has the local URL and preloads it. Having the preload tag on the page would instruct browsers to preload the font files for each new page.

For some visitors that may not matter, but there are still a LOT of people who just have to live with limited bandwidth. For some visitors they may be on a limited bandwidth plan, or just live where there is only so much bandwidth to go around. User experience still matters.

deeper

8:50 pm on Jan 29, 2026 (gmt 0)

If the @font-face is in your CSS file it does not need to have a 'preload' because the CSS has the local URL and preloads it.

What kind of preload do you mean, which is done just by having a stylesheet, are you sure this is the same "preload" as the preload link tag (which indeed needs to be used just for few resources because of bandwith)? I doubt this is the same preload effect.

You certainly know what the usual preload with link tag, like it is shown in the mozilla example of my first post, does and how it works.
Like Brett said, it has the effect of downloading the webfonts at the same time as the stylesheet. Without preload, the webfonts are discovered and loaded late, after the stylesheet has been parsed and loaded. Therefore webfonts are said to be ideal candidates for preloading.

Having a stylesheet is very usual. Therefore the preload link tag is superfluos, having the same kind of preload effect just because of having a regular external stylesheet?

I have read several articles about preloading webfonts and also having a stylesheet, but they did not mention this kind of similar preload by the stylesheet.
Could you explain in more detail, what stylesheet-"preload" do you mean?

not2easy

9:03 pm on Jan 29, 2026 (gmt 0)

I left a link above in case you want to read more.

There is no reason to add

 <link
 rel="preload"

if your CSS file is already loading the font/s. That is the purpose of the @font-face in the CSS. It is up to you to decide how to integrate custom fonts, there is more than one way to do that.

tangor

7:06 am on Jan 30, 2026 (gmt 0)

Rather than look for "which order to insert" look at "best practice for use". In the latter case the CSS file is the place for font declarations---and since it is always loaded the desired fonts will be as well. And most browsers will know to do it once per session and cache until expiry.

This assumes, of course, that all pages HAVE a CSS!

deeper

4:56 pm on Jan 30, 2026 (gmt 0)

Once again, just to be sure that there is no misunderstanding: I have already an external stylesheet and font-face in it. This is the standard way of implementing self-hosted webfonts and I do it this way, like most webmasters do and like it is recommended.

But I still don't see, where and why font face in a stylesheet should make the preload linktag superfluos, because it does the same.

The link to w3schools just gives general information about font face property.

The preload link tag let browser load webfonts before loading and parsing any stylesheet. Just font-face in a stylesheet does not.
Due to for example [web.dev...] which says:

Fonts defined with @font-face rules or background images defined in CSS files aren't discovered until the browser downloads and parses those CSS files. Preloading these resources ensures they are fetched before the CSS files have downloaded.

lucy24

5:54 pm on Jan 30, 2026 (gmt 0)

Preloading these resources ensures they are fetched before the CSS files have downloaded.

And ...? The only time this could make a visible difference is if the user is on an ultra-slow connection. Or the site itself has an absurdly slow server; we've all seen sites where the html obviously loaded up a moment before the styles. In the first case, that's exactly when it is least considerate to start with a massive preload. In the second case, preloading resources is the least of your problems.

In short: except in rare and special circumstances, this is a non-issue. Keep font declarations in the css where they belong.

deeper

10:50 am on Jan 31, 2026 (gmt 0)

So things are like i say, but in real life in 99,9% of all sites and users it doesn't make any difference?

Very weird that there are many articles and recommendations from serious sources recommending decent (not massive) preload especially for webfonts, in order to improve page loading time and avoiding FOIT, FOUT, CLS.
All the examples there showing for example FOIT and disappearing FOIT with preload...
All discussions about Core Web Vitals, FCP, LCP, CLS and Google Lighthouse warnings like "Ensure text remains visible during Webfont load" is 99,9% theory?