浏览器解析HTML时最常卡在三处：未加defer/async的script标签、meta charset不在前1024字节内、内联JS超1KB；这些会直接中断DOM构建，导致首屏元素无法渲染。
浏览器解析 HTML 时卡在哪几个地方
浏览器不是等整个 HTML 下载完再开始干活，而是边下载边解析（流式解析），但只要遇到阻塞点，就会立刻停住。最常卡住的位置有三个：<script> 标签没加 defer 或 async、<meta charset> 不在前 1024 字节内、内联大段 JavaScript 超过 1KB。这些不是“慢”，是直接中断 DOM 构建，首屏元素哪怕写在第 2 行也渲染不出来。
<script> 放哪儿、加什么属性才不打断解析
默认行为就是阻塞：浏览器一碰到 <script src="a.js"></script>，立刻暂停 HTML 解析，去下载、编译、执行，完事才继续。修复方式不是“尽量少写”，而是明确控制加载时机：
- 非关键脚本（如埋点、广告）统一用
async：下载不阻塞，执行时机不可控，适合完全独立逻辑 - 依赖 DOM 的初始化脚本（如 Vue mount、表单校验）必须用
defer：下载不阻塞，DOM 解析完再按顺序执行 - 所有
<script>避免塞进<head>—— 除非是极小内联代码（比如设置window.__INIT__），且体积严格 ≤1KB - 绝对禁用
document.write()：现代浏览器执行即清空文档流，本地双击打开file://时尤其容易翻车
为什么 <meta charset> 位置错了会导致重解析
浏览器必须在收到前 1024 字节内确定编码，否则会先用 latin1 试解析一部分，发现乱码后再丢弃已构建的 DOM，重新用 UTF-8 下载并解析整页——这不是延迟，是白屏后闪一下再重来。实操中只需保证：
-
<meta charset="utf-8">是<head>中第一个标签（建议第 1 行） - 服务端响应头
Content-Type: text/html; charset=utf-8必须与 meta 一致，避免冲突 - 不要在它前面放任何注释、空行或 BOM 字符
DOM 结构扁平化对解析速度的真实影响
嵌套本身不耗 CPU，但每多一层 <div> 就多一次节点创建、样式匹配和布局计算。Android WebView 或低端设备上，6 层以上嵌套会让解析时间翻倍。这不是理论值，是 Chrome DevTools 的 “Elements” 面板里能直接数出来的层数：
立即学习“前端免费学习笔记（深入）”；
- 用
<header>、<nav>、<main>替代<div class="wrapper"><div class="inner"><div class="content"> - Flexbox/Grid 布局天然减少容器层，比如一个三栏布局，用
display: grid可省掉至少 2 层包裹 - SSR 模板里避免生成空
<div class="">或仅用于样式隔离的冗余节点——它们照进 DOM 树，照样算开销
真正卡解析的从来不是 HTML 文件大小，而是那些看似无害的标签位置、属性缺失和嵌套惯性。改完 <script> 和 <meta charset> 两处，再压平三层以上 <div>，首屏解析时间通常能砍掉 30%～60%，而且不用动一行 JS 或 CSS。
