33 patterns in this category — each with its illustration, what it is, and the fields that matter when you build or review one. Part of the UX pattern catalogue; the raw, agent-readable version is ux-pattern-catalogue/head-order-patterns.json.
The <meta charset="utf-8"> tag must appear as early as possible in the <head> — ideally as the very first element. The HTML specification requires that the character encoding declaration appear within the first 1024 bytes of the document. If the browser encounters content before knowing the encoding, it may speculatively parse with the wrong encoding and then re-parse the entire document when it discovers the charset, wasting time and causing visual flashes.
The <meta name="viewport" content="width=device-width, initial-scale=1"> tag tells the browser how to scale and size the viewport on mobile devices. Without it, mobile browsers render at a desktop width (typically 980px) and then shrink everything down. This must appear very early in the <head> because layout calculations depend on knowing the viewport dimensions.
The <meta http-equiv="content-security-policy"> tag defines which resources the browser is allowed to load. This is a critical security pragma that MUST appear before any <script> or <link> tag in the <head>. If CSP appears after a script element, the browser's preload scanner may have already started fetching resources that CSP would block, causing wasted connections and potential security gaps.
The <base href="..."> tag sets the base URL for all relative URLs in the document. Because every subsequent <link>, <script>, <a>, and <img> with a relative URL resolves against the base, it must appear before any element that uses a relative URL. Placing it late means earlier elements may resolve to the wrong URL, causing failed resource loads and broken links.
Additional <meta http-equiv> directives that control browser behavior before parsing begins. Includes: accept-ch (Client Hints), delegate-ch (delegated Client Hints), x-dns-prefetch-control (enable/disable DNS prefetching), default-style (preferred stylesheet), origin-trial (enable experimental features), and content-type (legacy charset declaration). All are pragma directives that must be discovered before resources they affect.
The <title> element should appear immediately after pragma directives (capo.js weight 9). The browser needs the title early to populate the tab/window title bar. More importantly, the title must appear after <meta charset> to ensure correct character rendering — a title decoded with the wrong charset may display garbled text. ct.css flags the title as an error if it appears after synchronous JavaScript.
The <link rel="preconnect" href="https://..."> hint tells the browser to start DNS resolution, TCP handshake, and TLS negotiation with a third-party origin before any resource from that origin is needed. Placed at weight 8 by capo.js — after pragma directives and title, but before any scripts or stylesheets. Preconnects are most valuable for origins that will be needed for render-blocking resources (fonts, CSS CDNs, critical API endpoints).
Scripts with the async attribute (<script async src="...">) should appear high in the <head> (capo.js weight 7). Despite being non-blocking, they still need to be discovered early by the browser's preload scanner to begin downloading as soon as possible. The key insight from Harry Roberts: use static <script async> markup instead of JavaScript-injected async snippets — the preload scanner cannot see scripts created by JavaScript.
The most counterintuitive rule in head ordering: synchronous scripts (weight 5) should appear BEFORE synchronous stylesheets (weight 4) in the <head>. The reason: CSS blocks JavaScript execution. When the browser encounters a synchronous <script> after a <link rel="stylesheet">, it must wait for the CSS to fully download and parse before executing the script — and it cannot parse any HTML after the script during that wait. Placing the script first allows the preload scanner to discover and begin downloading the stylesheet while the script downloads and executes.
Synchronous stylesheets — <link rel="stylesheet"> and <style> tags — are render-blocking by design: the browser will not paint anything until all synchronous CSS is downloaded and parsed. Placed at weight 4 by capo.js. Despite being critical for rendering, they come after synchronous scripts to enable parallel resource discovery via the preload scanner. Inline <style> blocks are treated identically to external stylesheets for ordering purposes.
Inlining critical above-the-fold CSS directly in a <style> tag eliminates the network round trip for the most important styles. The browser can start rendering immediately after parsing the inline styles without waiting for an external file. Harry Roberts' csswizardry.com bundles its entire main CSS inline. This is the fastest possible way to deliver render-blocking CSS — zero network latency for styles.
The <link rel="preload"> hint tells the browser to fetch a resource that will be needed soon for the current page, even before the parser naturally discovers it. Placed at weight 3 by capo.js — after all render-blocking resources but before deferred scripts. Common preload targets: fonts, hero images, critical JSON/data files, and above-the-fold images. Preload is for resources needed NOW, not for future navigations.
The <link rel="modulepreload"> hint preloads ES module scripts and their dependency graph. Unlike regular preload, modulepreload also compiles and caches the module, not just downloads it. Placed alongside regular preloads (weight 3) by capo.js. Essential for applications using ES modules, as the browser would otherwise discover and fetch module dependencies one by one in a waterfall pattern.
Scripts with the defer attribute (<script defer src="...">) and module scripts (<script type="module" src="...">) download in parallel without blocking the parser, and execute in document order after HTML parsing is complete. capo.js assigns weight 2 — they are needed for the current page but are not time-critical for rendering. Module scripts are defer by default unless they also have async.
The <link rel="dns-prefetch" href="https://..."> hint performs DNS resolution only (no TCP or TLS) for a third-party origin. Cheaper than preconnect and appropriate for origins that are likely but not certain to be needed. capo.js assigns weight 1 (prefetch tier) — these are speculative hints for the current page and should not compete with critical resources.
The <link rel="prefetch" href="..."> hint fetches a resource that will be needed for a future navigation, not the current page. The browser downloads it at idle priority, only using leftover bandwidth. capo.js assigns weight 1 — the lowest actionable weight. Prefetched resources are stored in the HTTP cache and used instantly when the user navigates to the next page.
The <script type="speculationrules"> element is the modern replacement for <link rel="prerender">. Use a 4-tier layered approach: (1) Immediate prerender for high-confidence targets (top nav, CTAs) via data-prefetch="prerender", (2) Immediate prefetch for likely navigations via data-prefetch, (3) On-demand prerender that upgrades prefetched links on hover (eagerness: moderate), (4) Fallback prefetch for all internal links on hover. This cascading strategy gives near-instant transitions for probable targets while keeping resource usage proportional to navigation probability. Supported in Chrome 109+ and Edge; ignored by other browsers.
ANTI-PATTERN: Placing synchronous scripts AFTER stylesheets. When the browser encounters a <script> after a <link rel="stylesheet">, it halts script execution until the stylesheet is fully downloaded and parsed (CSSOM construction). The browser does this defensively — the script might call getComputedStyle() — but most scripts don't need CSSOM. This ordering serializes downloads that could be parallel, potentially doubling load time.
ANTI-PATTERN: Placing <meta charset> anywhere other than the very first element in <head>. The HTML specification requires the encoding declaration within the first 1024 bytes. If the browser has already started parsing content before discovering the charset, it must throw away all work and re-parse from the beginning with the correct encoding. This is an invisible but costly mistake.
ANTI-PATTERN: Placing a <meta http-equiv="content-security-policy"> tag after any <script> element. When CSP appears mid-<head> after scripts, the preload scanner may have already initiated fetches that CSP would block. Those fetches are wasted (aborted when CSP is applied). Worse, some browsers may partially disable the preload scanner for content that appeared before the CSP directive, losing parallelism entirely.
ANTI-PATTERN: Using @import rules in stylesheets instead of <link> tags. @import creates a hidden waterfall: the browser must download and parse the first stylesheet before it can discover the @import URL, then download the imported stylesheet serially. With <link> tags, the preload scanner discovers all stylesheets immediately and downloads them in parallel. capo.js assigns @import styles a higher weight (6) to flag them for early placement, but the real fix is eliminating @import entirely.
ANTI-PATTERN: Using a JavaScript snippet to dynamically create and inject an async script, instead of using a static <script async src="..."> tag. The classic pattern (used by Google Analytics pre-gtag) creates a <script> element via JS and appends it to the DOM. The problem: the preload scanner only reads HTML markup — it cannot execute JavaScript. So the injected script URL is completely invisible until the parent script runs, which may be blocked by CSS.
ANTI-PATTERN: Adding both async and defer attributes to the same <script> element. While browsers handle this gracefully (async takes precedence; defer acts as a fallback for browsers that support defer but not async), it signals confusion about the developer's intent. In modern browsers (all browsers since IE10), the defer attribute is completely ignored when async is present. It adds bytes without benefit.
ANTI-PATTERN: Using document.write() to inject scripts or stylesheets into the <head>. document.write() is the nuclear option against performance: it forces the HTML parser to stop, inserts raw HTML into the parse stream, and in many cases completely defeats the preload scanner. Chrome actively intervenes against document.write() on slow connections (2G) by blocking the injected resource entirely.
The <link rel="canonical" href="..."> tag tells search engines which URL is the authoritative version of the page. It has zero rendering or loading impact — search engines process it after the page loads. Placed at weight 0 ("everything else") by capo.js. There is no performance reason to place canonical early in the <head>; it should not displace any rendering-critical resource.
Open Graph <meta property="og:..."> tags control how the page appears when shared on social media platforms (Facebook, LinkedIn, Twitter/X, Slack, Discord, etc.). They have absolutely no impact on page rendering, loading, or performance. capo.js weight 0 — "everything else." Place at the bottom of <head> where they belong, and never let them displace render-critical resources.
The <meta name="description" content="..."> tag provides a summary of the page for search engine result pages (SERPs). Like all SEO meta tags, it has zero impact on rendering or performance and belongs at the bottom of <head>. Search engines may use it as the SERP snippet text, but modern search engines increasingly generate their own snippets from page content.
Favicon and app icon declarations (<link rel="icon">, <link rel="apple-touch-icon">, <link rel="manifest">) should be placed at the bottom of the <head>. Browsers fetch the favicon at low priority and only display it in the tab after the page starts rendering. These resources should never displace render-critical elements. capo.js weight 0 — "everything else."
<link rel="alternate"> tags for RSS/Atom feeds, language alternates (hreflang), and canonical format alternates. These are metadata for feed readers, search engines, and internationalization — they have no impact on page rendering. Browsers show an RSS icon for discoverable feeds, but this happens after page rendering is complete. Place at the bottom of <head> with other non-rendering metadata.
capo.js by Rick Viscomi is the definitive tool for auditing HTML <head> element ordering. Available as a Chrome extension, bookmarklet, or npm package. It color-codes every element in your <head> by its weight (10 = red/highest priority, 0 = grey/lowest), logs the actual order and optimal order to the console, and highlights high-impact elements that are out of order. Inspired by Harry Roberts' ct.css and Vitaly Friedman's research.
ct.css by Harry Roberts (CSS Wizardry) is a diagnostic CSS snippet that visually highlights performance issues in your <head>. Named after CT scans, it uses CSS-only selectors to detect anti-patterns: late charset, CSS blocking JS, redundant attributes, third-party resources in <head>, and more. Issues are highlighted with colored borders that disappear as you fix them. Available as a bookmarklet at csswizardry.com/ct/.
Several frameworks now have plugins that automatically enforce optimal <head> ordering at build time, using the capo.js weight system. astro-capo sorts Astro's <head> output automatically. nuxt-capo does the same for Nuxt 3. Unhead (the universal <head> manager used by Nuxt, Vue, and others) has built-in capo.js sorting. These tools eliminate head ordering mistakes by making correct ordering the default.
Harry Roberts uses the Performance API (performance.mark() and performance.measure()) directly in the <head> to measure how long each section takes to parse and load. His csswizardry.com <head> includes marks for HEAD_Start, CSS_Start, CSS_End, and HEAD_End, giving precise measurements of <head> parsing time. This technique allows you to quantify the impact of head ordering changes.