浏览器流式解析HTML，遇同步script暂停DOM构建，导致白屏；CSS阻塞渲染但不阻塞DOM解析；内联关键CSS和preload可优化FCP；JS执行触发回流重绘，应避免强制同步布局。
浏览器拿到HTML后立刻开始解析DOM树
HTML解析不是等整个文件下载完才启动的，而是流式解析：边接收字节、边构建DOM节点。一旦遇到<script>标签（且没加async或defer），解析会立即暂停，等待JS下载、编译、执行完毕后再继续。这是造成白屏最常见的原因。
常见错误现象：DOMContentLoaded事件延迟触发、首屏内容长时间空白、Lighthouse提示“Render-blocking resources”。
- 关键判断点：检查
<script>是否在<head>中同步加载，尤其是未压缩的第三方SDK - 真实场景下，
document.write()会彻底中断并重置当前解析上下文，应完全避免 - 现代打包工具（如Vite、Webpack）默认生成
type="module"脚本，这类脚本天然具有defer语义，但需注意兼容性（IE不支持）
CSS解析不阻塞DOM构建，但会阻塞渲染树合成
CSS文件下载过程不影响HTML解析器推进，但浏览器不会绘制任何内容，直到所有已知的CSS规则（包括<link rel="stylesheet">和<style>内联块）都解析完成。这是因为渲染树（Render Tree）必须同时具备DOM节点和对应样式信息才能生成。
容易踩的坑：@import在CSS文件内部使用时，会触发额外的串行请求，比并行<link>慢得多；display: none元素仍参与样式计算，只是不进入渲染树。
立即学习“前端免费学习笔记（深入）”；
-
<link rel="preload" as="style" href="main.css">可提前发起CSS请求，但不改变解析时机 - 内联关键CSS（Critical CSS）能绕过网络请求，直接进入解析流程，对FCP指标提升明显
- 使用
media属性的<link>（如media="print"）在匹配前不会阻塞渲染
JavaScript执行可能动态修改DOM结构，触发回流与重绘
JS执行阶段不只是“跑代码”，它能调用document.createElement()、element.innerHTML = ...、getComputedStyle()等API，直接干预DOM树和样式树。一旦发生结构变更（如添加/删除节点、修改尺寸），浏览器必须重新计算布局（reflow）和重绘（repaint）。
性能敏感点：在循环中反复读写offsetHeight或scrollTop会强制同步触发布局计算，形成“强制同步布局”（Forced Synchronous Layout），严重拖慢帧率。
- 批量DOM操作优先用
DocumentFragment或innerHTML一次性插入，而非多次appendChild - 动画场景下，用
transform和opacity替代left/top或visibility，它们只触发合成（composite），不引发回流 -
requestIdleCallback()适合处理低优先级DOM更新，但注意其执行时机不可控，不能用于用户交互响应
AST解析仅发生在构建工具或服务端，不在浏览器运行时
浏览器本身不进行HTML AST解析——它用的是经过高度优化的C++ HTML parser（如Blink的HTMLTokenizer），输出的是内存中的DOM对象，不是抽象语法树。所谓“HTML AST”只存在于构建时工具链中，比如html-query的extract()函数、模板引擎预编译、或服务端渲染（SSR）框架的静态分析阶段。
混淆点常出现在前端工程化语境里：有人把“用PostHTML插件遍历AST”当成浏览器行为，其实那是在Node.js里跑的，产物是转换后的HTML字符串，浏览器收到的仍是普通HTML。
- 若你在调试中看到
parser.rs或nom，说明你正看的是Rust写的命令行工具（如html-query-extractor），和浏览器无关 - 服务端React SSR（如Next.js）的
ReactDOMServer.renderToString()内部确实有类似AST遍历逻辑，但那是React reconciler的工作，不是浏览器原生能力 - 想验证某段HTML如何被浏览器解析？用Chrome DevTools的
Elements面板看实时DOM树，比任何AST可视化都准确
load事件，但却是DOMContentLoaded触发的必要条件之一。很多优化只盯着JS，却让一个200KB的main.css卡住整页渲染。 
