--- title: "What is Capo.js? Why HTML Head Tag Order Matters" description: "How HTML head tag ordering affects page load performance. Complete Capo.js weight reference, common mistakes, and how Unhead automates optimal ordering." canonical_url: "https://unhead.unjs.io/learn/guides/what-is-capo" last_updated: "2026-03-05" --- ## What is Capo.js? [Capo.js](https://github.com/nickvdh/capo.js) is a set of rules by [Rick Viscomi](https://rviscomi.dev/) (Chrome DevRel) defining the optimal order of HTML `` tags for page load performance. Named after the guitar capo - it tunes your `` by putting every tag in the right position. Browsers parse `` top-to-bottom. Wrong order means delayed rendering, unnecessary re-parsing, and slower LCP. **Unhead implements Capo.js sorting automatically.** Every tag from `useHead()` is placed in optimal position - zero config. ## Why order matters The HTML parser processes `` sequentially: - `` **after the title** → browser re-parses the document when it discovers a different encoding - **Sync** ` ``` Problems: charset after title triggers re-parse, sync script blocks CSS, preconnect comes after the stylesheet that needs it. With Capo.js ordering: ```html My Page ``` ## Complete Weight Reference Unhead implements all 14 Capo.js weight levels. Lower weight = placed first in ``:
Priority Weight Tag Why
1 -30 < meta http-equiv = " Content-Security-Policy " > The Preload Scanner Stall: Must be first. Late CSP tags can disable the Chromium preload scanner , forcing resources to load sequentially.
2 -20 < meta charset > Encoding must be in first 1024 bytes
3 -15 < meta name = " viewport " > Prevents mobile layout shifts
4 -10 < base > Affects all relative URLs after it
5 10 < title > First visible content in browser tab
6 20 < link rel = " preconnect " > Early DNS + TLS for critical origins
7 30 < script async > Fetch ASAP, non-blocking
8 40 < style > with @import Render-blocking; must discover imports early
9 50 < script src > (sync) Render-blocking but unavoidable
10 60 < link rel = " stylesheet " > / < style > Render-blocking CSS
11 70 < link rel = " preload " > / < link rel = " modulepreload " > Hints for soon-needed resources
12 80 < script defer > / < script type = " module " > Non-blocking, post-parse execution
13 90 < link rel = " prefetch " > / < link rel = " dns-prefetch " > Low-priority future navigation hints
14 100 Everything else < meta name = " description " > , OG tags, JSON-LD
### Weight groups **-30 to -10 (critical metadata)** must appear first - `` after 1024 bytes forces re-parsing, late viewport causes mobile layout shifts. **10-20 (content & connections):** `` for the browser tab, `<link rel="preconnect">` to establish connections before they're needed. **30-60 (render-blocking resources):** `<script async>` gets discovered early for fetching. Sync `<script>` and `<link rel="stylesheet">` in their optimal relative order. **70-100 (deferred & hints):** `<link rel="preload">`, `<script defer>`, `<link rel="prefetch">`, and everything else. These don't affect initial rendering. ## Common Mistakes ### The "Head-Breaker" A common mistake is placing an invalid tag (like `<img>` or `<iframe>`) inside the `<head>`. The browser's DOM builder implicitly closes the `<head>` and moves everything after the invalid tag to the `<body>`. <chart-head-breaker-impact> </chart-head-breaker-impact> According to the **Web Almanac 2025**, invalid head markup remains a significant issue for **22% of all mobile pages**. This "breaks" SEO and performance because the parser discovers critical meta tags and styles too late. ### Charset after the title ```html <!-- Bad --> <title>My Page My Page ``` The [HTML spec](https://html.spec.whatwg.org/multipage/semantics.html#charset) requires `` within the first 1024 bytes. Content before it may trigger re-parsing. ### CSS before preconnects ```html ``` ### Sync scripts blocking CSS ```html ``` Better - make analytics async: ```html ``` ### Preloads after what they preload ```html ``` ## Automatic Sorting with Unhead Every `useHead()` call produces Capo.js-ordered output: ```ts import { useHead } from 'unhead' useHead({ meta: [ { charset: 'utf-8' }, // weight: -20 { name: 'viewport', content: 'width=device-width' }, // weight: -15 { name: 'description', content: 'My page' }, // weight: 100 ], title: 'My Page', // weight: 10 link: [ { rel: 'preconnect', href: 'https://fonts.googleapis.com' }, // weight: 20 { rel: 'stylesheet', href: '/style.css' }, // weight: 60 ], }) ``` Unhead sorts the output by weight regardless of input order. ### Custom priority Override the default ordering with `tagPriority`: ```ts useHead({ script: [ { src: '/critical-polyfill.js', tagPriority: 'critical', // -8 offset (higher priority) }, { src: '/analytics.js', tagPriority: 'low', // +2 offset (lower priority) }, ], }) ``` Priority aliases (applied as offsets to the tag's calculated weight): - `'critical'` - subtracts 8 from weight - `'high'` - subtracts 1 - `'low'` - adds 2 - Any number - exact weight override Relative positioning with `before:` and `after:` prefixes: ```ts useHead({ script: [ { src: '/my-script.js', tagPriority: 'before:script:analytics', }, ], }) ``` ## Check Your Site Paste HTML or enter a URL to get instant feedback on your head tag ordering, with specific suggestions for improvement. For the measured performance impact of head tag ordering, including the **"Nuxt Paradox"** where automatic ordering isn't enough to fix slow LCP, see [Does Head Tag Order Affect Performance?](/learn/research/capo-performance-research). For how streaming SSR interacts with head management, see [Streaming SSR SEO](/learn/research/streaming-head-performance).