浏览器渲染的核心是将HTML、CSS和JavaScript转化为屏幕像素，经历解析、DOM/CSSOM构建、渲染树生成、布局、绘制及合成阶段。JavaScript可动态修改页面，但也可能阻塞解析与渲染。关键优化在于减少回流与重绘，利用合成层实现GPU加速动画。
浏览器渲染的核心，是将我们编写的HTML、CSS和JavaScript代码，一步步转化为屏幕上可见的像素图像。这个过程远不止我们想象的那么简单，它涉及了从最初的文件解析，到构建DOM和CSSOM，再到布局、绘制，最终通过合成器（Compositor）将所有元素高效地呈现在用户面前。JavaScript在其中扮演着关键角色，它能动态地修改页面结构和样式，直接影响甚至阻塞这些渲染步骤。理解这个流程，是前端工程师优化性能、打造流畅用户体验的基础。
解决方案
说实话，刚开始接触这些概念的时候，我也被各种“树”、“层”搞得有点晕，觉得这玩意儿挺玄乎的。但一旦拆解开来，你会发现它其实是一个相当精妙的流水线作业。整个流程大致可以分为几个关键阶段，每个阶段都有其独特的任务，并且JavaScript的介入，让这个流程变得更加动态，也更复杂。
首先，当浏览器接收到HTML文件时，它会启动HTML解析器，将原始的字节流转换为字符，然后是令牌（Tokens），最终构建出我们熟悉的DOM树（Document Object Model）。这个过程中，如果遇到
标签，特别是那些没有
async
或
defer
属性的脚本，HTML解析器会暂停，转而去下载并执行JavaScript代码。这也就是为什么我们常说，阻塞性的JavaScript会延迟页面的首次渲染。
与此同时，浏览器也会处理CSS文件。CSS解析器会将CSS样式规则解析成CSSOM树（CSS Object Model）。CSSOM树与DOM树是独立的，但它们最终会结合起来。我个人觉得，CSSOM的构建是阻塞渲染的，这一点特别值得注意，因为浏览器需要完整的样式信息才能正确计算元素的最终样式，进而构建渲染树。
立即学习“前端免费学习笔记（深入）”；
DOM树和CSSOM树都构建完成后，浏览器会将它们合并，形成渲染树（Render Tree），或者现在更常被称为布局树（Layout Tree）。这棵树只包含需要显示在页面上的可见元素。那些设置了
display: none
的元素，就不会进入渲染树，这在我看来是一个很巧妙的优化点。渲染树的每个节点都包含了元素的可见属性，比如颜色、尺寸等等。
接着是布局（Layout）阶段，也叫回流（Reflow）。在这个阶段，浏览器会根据渲染树，计算每个元素在屏幕上的精确位置和大小。这是一个递归的过程，从根节点开始，遍历所有可见元素，确定它们在视口中的几何信息。这个过程是相当耗费资源的，因为任何一个元素的尺寸或位置变化，都可能影响到其兄弟元素、父元素甚至整个文档的布局。JavaScript如果频繁地读写DOM属性（比如
offsetWidth
、
clientHeight
），会强制浏览器立即执行布局，导致所谓的“布局抖动”（Layout Thrashing），这绝对是前端性能的杀手之一。
布局完成后，就进入了绘制（Paint）阶段，也叫重绘（Repaint）。浏览器会遍历渲染树，将布局阶段计算出的所有几何信息，转化为屏幕上的实际像素。这个过程会将元素绘制到不同的“层”（Layer）上。比如，背景、边框、文本内容等都会被绘制出来。重绘的开销通常比回流小，因为它不涉及几何信息的重新计算，只是更新像素。但如果一个元素被多次重绘，累积起来的开销也可能不容小觑。
最后，也是现代浏览器渲染性能的关键所在，是合成（Compositing）阶段。绘制完成后，浏览器会将所有这些独立的层按照正确的顺序和位置堆叠起来，最终呈现在屏幕上。这个工作通常由一个独立的合成器线程（Compositor Thread）和GPU来完成。在我看来，这是浏览器渲染架构中最优雅的部分之一，因为它允许浏览器在不重新布局或绘制整个页面的情况下，高效地处理元素的移动、缩放或透明度变化，极大地提升了动画的流畅度。JavaScript通过
transform
、
opacity
等CSS属性触发的动画，往往能直接跳过布局和绘制阶段，直接进入合成阶段，从而获得更好的性能。
DOM、CSSOM 与渲染树：浏览器如何理解你的代码结构？
说起浏览器如何“理解”我们的代码，这得从它构建内部数据结构说起。这就像我们盖房子，得先有设计图纸（HTML），再有装修风格（CSS），最后才能把房子搭起来。
当浏览器拿到HTML文件，它会启动一个HTML解析器。这个解析器可不是简单地读一遍文件，它会把文件内容从字节流一步步转换成字符，再变成一个个有意义的“令牌”（Tokens），比如
、
、
这些标签。接着，这些令牌会被组织成节点对象，最终构建出一棵树形结构，也就是DOM（Document Object Model）树。这棵树直观地反映了HTML文档的结构，每个HTML标签都对应DOM树上的一个节点。
有个细节我一直觉得很有趣：当HTML解析器遇到
标签时，如果这个脚本没有
async
或
defer
属性，解析器就会停下来，去下载并执行这个JavaScript文件。直到脚本执行完毕，HTML解析才会继续。这种“暂停-执行-继续”的模式，直接影响了页面的加载速度和用户体验，因为用户可能要等脚本执行完才能看到页面内容。这也是为什么我们常把JS文件放在
底部或者使用
async
/
defer
来优化加载。
与此同时，浏览器也会处理CSS文件。CSS解析器会把所有的样式规则解析成另一个树形结构，叫做CSSOM（CSS Object Model）树。这棵树描述了每个元素的样式信息，比如字体、颜色、大小等等。与DOM树不同，CSSOM树的构建是“阻塞渲染”的。这意味着浏览器必须等到所有的CSS文件都被下载并解析完毕，才能开始构建渲染树，因为任何一个元素的最终样式都可能依赖于整个CSS文件中的规则，比如继承、层叠等。
一旦DOM树和CSSOM树都准备好了，浏览器就会把它们“嫁接”起来，形成渲染树（Render Tree）。在我看来，渲染树是DOM和CSSOM的“合体”，它包含了所有可见元素及其计算后的样式。这里有个重要的点：只有那些最终会显示在页面上的元素才会进入渲染树。比如，如果你给一个
设置了
display: none，那么这个
及其子元素就不会出现在渲染树中。但如果是
visibility: hidden，元素会出现在渲染树中，只是不可见，因为它仍然占据着布局空间。理解这个差异，对优化页面性能非常关键。渲染树的构建，标志着浏览器已经初步理解了页面的结构和样式，为接下来的布局和绘制做好了准备。
回流与重绘：前端性能瓶颈的幕后推手及优化策略
在浏览器渲染的流程里，回流（Reflow）和重绘（Repaint）绝对是两个让前端开发者又爱又恨的词。它们是页面更新的必然产物，但如果触发得不恰当或过于频繁，就会成为拖慢页面性能的“罪魁祸首”。
回流，也被称为布局（Layout），顾名思义，就是浏览器重新计算文档中元素几何属性（位置和大小）的过程。每当DOM结构发生变化、元素尺寸或位置发生改变（比如修改了
width、
height、
padding、
margin、
border、
top、
left等），或者内容发生变化（比如文本内容、图片大小），甚至只是窗口大小调整，都可能触发回流。回流的影响是连锁反应式的，一个元素的几何属性改变，可能会导致其父元素、兄弟元素，甚至整个文档的布局都需要重新计算。我个人觉得，回流是浏览器渲染过程中最耗性能的环节之一，因为它涉及了大量的计算。
举个例子，如果你用JavaScript连续修改一个元素的样式：
const element = document.getElementById('myElement');element.style.width = '100px'; // 触发回流element.style.height = '100px'; // 再次触发回流element.style.margin = '10px'; // 又一次触发回流这样连续操作，浏览器可能会每次修改都尝试执行回流，这叫做“布局抖动”（Layout Thrashing）。聪明的浏览器会尝试批量处理这些样式修改，但在某些情况下，比如当你读取一个元素的几何属性（
element.offsetWidth、
element.clientHeight、
getComputedStyle()等）后立即修改样式，浏览器就不得不立即执行回流，以确保你读取到的是最新的、准确的值。
而重绘（Repaint）则相对“轻量”一些。它发生在元素的几何属性没有改变，但其外观样式发生变化时，比如修改了
color、
background-color、
visibility等不影响布局的属性。重绘只是重新绘制元素的像素，不需要重新计算布局，所以它的开销通常比回流小。
那么，如何优化回流和重绘呢？这其实是前端性能优化的一个永恒话题：
减少DOM操作： 频繁地添加、删除或修改DOM元素是回流的常见原因。可以考虑使用文档碎片（DocumentFragment）进行批量DOM操作，或者通过修改元素的
innerHTML一次性更新内容。避免频繁读写布局属性： 就像前面提到的，连续读取几何属性后立即修改样式，会强制浏览器同步执行回流。一个好的习惯是，先读取所有需要的布局属性，然后再统一进行样式修改。使用CSS动画替代JS动画： 对于动画，优先使用CSS的
transform和
opacity属性。这些属性的改变通常只会触发重绘或直接进入合成阶段，而不会触发回流。将元素脱离文档流： 对于需要频繁操作的元素，可以将其
position设置为
absolute或
fixed，使其脱离文档流。这样，它的改变就不会影响到其他元素的布局，从而减少回流的范围。操作完成后，再将其放回文档流。避免使用
table布局：
table元素的布局算法非常复杂，任何对
table内容的修改都可能导致整个表格的回流，开销巨大。利用
will-change属性： 这是一个CSS属性，可以提前告诉浏览器哪些元素将会发生变化，从而让浏览器进行一些优化，比如为该元素创建独立的层，从而减少回流和重绘的影响。但也要注意，滥用
will-change反而可能导致性能下降。
在我看来，优化回流和重绘，核心思想就是“减少不必要的计算和绘制”。通过理解浏览器的工作原理，我们能更聪明地编写代码，让页面跑得更快。
深入 Composite 层：GPU 加速与流畅动画的秘密
如果说回流和重绘是页面性能的“日常挑战”，那么合成（Compositing）层，在我看来，就是现代浏览器在追求极致流畅用户体验上的一张“王牌”，尤其是对于复杂的动画和交互。这个阶段是整个渲染流程的终点，也是GPU发挥其强大并行计算能力的地方。
在绘制（Paint）阶段，浏览器会把页面内容绘制到不同的“层”（Layer）上。你可以把这些层想象成Photoshop里的图层，它们是独立的，可以单独移动、缩放或改变透明度，而不会影响到其他层。哪些元素会被提升到独立的层呢？通常包括：
拥有
transform属性的元素（比如
translateZ、
scale等）。拥有
opacity属性的元素。使用
will-change属性声明的元素。视频元素、
canvas元素。一些拥有复杂CSS属性（如
filter、
mix-blend-mode）的元素。滚动区域。
这些独立的层，在渲染管线中被称为“合成层”（Compositing Layers）。当一个元素被提升到合成层后，它的绘制就被交给了合成器线程（Compositor Thread）来管理。这个线程会独立于主线程（负责JavaScript执行、样式计算、布局和绘制）工作。
合成器线程会把这些层的信息（包括它们的位置、大小、透明度以及指向它们像素数据的指针）发送给GPU（图形处理器）。GPU利用其并行计算能力，将这些独立的层高效地合并在一起，最终形成我们看到的屏幕图像。这个过程叫做“合成”。
为什么合成层对于性能，尤其是动画性能至关重要？
关键在于，一旦一个元素被提升到合成层，它的一些属性变化（比如
transform的
translate、
scale，或者
opacity）就只会在合成器线程上处理，直接利用GPU进行渲染。这意味着：
跳过布局和绘制： 这些变化不再需要主线程进行布局计算或重新绘制，大大减少了主线程的负担。GPU加速： GPU在处理图像和图形方面有天然优势，能够以极高的帧率完成合成操作，从而实现非常流畅的动画效果，即使在主线程繁忙时也能保持。独立性： 一个合成层的变化不会影响到其他层，避免了不必要的重绘和回流。
所以，当我们用CSS
transform: translate(x, y)来移动元素时，通常会比修改
left或
top属性更流畅，因为前者可以直接在合成层上操作，而后者会触发回流和重绘。
当然，合成层也不是越多越好。创建过多的合成层会增加内存开销，并且在某些低端设备上，层之间的切换和管理也可能带来额外的性能负担。我有时候会看到一些开发者为了“优化”而滥用
will-change，结果反而适得其反。所以，理解其原理并适度使用，才是真正的智慧。
总之，Composite层是现代浏览器实现高性能、流畅动画的秘密武器。它通过将部分渲染工作卸载到独立的合成器线程和强大的GPU上，使得页面在面对复杂交互和动画时，依然能保持出色的响应速度。理解并善用这一机制，无疑是提升前端应用用户体验的关键一步。
以上就是JS 浏览器渲染原理 – 从解析 HTML 到 Composite 层的完整流程的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521642.html赞 (0)打赏微信扫一扫
支付宝扫一扫
微信扫一扫 
支付宝扫一扫 关于作者
相关推荐
-
如何实现一个JavaScript的中间件模式，比如Express中的中间件？
答案：实现一个类Express中间件系统，通过use添加函数到队列，run启动流程，next控制执行流转。核心是维护中间件数组并递归调用next执行下一个，支持同步与异步操作，可扩展错误处理。 实现一个类似 Express 的 JavaScript 中间件模式，核心是将多个函数串联起来，通过 nex…
-
JavaScript对象值校验：确保字符串和数组非空
本教程将深入探讨如何在JavaScript中高效地验证一个对象的所有值，确保其包含的字符串和数组类型字段均不为空。我们将通过Object.values()和every()方法，提供一个简洁而强大的解决方案，帮助开发者构建更健壮的数据校验逻辑，并讨论其适用性、局限性及扩展考虑。 理解需求：对象值非空校…
-
如何解决Mineflayer Python机器人中的ENOTFOUND错误
本文旨在解决使用Python通过javascript模块运行Mineflayer机器人时遇到的ENOTFOUND错误。尽管该错误通常指向主机或端口配置问题，但实际案例表明，一个过于复杂或动态生成的用户名也可能是导致连接失败的间接原因。教程将提供解决方案和相关排查建议。 Mineflayer在Pyth…
-
JavaScript对象属性非空校验：字符串与数组的高效验证
本文介绍一种高效方法，用于校验JavaScript对象中的字符串和数组属性是否为空。通过结合使用Object.values()和Array.prototype.every()方法，能够简洁地遍历对象的所有值，并确保所有字符串和数组类型的属性都具有非零长度，从而实现快速、可靠的数据验证。 引言：对象属…
-
在Qualtrics问卷中精确计算用户停留时间（跨日处理）
本教程详细介绍了如何在Qualtrics问卷中计算用户输入的开始时间和结束时间之间的分钟差，尤其关注跨午夜（即跨日）情况的处理。文章提供了两种实现方法：纯JavaScript原生实现和利用Moment.js库的优化方案，并附有详细代码示例和注意事项，帮助开发者准确获取用户在特定活动中的持续时间，并将…
-
深入理解Socket.io国际象棋将军检测逻辑与实现优化
本文探讨了在线国际象棋游戏中使用Socket.io进行将军（Check）检测时遇到的常见逻辑错误。核心问题在于前端onDrop函数中，将军检测逻辑错误地检查了当前玩家的棋盘而非对手的棋盘。通过调整checkControl变量的赋值逻辑，将其从检查当前玩家颜色反转为检查对手颜色，成功解决了将军信号无法…
-
JavaScript中检测带有特定类名的元素是否获得焦点
本文探讨了如何利用 document.activeElement 属性结合 classList.contains() 方法，准确判断页面中具有特定CSS类名的元素是否获得了焦点。通过事件监听器实时响应用户交互，我们能够有效地跟踪焦点状态，并针对不同类名的元素进行精确识别和处理。 理解 documen…
-
使用ES6特性批量修改JavaScript对象数组的键名
本文将介绍如何利用ES6+的现代JavaScript特性，高效地批量重构对象数组中的键名。通过结合Array.map、Object.entries、String.replace和Object.fromEntries，可以轻松实现对键名中特定后缀（如-0、-1）的清理和转换，生成结构清晰的新对象数组，…
-
如何通过 JavaScript 的 Web Components 实现真正的组件复用？
Web Components通过Shadow DOM、自定义元素和HTML模板实现跨框架复用。1. Shadow DOM隔离样式与结构，防止污染全局；2. 自定义元素支持语义化标签与属性监听，提升可操作性；3. 插槽机制增强内容灵活性；4. 封装逻辑并暴露事件与方法接口，实现解耦通信。合理运用这些技…
-
如何构建一个可访问性(A11y)完备的UI组件库？
构建可访问性完备的UI组件库需将A11y融入全流程：遵循WAI-ARIA标准，优先使用语义化HTML和原生元素，避免div模拟按钮；为自定义组件添加role、aria-label等属性；确保表单有label关联；模态框设置aria-modal并管理焦点进出；支持键盘导航，保持聚焦顺序与视觉一致，复合…
-
优化 Material Symbols 字体加载性能：按需引入与配置
Material Symbols 字体因其默认加载所有变体而导致页面加载缓慢，尤其是在移动网络下。本文将详细介绍如何通过定制 Google Fonts API 请求URL，按需选择字体变体（如字重、填充状态），从而显著减小字体文件大小，加速页面渲染，提升用户体验。此方法可将字体文件从数MB有效缩减至…
-
优化React useEffect实现用户资料实时更新
本文旨在解决React应用中用户登录后个人资料未能实时更新，需要刷新页面才能显示最新数据的问题。通过深入分析useEffect钩子的工作原理及其依赖项管理，文章提出了一种基于用户身份变化触发数据获取的解决方案，并提供了具体的代码示例和最佳实践，确保用户体验的流畅性。 问题分析：useEffect的触…
-
如何实现一个基于WebRTC的屏幕共享功能？
首先通过 getDisplayMedia() 获取屏幕视频流，再将其视频轨道添加到 RTCPeerConnection 中实现共享。需在 HTTPS 环境下调用 getDisplayMedia({ video: true }) 请求用户选择屏幕内容，成功后返回 MediaStream 并绑定到 vi…
-
JavaScript中检测非数值结果（NaN）的实用指南
在JavaScript开发中，尤其是在构建计算器等应用时，有效处理非数值（NaN）结果至关重要，以避免显示不友好的错误信息，例如由虚数运算导致的NaN。本文将深入探讨如何利用JavaScript内置的isNaN()函数来准确检测变量是否为非数值，从而实现更健壮的错误处理机制，提升用户体验，确保应用在…
-
JavaScript中的设计模式（如观察者模式）如何应用？
观察者模式通过一对多依赖实现自动通知，JavaScript中可用Subject和Observer类实现，典型应用包括事件监听、状态管理和组件通信，如Vue和Event Bus，优点是解耦与扩展性，但需注意性能和内存泄漏。 JavaScript中的设计模式能帮助我们写出更清晰、可维护和可扩展的代码。其…
-
强制刷新HTML页面：处理浏览器回退场景下的数据一致性
当用户从其他页面回退到前一页面时，浏览器通常会利用缓存（如BFcache）来快速加载，导致window.onload事件不触发，页面内容和功能可能无法按预期更新。本教程将深入探讨这一问题，并提供一种利用window.onbeforeunload事件强制页面重新加载的解决方案，确保每次回退都能获取到最…
-
JSX中展开运算符（Spread Operator）的深入解析与属性传递机制
本文旨在深入探讨React JSX中展开运算符（{…rest}）在属性传递中的必要性及其与JavaScript对象展开语法的区别。我们将阐明为何在JSX中直接使用{rest}是无效的，并揭示JSX属性如何通过React.createElement转换，最终在HTML中以=作为分隔符呈现。…
-
如何构建一个支持多语言国际化的前端应用？
答案：实现多语言国际化需选用i18next等成熟框架，按语言和模块组织JSON资源文件，支持动态切换与浏览器语言自动匹配，结合Intl API处理日期、数字等本地化格式，并通过持久化用户偏好保障体验一致性。 构建一个支持多语言国际化的前端应用，关键在于统一管理文本资源、动态切换语言、适配不同区域习惯…
-
在JSX中处理动态字段名与简化复杂数据访问的教程
本文详细介绍了在React JSX中如何优雅地处理具有动态索引的字段名，通过正确的方括号语法实现动态属性访问。同时，针对深层嵌套对象的冗余检查，文章展示了如何利用JavaScript的可选链操作符简化代码，提升可读性和健壮性，确保组件渲染的准确性与简洁性。 在react开发中，我们经常会遇到需要根据…
-
如何利用Web Workers提升前端应用的性能与响应能力？
Web Workers通过将耗时任务移至后台线程避免主线程阻塞，提升前端性能。它基于独立上下文运行JavaScript，不访问DOM，通过postMessage通信，适用于大数据处理、加密解压等计算密集型任务。创建Worker实例并加载单独JS文件即可实现异步执行，如数组排序不卡页面。需注意结构化克…
