一、 前言最近在做前端性能优化的时候我发现自己陷入了一个怪圈遇到页面卡顿就去百度搜“优化技巧”然后机械地把transform替换掉left或者给 JS 加上defer。但每当别人问我一句“为什么这样会快”的时候我就只能支支吾吾地说“因为……大家都这么说。”这种知其然不知其所以然的感觉太难受了。于是这两天我沉下心去啃了一下浏览器渲染原理的相关资料。不看不知道一看吓一跳原来我们写的一行简单代码在浏览器的“黑盒”里竟然经历了一场如此精密的流水线作业。今天我就想把这些枯燥的底层原理用我自己的理解掰开了揉碎了分享给大家。二、 浏览器其实是个精密的“代工厂”以前我觉得浏览器渲染就是个玄学现在我才明白它本质上是一个严密的“代码代工厂”。当我们按下回车网络进程把 HTML 文件下载回来后就会把它丢进渲染主线程的消息队列里。接下来这台机器就开始执行一套雷打不动的8 步流水线工序解析HTML (Parse HTML)样式计算 (Recalculate Style)布局 (Layout)分层 (Layer)绘制 (Paint)分块 (Tiling)光栅化 (Raster)画 (Draw)这八个步骤环环相扣上一个阶段的输出就是下一个阶段的输入。咱们一个个来看。三、 解析阶段CSS不阻塞JS才是真拦路虎第一步是解析 HTML生成 DOM 树。在这个过程中我一直有个误区觉得 CSS 加载慢会卡住页面的解析。但查完资料我才发现浏览器非常聪明它在解析前会启动一个“预解析线程”。这个线程会提前去下载外部的 CSS 和 JS 文件。冷知识当主线程解析到link标签时它根本不需要停下来等继续往下跑就行。这就是 CSS 不会阻塞 HTML 解析的根本原因。但是JavaScript 就完全是另一回事了。一旦主线程遇到了script标签整条流水线必须立刻强制停止为什么呢JS 是单线程的它随时可能通过 DOM API 修改当前的页面结构浏览器不敢赌只能老老实实等 JS 下载并全局执行完毕后才敢继续解析后面的 HTML。这也解释了为什么我们在做首屏优化时一定要想尽办法让 JS 异步加载比如使用async或defer。四、 样式计算与布局DOM树和布局树竟然不是双胞胎HTML 解析完后主线程会遍历 DOM 树结合 CSSOM 进行样式计算。这一步会把所有的相对单位如em转成绝对单位px把颜色名称red转成rgb值。紧接着就是最耗性能的布局Layout阶段也就是大家常说的“重排Reflow”。浏览器要在这里计算出每个节点的宽高和确切位置。这里有一个让我大跌眼镜的细节DOM 树和布局树并不是一一对应的场景DOM 树布局树 (Layout Tree)display: none的元素存在消失不占空间::before / ::after伪元素不存在凭空出现有几何信息搞懂了这个你就知道为什么频繁操作 DOM 会这么卡了——因为布局树的重新计算代价极高。五、 为什么 transform 动画丝滑得像德芙聊到这里终于到了大家最关心的性能优化核心了。在布局和样式计算之后浏览器会进入分层Layer和绘制Paint阶段。主线程会为每个图层生成绘制指令集然后交给合成线程去做分块Tiling和光栅化Raster。最后合成线程拿到位图后会生成一个个叫“Quad指引”的东西告诉 GPU 这些像素该画在屏幕的哪个位置。那么重点来了为什么我们说transform和opacity效率高因为这两个属性既不会影响布局Layout也不会影响绘制指令Paint。它们影响的仅仅是最后一个Draw 阶段。由于 Draw 阶段是在合成线程中完成的甚至直接由 GPU 硬件加速处理所以transform的变化几乎完全绕过了繁忙的渲染主线程。反之如果你去改left或width浏览器就得乖乖回去重新算布局、重新绘制那能不卡吗六、 避坑指南千万别在循环里读布局属性在研究文档时我还看到了一个极易被忽视的性能陷阱——强制同步布局Layout Thrashing。什么意思呢当你在 JavaScript 里读取某些布局属性比如offsetHeight、getBoundingClientRect()时浏览器为了保证你能拿到最新的准确数据会被迫立即中断当前任务强行执行一次布局计算。如果你在循环里先读了一个高度紧接着又去修改样式再读一次高度……恭喜你你成功引发了连续多次的重排性能直接崩盘。// 错误的做法读写交替触发多次重排 for (let i 0; i items.length; i) { const height items[i].offsetHeight; // 强制触发布局计算 items[i].style.height height 10 px; // 修改样式 } // 正确的做法读写分离 const heights []; // 1. 统一读取 for (let i 0; i items.length; i) { heights.push(items[i].offsetHeight); } // 2. 统一修改 for (let i 0; i items.length; i) { items[i].style.height heights[i] 10 px; }七、 写在最后梳理完这一套流程我最大的感触就是前端性能优化真的不是靠微操而是一种架构思维。我们在写每一行 CSS 和 JS 的时候脑子里都应该有一张渲染流水线的地图多问自己一句“我这行代码会让浏览器重新计算布局吗”希望我今天分享的这些从文档里挖出来的底层细节能帮你打通前端性能优化的“任督二脉”。如果觉得这篇文章对你有启发欢迎点赞收藏或者在评论区留下你的看法咱们一起交流
浏览器的“黑盒”解密：从一行代码到屏幕成像，到底发生了什么？
发布时间：2026/6/9 7:29:23
一、 前言最近在做前端性能优化的时候我发现自己陷入了一个怪圈遇到页面卡顿就去百度搜“优化技巧”然后机械地把transform替换掉left或者给 JS 加上defer。但每当别人问我一句“为什么这样会快”的时候我就只能支支吾吾地说“因为……大家都这么说。”这种知其然不知其所以然的感觉太难受了。于是这两天我沉下心去啃了一下浏览器渲染原理的相关资料。不看不知道一看吓一跳原来我们写的一行简单代码在浏览器的“黑盒”里竟然经历了一场如此精密的流水线作业。今天我就想把这些枯燥的底层原理用我自己的理解掰开了揉碎了分享给大家。二、 浏览器其实是个精密的“代工厂”以前我觉得浏览器渲染就是个玄学现在我才明白它本质上是一个严密的“代码代工厂”。当我们按下回车网络进程把 HTML 文件下载回来后就会把它丢进渲染主线程的消息队列里。接下来这台机器就开始执行一套雷打不动的8 步流水线工序解析HTML (Parse HTML)样式计算 (Recalculate Style)布局 (Layout)分层 (Layer)绘制 (Paint)分块 (Tiling)光栅化 (Raster)画 (Draw)这八个步骤环环相扣上一个阶段的输出就是下一个阶段的输入。咱们一个个来看。三、 解析阶段CSS不阻塞JS才是真拦路虎第一步是解析 HTML生成 DOM 树。在这个过程中我一直有个误区觉得 CSS 加载慢会卡住页面的解析。但查完资料我才发现浏览器非常聪明它在解析前会启动一个“预解析线程”。这个线程会提前去下载外部的 CSS 和 JS 文件。冷知识当主线程解析到link标签时它根本不需要停下来等继续往下跑就行。这就是 CSS 不会阻塞 HTML 解析的根本原因。但是JavaScript 就完全是另一回事了。一旦主线程遇到了script标签整条流水线必须立刻强制停止为什么呢JS 是单线程的它随时可能通过 DOM API 修改当前的页面结构浏览器不敢赌只能老老实实等 JS 下载并全局执行完毕后才敢继续解析后面的 HTML。这也解释了为什么我们在做首屏优化时一定要想尽办法让 JS 异步加载比如使用async或defer。四、 样式计算与布局DOM树和布局树竟然不是双胞胎HTML 解析完后主线程会遍历 DOM 树结合 CSSOM 进行样式计算。这一步会把所有的相对单位如em转成绝对单位px把颜色名称red转成rgb值。紧接着就是最耗性能的布局Layout阶段也就是大家常说的“重排Reflow”。浏览器要在这里计算出每个节点的宽高和确切位置。这里有一个让我大跌眼镜的细节DOM 树和布局树并不是一一对应的场景DOM 树布局树 (Layout Tree)display: none的元素存在消失不占空间::before / ::after伪元素不存在凭空出现有几何信息搞懂了这个你就知道为什么频繁操作 DOM 会这么卡了——因为布局树的重新计算代价极高。五、 为什么 transform 动画丝滑得像德芙聊到这里终于到了大家最关心的性能优化核心了。在布局和样式计算之后浏览器会进入分层Layer和绘制Paint阶段。主线程会为每个图层生成绘制指令集然后交给合成线程去做分块Tiling和光栅化Raster。最后合成线程拿到位图后会生成一个个叫“Quad指引”的东西告诉 GPU 这些像素该画在屏幕的哪个位置。那么重点来了为什么我们说transform和opacity效率高因为这两个属性既不会影响布局Layout也不会影响绘制指令Paint。它们影响的仅仅是最后一个Draw 阶段。由于 Draw 阶段是在合成线程中完成的甚至直接由 GPU 硬件加速处理所以transform的变化几乎完全绕过了繁忙的渲染主线程。反之如果你去改left或width浏览器就得乖乖回去重新算布局、重新绘制那能不卡吗六、 避坑指南千万别在循环里读布局属性在研究文档时我还看到了一个极易被忽视的性能陷阱——强制同步布局Layout Thrashing。什么意思呢当你在 JavaScript 里读取某些布局属性比如offsetHeight、getBoundingClientRect()时浏览器为了保证你能拿到最新的准确数据会被迫立即中断当前任务强行执行一次布局计算。如果你在循环里先读了一个高度紧接着又去修改样式再读一次高度……恭喜你你成功引发了连续多次的重排性能直接崩盘。// 错误的做法读写交替触发多次重排 for (let i 0; i items.length; i) { const height items[i].offsetHeight; // 强制触发布局计算 items[i].style.height height 10 px; // 修改样式 } // 正确的做法读写分离 const heights []; // 1. 统一读取 for (let i 0; i items.length; i) { heights.push(items[i].offsetHeight); } // 2. 统一修改 for (let i 0; i items.length; i) { items[i].style.height heights[i] 10 px; }七、 写在最后梳理完这一套流程我最大的感触就是前端性能优化真的不是靠微操而是一种架构思维。我们在写每一行 CSS 和 JS 的时候脑子里都应该有一张渲染流水线的地图多问自己一句“我这行代码会让浏览器重新计算布局吗”希望我今天分享的这些从文档里挖出来的底层细节能帮你打通前端性能优化的“任督二脉”。如果觉得这篇文章对你有启发欢迎点赞收藏或者在评论区留下你的看法咱们一起交流
