<meta charset="utf-8">必须位于前1024字节内，否则浏览器先按Latin-1错解中文，触发重载导致闪动、乱码和脚本中断；前面仅允许<!DOCTYPE html>和空白符，禁用注释、BOM、空行或注入脚本。
浏览器渲染引擎解析 HTML 的效率，不取决于你写了多少语义化标签，而取决于它「少做了哪些事」——比如跳过重载、避免重排、省掉无效 token 匹配。关键不是“怎么解析”，而是“怎么让解析器不卡住”。
为什么 <meta charset="utf-8"> 必须在前 1024 字节内
浏览器启动 HTML 解析器时，默认按 Latin-1 编码读取开头数据。如果 <meta charset="utf-8"> 出现在第 1200 字节，它会先错解一部分中文或符号，再触发重载（reparse），造成闪动、乱码、甚至脚本执行中断。
- 必须紧贴
<head>开始，前面只允许<!DOCTYPE html>和空白符 - 禁止在它前面加注释、BOM（UTF-8 with BOM 是高频坑）、空行或广告 JS 注入
- 用
curl -s your-page.html | head -c 1024 | hexdump -C实际验证位置
<script> 放哪儿才不打断 DOM 构建
未加修饰的 <script src="app.js"> 一遇到就暂停 HTML 解析，等下载+执行完才继续。这不是 JS 慢，是解析流程被硬阻塞。
- 同步脚本：一律移到
</body>前，最简单兜底方案 - 业务逻辑脚本：优先用
defer——下载不阻塞，执行在 DOM 解析完成后、DOMContentLoaded前，且保持顺序 - 统计/埋点脚本：用
async，但确认它不依赖document.getElementById等 DOM 节点 - 绝对禁用
document.write()——现代浏览器执行即清空文档流，本地双击打开时直接白屏
深层嵌套 <div> 怎么拖慢解析速度
浏览器对 <header>、<nav>、<main> 等语义标签有内部解析捷径；而对同级的 <div class="header"> 需额外走 CSS 类匹配、JS 查询等通用路径。
立即学习“前端免费学习笔记（深入）”；
- 嵌套超过 6 层的
<div>容易触发重排压力，尤其在低端安卓设备上 - 服务端渲染时避免生成大量空
<div>或<div class="">——这些节点仍要进 DOM 树 -
<section>不等于<div>：<section>是独立可分发内容单元（如博客正文），浏览器对其有结构感知优化
DOM 操作中哪些写法会让解析器多干活
很多“看起来没问题”的操作，其实在强迫浏览器反复重建解析上下文。
- 慎用
innerHTML = '<div></div>'拼接长模板——V8 解析 HTML 字符串比用document.createElement创建元素慢 3–5 倍 - 图片占位别用
<img src="placeholder.jpg">再 JS 替换——改用loading="lazy"+ 合理的srcset+ 显式width/height - 避免在循环里频繁调用
document.querySelector——查一次缓存起来，别让解析器每次重跑选择器引擎
真正影响解析效率的，往往不是你写的 JS 多复杂，而是 HTML 文件开头那几百字节有没有让浏览器“一眼看懂”。一个没闭合的 <script>、一个错位的 charset、一层多余的 <div>，都可能让整个解析流水线卡顿半秒以上——而这半秒，在 LCP 指标里就是失败。
