HTML link Table
| rel value | What it loads | Field note |
|---|---|---|
stylesheet | CSS file | Render-blocking in head - split and media-query what you can |
icon | Favicon | Sizes attribute picks among multiple icons |
canonical | The authoritative URL | Ends duplicate-content confusion for search engines |
preload | Fetch now, use later | as="font" / "script"; without as it downloads twice |
preconnect | Warm the connection | DNS+TCP+TLS handshake early - free speed for known third parties |
alternate | Feed or language variant | type="application/rss+xml" for feeds; hreflang for languages |
modulepreload | Pre-fetch an ES module | Parses too, not just downloads |
nofollow / noopener / noreferrer | Link security trio on a | noopener stops tab-nabbing on target=_blank |
The link element is the head's instruction sheet: it loads stylesheets and icons, declares which URL is authoritative, warms connections to third-party hosts, and pre-fetches what the next navigation will need - all without rendering anything itself. The table below is the working eight rel values, ordered by how often they earn their place.
Bottom line: the performance wins are ordered by effort. preconnect for every critical third-party origin (fonts CDN, API host) costs one line and saves full DNS+TCP+TLS handshakes. preload for the hero font - with the as attribute, without which browsers fetch it twice. Everything else (canonical, alternate, icon) is correctness rather than speed, and correctness rows are the ones audits check.
The honest part: link mistakes are silent by design. A preload without as downloads the resource twice (unknown type, then real fetch). A canonical pointing at a URL that redirects points at nothing. And rel values on link are a different vocabulary than the link-security trio on <a> elements (noopener/noreferrer) - same attribute name, different lists.
How to use
- Load what renders: stylesheet and icon first - the two rows every page has.
- Declare identity: canonical for the authoritative URL, alternate for feeds and language variants.
- Then optimize: preconnect known third-party origins, preload only the hero resource with its as type set correctly.
Frequently asked questions
What is the difference between preload and preconnect?
preconnect warms the connection to a host - DNS, TCP and TLS - without downloading anything; use it for origins you will request from soon (a fonts CDN, an API host). preload actually downloads a specific resource you will use on this page. They stack: preconnect the font host, then preload the hero font file itself with as="font" and crossorigin (fonts always need crossorigin, even same-origin - the number one preload mistake).
Why does my preloaded font download twice?
Almost always a missing or mismatched as attribute. preload without as downloads the file blind - the browser cannot match that anonymous request to the later font fetch, which uses CORS - so it fetches twice. as="font" plus crossorigin makes the preloaded response the one the stylesheet actually uses. The second cause is a mismatched crossorigin: preload without it, @font-face request with it - same double-fetch, different trigger.
What does rel=canonical actually do?
It tells search engines which URL is authoritative when the same content is reachable at several URLs (with and without trailing slash, with query parameters, printed in two sections). The canonical link on every duplicate points at the one true URL, consolidating ranking signals. Two rules: absolute URLs only (relative canonical is silently mishandled by some crawlers), and each page canonicals to ITSELF when there is no duplicate - self-canonical is the standard default.
What do noopener and noreferrer do on links?
Wrong table by one tag - those live on <a> elements, not link, and they matter: without them, a page opened via target="_blank" can manipulate the opener through window.opener (tab-nabbing). Modern browsers imply noopener for target="_blank" automatically, which retired most of the risk; noreferrer additionally strips the referrer header. Inside link elements, the security vocabulary is different - it is about what the LINKED-TO resource may do, set via the allow attribute pattern on iframes or Permissions-Policy.