天马行空的味道最近帮朋友优化一个公司官网，服务端响应正常、图片资源也不算大，但首屏就是肉眼可见地慢。打开 Network 面板盯了半天，发现一个特别隐蔽的问题：页面里第三方字体和图床 CDN 的连接，总是在脚本加载完之后才开始建立，关键资源请求硬生生等了一轮 RTT。后来我用 capo.js 给这个页面的 <head> 打了一下分，只得了 3 分，问题一目了然。
capo.js 是前端开发里目前少见的、专门针对 <head> 标签顺序做分析和评分的工具。它不帮你写代码，而是像一个“head 标签顺序裁判”，扫描你的 HTML 后输出一个 0 到 10 的分数，并把每个 head 子节点应该排在哪个位置、当前排在哪里全部列出来。如果你在做前端性能优化、页面首屏速度排查，或者准备前端面试时想聊点别人很少往深处理的细节，这工具值得花半小时彻底搞懂。
1. head 标签顺序，为什么能偷偷拖慢整站速度
1.1 浏览器解析 HTML 时，其实有第三把“扫描器”在抢跑
很多前端开发对 HTML 解析的理解停留在“自上而下，遇到标签就处理”这个层面，顶多知道 <script> 会阻塞解析、<link rel="stylesheet"> 会阻塞渲染。但这里少说了一个关键角色：浏览器在正式的 HTML 解析器之外，还会启动一个轻量级的预加载扫描器（preload scanner）。它不等主解析器执行完，就会提前扫一遍文档，把可能需要的资源 URL 先丢给网络进程去下载。
问题就在这里：预加载扫描器同样是从上往下扫的。如果 <link rel="preconnect"> 排在了 <script> 或者 <link rel="preload"> 的后面，扫描器先看到的是一堆需要发请求的资源和脚本，但它此时还不知道后面有个 preconnect 正在预热连接。于是这个第三方域的 TCP 连接、TLS 握手只能等浏览器真正解析到 preconnect 标签时才开始，前面那些对第三方域的资源请求全部卡在“连接建立”这一步上。
这相当于客人已经到店点完菜了，厨师才发现灶还没开。capo.js 把这些顺序问题量化成了分数和可读的排查报告。
1.2 越“没有副作用”的标签，越应该靠前
head 里的标签可以粗分成两类：一类是自己需要发起网络请求的，比如 preload、prefetch、script、stylesheet；另一类是无依赖、纯信息类的，比如 <meta charset>、<title>、meta description。后者虽然不产生网络请求，但它们决定了浏览器怎么解析整个文档。
<meta charset> 是这里最典型的例子。它如果出现在 head 的最开头，浏览器在解析第一个字节时就能确定文档编码，之后所有字符都能正确解码。这个标签往后挪，浏览器在编码不确定期间可能先用默认编码（比如 Windows-1252）做预解析，一旦后续发现真正的编码声明，整个文档就得重新解析一遍。你在性能面板里偶尔看到的 “Document re-parsed due to charset change” 就是这么来的，属于纯粹的无效开销。
<title> 和 description 这类标签同理，它们不阻塞任何资源，也不依赖任何外部文件，把它们放在最前面没有成本。既然没有成本，又能在最早期把页面标题、描述信息确定下来，那就应该放前面。capo.js 的优先级排序里，这类“零副作用”标签基本都在最顶层。
1.3 预连接和资源声明是“先后关系”，不是“并列关系”
preconnect、dns-prefetch、preload、prefetch、modulepreload 这些标签，都是为了让浏览器“提前做事”。但提事前也得有个顺序：
dns-prefetch只做 DNS 查询，最轻量，作用集中在节省 DNS 解析时间。preconnect在 DNS 之上还建立 TCP 连接并完成 TLS 握手，比 dns-prefetch 更重、收益也更大。preload是提前下载某个具体资源，下载之前最好连接已经准备好。prefetch是空闲时间预取下一页可能用到的资源。
如果 preload 排在 preconnect 前面，等于先让浏览器去下载一个还没有热好连接的资源，预加载的效果大打折扣。capo.js 会把这种“半吊子预加载”标记出来，并且建议你调整位置。
这套逻辑用生活场景类比就是：先烧水、再放茶叶、再强调这壶茶是给哪个客人准备的。顺序反了，茶也没快，客人的体验还更差了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. capo.js 的评分机制：10 分制背后的优先级逻辑
2.1 每个 head 子节点都有一张“优先级等级表”
capo.js 会把 head 下的每个元素按标签类型、属性、位置计算出一个 rank 值，rank 的范围大致是 0 到 10，数字越小代表越应该靠前。以下是基于 capo 项目思路和实际使用整理出来的简化优先级参考，完整规则建议直接看源码：
| rank | 典型场景 | 为什么排在当前位次 |
|---|---|---|
| 0 | <meta charset> 且是 head 第一个子节点、位于 preconnect 之前的 <title>、preload、render-blocking script |
要么决定文档解析，要么需要尽早触发网络请求，越早发现收益越大 |
| 1-2 | 迟到的 <meta charset>、head 开头的空白文本/注释乱入、viewport 在较前位置 |
不致命，但有明显优化空间 |
| 3 | <title> 出现在 preconnect 之后 |
可接受，但 title 无副作用，理应先出现 |
| 4-5 | meta refresh、iframe、社交分享类 meta | 不参与关键渲染路径，放太前反而干扰主解析器 |
| 6-7 | dns-prefetch、modulepreload、非关键 preload | 需要连接但优先级低于工具链核心资源 |
| 8-9 | 字体资源 preload、stylesheet | 样式确实影响渲染，但通常应在关键脚本和基础信息之后 |
| 10 | meta description、favicon、keywords、author、generator、异步脚本 | 本质是补充信息，放最后不影响性能 |
这个表不是官方文档的完整复刻，具体实现细节可能存在版本差异，但它反映的核心思想是稳定的：先排“决定解析基础的”，再排“触发网络请求的”，最后排“纯粹补充信息的”。
2.2 分数是“顺序质量”的直接量化
capo.js 的分数逻辑大致是这样的：从 head 的第一个子元素开始检查，如果它本身就是一个 rank 较高的元素（比如 charset），后续标签又基本遵循优先级递减的规律，那么得分就接近 10；反过来，如果第一个节点就是 meta description 这种 rank 10 的信息类标签，后面的 title、preconnect、script 无论如何排序，整体分数都会被拉低。
你不需要背它的计分公式，也没必要纠结“为什么这次扣了 2 分不是 3 分”。实际用的时候，重点看两点：第一，总分是不是低于 8；第二，report 里有没有出现“xxx 应该排在 yyy 之前”这类建议。这两点比精确分数更直接。
2.3 一个典型低分 head 长什么样
假设某个页面的 head 是这样的：
html复制<head>
<script src="/js/app.js"></script>
<meta charset="utf-8">
<title>示例页面</title>
<link rel="stylesheet" href="/css/style.css">
<link rel="preconnect" href="https://fonts.example.com">
<meta name="description" content="这是一个示例">
</head>
capo.js 会把 <script> 标记为“出现了不该出现在 head 最前面的脚本”，把 <meta charset> 标记为“应该在更靠前的位置”，把 preconnect 标记为“在样式和脚本之后才声明连接预热，效果会打折扣”。整个 head 的实际解析路径是：先执行一个阻塞渲染的脚本，再回头确定编码，然后再加载样式，最后才发现原来还要和第三方字体域建立连接。这个顺序几乎把能踩的低效点全踩了一遍，评分大概率在 3 到 5 之间。
3. 三种实际用法：CLI 扫描、Node API、浏览器扩展
3.1 环境准备与安装
capo.js 是一个 npm 包，使用前需要本机有 Node.js 环境，建议 Node 18 以上。命令很简单：
bash复制npm install -D @zachleat/capo
如果不想装到项目里，也可以直接通过 npx 临时运行：
bash复制npx capo index.html
我第一次用的时候直接跑在构建产物上——也就是项目里 dist 目录下真正的 HTML 文件，而不是源码模板。因为很多模板引擎会在 head 里留模板变量、条件注释，直接分析模板会得到一堆误报，分析构建后的页面反而干净。
3.2 命令行扫描与 JSON 输出
CLI 最基础的用法是给一个 HTML 文件路径：
bash复制npx capo index.html
输出会直接展示 head 的分数和每个子节点的排序建议。如果你想在脚本里处理结果，加一个 JSON 输出参数：
bash复制npx capo --json index.html
输出结构大致长这样：
json复制{
"score": 8,
"report": [
{
"rank": 2,
"tagName": "meta",
"tag": "<meta charset=\"utf-8\">",
"description": "Meta charset should be the first child of the head element.",
"priority": 2
}
]
}
不同版本的字段名可能略有差异，用之前建议先跑一下 npx capo --help 看看当前版本支持哪些参数。我自己在多个项目里测下来，CLI 的定位就是“快速看一眼”，真正要落地到流程里还得用 Node API。
3.3 用 Node API 接入自定义规则和 CI
CLI 适合人肉跑，但如果你想让 capo 成为团队规范的一部分，比如 Git 提交前检查、CI 构建失败拦截，用 Node API 更合适。官方导出的入门函数大概是 getHeadRank。
js复制import { getHeadRank } from '@zachleat/capo';
const result = getHeadRank('./dist/index.html');
console.log(result.score);
console.log(result.report);
你也可以把 HTML 字符串直接传进去，适合在内存里处理动态生成的页面：
js复制import { getHeadRank } from '@zachleat/capo';
const html = `<!doctype html>
<html>
<head>...</head>
<body>...</body>
</html>`;
const result = getHeadRank(html);
拿到 score 之后，做一个阈值判断就可以接到 CI 里。比如我在一个 SSG 项目里写过这样一个 Node 脚本：
js复制import { getHeadRank } from '@zachleat/capo';
import { readFileSync } from 'node:fs';
import { globSync } from 'glob';
const files = globSync('dist/**/*.html');
const threshold = 8;
let failed = false;
for (const file of files) {
const html = readFileSync(file, 'utf-8');
const result = getHeadRank(html);
if (result.score < threshold) {
failed = true;
console.error(`FAIL: ${file} head score is ${result.score}`);
}
}
if (failed) {
process.exit(1);
}
这样做的价值是：把一次性的手工检查变成持续约束。尤其对于多人协作、模板公共 head 被反复改动的项目，没有自动化卡口，顺序很快会再次劣化。
3.4 浏览器扩展：直接在 DevTools 里看当前页
作者还提供了浏览器扩展方式，可以在 Chrome / Edge 的开发者工具里直接对当前页面做 head 分析。安装后打开任意页面，capo 面板会显示当前页面的 head 分数和具体每一条排序建议。这个适合在开发调试阶段实时看，省去来回切换命令行的麻烦。
不过要注意，浏览器扩展读到的“当前页面”是运行时 DOM 序列化后的结果。对于纯静态页面，这个结果和 CLI 扫描基本一致；但对于前端框架动态渲染的页面，扩展看到的 head 其实已经被 JS 改过了，可能和原始的 HTML 文件不完全一致。我建议把它定位成“辅助观察工具”，真要出报告、进 CI，还是以命令行和 Node API 为准。
4. 实例拆解：从 3 分到 9 分的 head 改造全过程
4.1 改造前的页面 head 与评分
拿我前面提到的那个官网举例，改造前的 head 是这样：
html复制<head>
<script src="/js/vendor.js"></script>
<meta charset="utf-8">
<title>官网首页</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="/css/main.css">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">
<link rel="icon" href="/favicon.ico">
<meta name="description" content="官方网站描述">
</head>
capo 跑完的评分只有 3 分。报告里最扎眼的三条是：
<script src="/js/vendor.js">出现在 head 第一个位置，它本身是渲染阻塞的，进一步推迟了后面所有资源被发现的时间；<meta charset="utf-8">被脚本挤到了第二位，没有达到“head 第一个子节点”的最佳状态；- 两个
preconnect排在了main.css之后。这意味着浏览器在加载样式时，还没有和 Google Fonts 建立连接，字体请求只能等样式加载完后才开始连接热身。
4.2 每一步为什么这么移动
改造的目标不是“背一个标准模板”，而是理解每个标签的最优位置，然后按逻辑重排。
首先，把 <meta charset="utf-8"> 放到 <script> 前面，而且必须是 head 的第一个子节点。这一步没有任何成本，却能避免文档重新解析。
然后，<title> 紧随其后。title 不触发请求、不阻塞渲染，提前出现可以更早确定页面身份，在规范里也是最优先级的标签之一。
接下来是 <meta name="viewport">。虽然 viewport 主要影响移动端渲染，但它不产生网络请求，放在基础信息区没有问题。
再往后，把 <script> 从最前面挪到样式后面。同时如果业务允许，给它加 defer 属性，让脚本在文档解析完后执行，而不是阻塞解析。对于该项目的第三方库，这行调整本身就能显著降低首屏阻塞时间。
然后是 preconnect。它们必须排在真正使用该域资源的请求之前，也就是在 Google Fonts 的 CSS 之前。把两个 preconnect 从 main.css 后面挪到 fonts.googleapis.com 的样式表之前。
最后处理样式本身。<link rel="stylesheet" href="/css/main.css"> 和 Google Fonts 的 CSS 都属于样式资源，放一起、放 preconnect 之后即可。favicon 和 description 留在最后，它们根本不参与关键渲染路径。
改造后的 head：
html复制<head>
<meta charset="utf-8">
<title>官网首页</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="/css/main.css">
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">
<script defer src="/js/vendor.js"></script>
<link rel="icon" href="/favicon.ico">
<meta name="description" content="官方网站描述">
</head>
再次跑 capo，分数从 3 分变成 9 分。剩下 1 分不是因为它有问题，而是 capo 在非常严格的标准下认为某些社交分享 meta 可以继续优化。实际打开 Network 面板，字体链接从“样式加载完成后再建连”变成了“样式解析前连接已经预热完成”，最明显的体感是首屏白屏时间缩短。
4.3 如果遇到必须保留某些标签位置的场景
不是所有项目都能照搬“最佳顺序”。我在一个老项目里遇到过一个内联脚本，业务逻辑要求它必须在解析到某个位置时执行，不能加 defer，也不能后移。这时候 capo 的分数会明确告诉你“这里扣分了”，但这是业务约束造成的，不是工程失误。
遇到这种情况，我的建议是：在 CI 脚本里给这类页面一份单独的白名单，或者把阈值设成两档——普通页面必须过 8 分，含特殊脚本的页面只要求不低于 5 分。工具是用来辅助决策的，不是为了分数而分数。
5. 用 capo.js 的边界：它不管什么，以及跟其他工具怎么配合
5.1 capo 不会告诉你的事
capo.js 只关心 head 标签顺序，范围非常聚焦。它不会检查图片有没有转成 WebP/AVIF，不会评估缓存策略对不对，不会分析 JS 包体积，更不会管 body 内部的资源加载顺序。
我之前遇到一个项目，head 顺序优化到 10 分，但页面依然慢，原因是 body 里有几十张未压缩的大图，还有一段串行执行的第三方统计脚本。capo 对这些无能为力，这是合理的——它本身就不是一个全维度性能检查器，它只解决“head 顺序”这一个非常具体的问题。
所以使用场景要摆正：如果你的页面性能问题集中在“第三方资源连接建立慢”或“资源发现太晚”上，capo 是极好用的定位工具。如果是图片、缓存、接口速度问题，该上 Lighthouse 上 Lighthouse，该上 WebPageTest 上 WebPageTest。
5.2 和 Lighthouse 的分工
Lighthouse 是“全身体检”，跑一次能给你性能、可访问性、最佳实践、SEO 各维度打分，并且给出几十条建议。但正因为它覆盖面广，单项问题的诊断深度有限。比如它告诉你“消除阻塞渲染的资源”，却不会精确告诉你“这个 preconnect 应该排在那个 script 前面”。capo 恰好补上这一层“最后一公里”的深度。
我常用的组合是：先跑 Lighthouse 抓住整体方向，定位到性能短板后，打开 Network 面板看资源时序；如果时序里明显出现“连接建立晚”或者“资源发现晚”的问题，再用 capo 对 head 做精确分析。这样既不错过大方向，也不漏掉细节。
5.3 什么时候可以忽略 capo 的建议
明确一下哪些场景下不必严格执行 capo 的报告。
第一，第三方组件强制要求脚本位置。比如某些统计代码、客服插件，它们的接入文档明确要求放在 head 某一位置，并且不支持异步加载。这种属于外部约束，与其强行改造，不如在报告里标注“已知问题”。
第二，SPA 的动态 head。很多 Vue/React 项目会用框架的 SEO 插件在运行时往 head 里注入标签，这时候静态 HTML 文件里的 head 可能只是一个空壳，capo 对空壳的评分意义有限。处理方式是对“最终渲染后的 DOM”做快照检查，或者退回到运行时用浏览器扩展观察。
第三，capo 报告字段和版本细节会在不同版本间变化。我遇到过升级包之后，某个标签的 rank 从 8 变成 9 的情况。不要把一个版本的具体 rank 数字写死在团队文档里，更合理的做法是只约定“总分不低于多少”，让工具自己管理内部细节。
5.4 一个值得顺手做的落地方式
最后分享一个我后来沿用到多个项目的做法：把 capo 集成到本地 Git 钩子里，在 commit 前自动扫描公共 head 模板对应的构建产物路径。这样每个前端开发提交代码时，本地就能看到 head 分数变化，不需要等 CI 跑完一轮才发现问题。
我在实际使用中的体会是，head 顺序优化往往不会瞬间带来“从红色到绿色”的戏剧性变化，但它在高延迟网络和第三方依赖较多的场景下，收益非常稳定。它就是那块你平时看不见、但关键时刻确实会拖后腿的短板。capo 不复杂，复杂度在于养成“每次写完页面都顺手跑一遍 head 检查”的习惯。这习惯一旦建立，后续排查性能问题会省下很多时间。