HTML 属性顺序和书写规范对性能有影响吗？

结论：HTML 属性顺序对页面运行时性能（解析、布局、渲染、Core Web Vitals）没有可测量的影响，真正影响性能的是「写了哪些属性」而不是「属性排在前面还是后面」。属性顺序只在一个很窄的场景里有价值——gzip/brotli 压缩率和代码可维护性。

HTML 属性顺序会影响浏览器解析速度吗？

不会。HTML 解析器是单遍流式扫描，遇到标签名后按出现顺序读取属性并写入一个属性映射（attribute map），顺序不影响查找方式，也不影响后续的 DOM 构建和 CSSOM 匹配。

结论：把 class 写在 id 前面或反过来，对 FCP、LCP、INP 这些指标的影响是 0。浏览器不会因为属性乱序而多走一遍解析流程。

同理，这些写法差异也都不影响性能：单引号和双引号、属性值加不加引号、属性之间多敲一个空格、标签名和属性名大写还是小写（HTML 里 CLASS 和 class 等价）。它们只影响文件字节数和你团队的代码风格。

属性顺序在什么情况下真的有用？

唯一有实际收益的场景是文本压缩。gzip 和 brotli 都用滑动窗口做重复串匹配，相似的字符串挨得越近，压缩率越高。属性顺序统一后，同类标签的字节序列更规整，压缩器更容易命中重复模式。

结论：对同一份 HTML 打乱属性顺序再重排，gzip 后的体积差异通常在 0.1% 以内；页面上重复标签越多（比如几百个 <li> 或 <tr>），差异才会稍微明显一些。这个量级远小于你删掉一个未使用的图标字体的收益。

如果你确实想榨这一点收益，不用手工排，直接用 html-minifier-terser 的两个选项：

npx html-minifier-terser --sort-attributes --sort-class-name -o out.html in.html

sortAttributes 会把每个标签的属性按字母序重排，sortClassName 会把 class 里的类名按字母序重排，两者都是为了让相同字符串更容易被压缩。这是工具层面的确定性收益，比人工约定「class 必须写在 id 前面」靠谱得多。

class 名顺序会影响 CSS 优先级吗？

不会。CSS 优先级只跟选择器的类型和数量有关，跟类名在 class 属性里的书写顺序完全无关，class="a b" 和 class="b a" 在样式匹配上完全等价。

但有两个例外值得记住：

1. style 属性内部的声明顺序会生效。style="color:red;color:blue" 最终是蓝色，同一元素内后写的同优先级声明覆盖前面的。
2. 用属性选择器精确匹配字符串时，顺序会决定匹配成败。[class="btn primary"] 匹配的是字面字符串，把类名改成 class="primary btn" 就不匹配了。这种写法本身就脆弱，建议改用 .btn.primary。

另外补充一个容易被忽略的点：HTML 规范规定同一个标签里出现重复属性时，第一个生效，后面的被丢弃。所以 <input type="text" type="checkbox"> 解析出来是文本框。这跟顺序有关，但不是性能问题，是正确性问题。

哪些「顺序」是性能相关的？

真正跟顺序挂钩的性能点只有两处，而且都属于「标签顺序」而非「属性顺序」：

• 样式表顺序：多个 <link rel="stylesheet"> 之间，同优先级的规则后加载的覆盖先加载的，顺序错了会出样式 bug。
• 脚本顺序：不带 async/defer 的 <script> 严格按文档顺序同步执行，会阻塞解析；加了 defer 后仍按文档顺序执行，加了 async 则完全不保证顺序。这三个属性的存在与否，才是真正决定加载行为的东西。

真正能提升性能的属性是这些，跟顺序无关：图片加 width 和 height 防 CLS、首屏大图加 fetchpriority="high"、非首屏图片加 loading="lazy" 和 decoding="async"、脚本加 defer、资源加 <link rel="preload">。

团队该定什么样的 HTML 书写规范？

建议把规范目标定成「可读 + 压缩友好」，而不是「提升性能」，这样预期才不会跑偏。可落地的规则：

1. 属性顺序统一为：id → class → data-* → 功能属性（src/href/type）→ 布尔属性 → aria-*，靠 ESLint 插件或 Prettier 固化，不靠人记。
2. 属性值一律加双引号，全小写。
3. 布尔属性只写名字，写 disabled 而不是 disabled="true"；特别注意 disabled="false" 仍然是禁用，因为布尔属性的判断依据是「存在即真」。
4. 构建阶段跑一次 html-minifier-terser 做排序和压缩，压缩产物不进仓库。
5. 不要为了「性能」手工调属性顺序，把时间花在图片体积、字体子集化和减少 DOM 节点数上，这三项的收益比属性排序高 2 到 3 个数量级。

总结一句：属性顺序是代码风格问题，不是性能问题。它唯一能碰到性能的地方是压缩率，收益在 0.1% 量级；真要提速，去改图片格式、脚本加载策略和 DOM 规模。