你不知道的浏览器渲染原理

言

浏览器的内核是指支持浏览器运行的最核心的程序，分为两个部分的，一是渲染引擎，另一个是 JS 引擎。渲染引擎在不同的浏览器中也不是都相同的。目前市面上常见的浏览器内核可以分为这四种：Trident（IE）、Gecko（火狐）、Blink（Chrome、Opera）、Webkit（Safari）。这里面大家最耳熟能详的可能就是 Webkit 内核了，Webkit 内核是当下浏览器世界真正的霸主。

本文我们就以 Webkit 为例，对现代浏览器的渲染过程进行一个深度的剖析。

想阅读更多优质文章请猛戳GitHub 博客。

页面加载过程

在介绍浏览器渲染过程之前，我们简明扼要介绍下页面的加载过程，有助于更好理解后续渲染过程。

要点如下：

浏览器根据 DNS 服务器得到域名的 IP 地址；
向这个 IP 的机器发送 HTTP 请求；
服务器收到、处理并返回 HTTP 请求；
浏览器得到返回内容。

例如在浏览器输入https://juejin.im/timeline，然后经过 DNS 解析，juejin.im对应的 IP 是36.248.217.149（不同时间、地点对应的 IP 可能会不同）。然后浏览器向该 IP 发送 HTTP 请求。

服务端接收到 HTTP 请求，然后经过计算（向不同的用户推送不同的内容），返回 HTTP 请求，返回的内容如下：

其实就是一堆 HMTL 格式的字符串，因为只有 HTML 格式浏览器才能正确解析，这是 W3C 标准的要求。接下来就是浏览器的渲染过程。

浏览器渲染过程

浏览器渲染过程大体分为如下三部分：

1）浏览器会解析三个东西：

一是 HTML/SVG/XHTML，HTML 字符串描述了一个页面的结构，浏览器会把 HTML 结构字符串解析转换 DOM 树形结构。

二是 CSS，解析 CSS 会产生 CSS 规则树，它和 DOM 结构比较像。

三是 Javascript 脚本，等到 Javascript 脚本文件加载后，通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree。

2）解析完成后，浏览器引擎会通过 DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。

Rendering Tree 渲染树并不等同于 DOM 树，渲染树只会包括需要显示的节点和这些节点的样式信息。
CSS 的 Rule Tree 主要是为了完成匹配并把 CSS Rule 附加上 Rendering Tree 上的每个 Element（也就是每个 Frame）。
然后，计算每个 Frame 的位置，这又叫 layout 和 reflow 过程。

3）最后通过调用操作系统 Native GUI 的 API 绘制。

接下来我们针对这其中所经历的重要步骤详细阐述

构建 DOM

浏览器会遵守一套步骤将 HTML 文件转换为 DOM 树。宏观上，可以分为几个步骤：

浏览器从磁盘或网络读取 HTML 的原始字节，并根据文件的指定编码（例如 UTF-8）将它们转换成字符串。

在网络中传输的内容其实都是 0 和 1 这些字节数据。当浏览器接收到这些字节数据以后，它会将这些字节数据转换为字符串，也就是我们写的代码。

将字符串转换成 Token，例如：<html>、<body>等。Token 中会标识出当前 Token 是“开始标签”或是“结束标签”亦或是“文本”等信息。

这时候你一定会有疑问，节点与节点之间的关系如何维护？

事实上，这就是 Token 要标识“起始标签”和“结束标签”等标识的作用。例如“title”Token 的起始标签和结束标签之间的节点肯定是属于“head”的子节点。

上图给出了节点之间的关系，例如：“Hello”Token 位于“title”开始标签与“title”结束标签之间，表明“Hello”Token 是“title”Token 的子节点。同理“title”Token 是“head”Token 的子节点。

生成节点对象并构建 DOM

事实上，构建 DOM 的过程中，不是等所有 Token 都转换完成后再去生成节点对象，而是一边生成 Token 一边消耗 Token 来生成节点对象。换句话说，每个 Token 被生成后，会立刻消耗这个 Token 创建出节点对象。注意：带有结束标签标识的 Token 不会创建节点对象。

接下来我们举个例子，假设有段 HTML 文本：

复制代码

<html>
<head>
 <title>Web page parsing</title>
</head>
<body>
 <div>
 <h1>Web page parsing</h1>
 <p>This is an example Web page.</p>
 </div>
</body>
</html>

上面这段 HTML 会解析成这样：

构建 CSSOM

DOM 会捕获页面的内容，但浏览器还需要知道页面如何展示，所以需要构建 CSSOM。

构建 CSSOM 的过程与构建 DOM 的过程非常相似，当浏览器接收到一段 CSS，浏览器首先要做的是识别出 Token，然后构建节点并生成 CSSOM。

在这一过程中，浏览器会确定下每一个节点的样式到底是什么，并且这一过程其实是很消耗资源的。因为样式你可以自行设置给某个节点，也可以通过继承获得。在这一过程中，浏览器得递归 CSSOM 树，然后确定具体的元素到底是什么样式。

注意：CSS 匹配 HTML 元素是一个相当复杂和有性能问题的事情。所以，DOM 树要小，CSS 尽量用 id 和 class，千万不要过渡层叠下去。

构建渲染树

当我们生成 DOM 树和 CSSOM 树以后，就需要将这两棵树组合为渲染树。

在这一过程中，不是简单的将两者合并就行了。渲染树只会包括需要显示的节点和这些节点的样式信息，如果某个节点是 display: none 的，那么就不会在渲染树中显示。

我们或许有个疑惑：浏览器如果渲染过程中遇到 JS 文件怎么处理？

渲染过程中，如果遇到<script>就停止渲染，执行 JS 代码。因为浏览器有 GUI 渲染线程与 JS 引擎线程，为了防止渲染出现不可预期的结果，这两个线程是互斥的关系。JavaScript 的加载、解析与执行会阻塞 DOM 的构建，也就是说，在构建 DOM 时，HTML 解析器若遇到了 JavaScript，那么它会暂停构建 DOM，将控制权移交给 JavaScript 引擎，等 JavaScript 引擎运行完毕，浏览器再从中断的地方恢复 DOM 构建。

也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都建议将 script 标签放在 body 标签底部的原因。当然在当下，并不是说 script 标签必须放在底部，因为你可以给 script 标签添加 defer 或者 async 属性（下文会介绍这两者的区别）。

JS 文件不只是阻塞 DOM 的构建，它会导致 CSSOM 也阻塞 DOM 的构建。

原本 DOM 和 CSSOM 的构建是互不影响，井水不犯河水，但是一旦引入了 JavaScript，CSSOM 也开始阻塞 DOM 的构建，只有 CSSOM 构建完毕后，DOM 再恢复 DOM 构建。

这是什么情况？

这是因为 JavaScript 不只是可以改 DOM，它还可以更改样式，也就是它可以更改 CSSOM。因为不完整的 CSSOM 是无法使用的，如果 JavaScript 想访问 CSSOM 并更改它，那么在执行 JavaScript 时，必须要能拿到完整的 CSSOM。所以就导致了一个现象，如果浏览器尚未完成 CSSOM 的下载和构建，而我们却想在此时运行脚本，那么浏览器将延迟脚本执行和 DOM 构建，直至其完成 CSSOM 的下载和构建。也就是说，在这种情况下，浏览器会先下载和构建 CSSOM，然后再执行 JavaScript，最后在继续构建 DOM。

布局与绘制

当浏览器生成渲染树以后，就会根据渲染树来进行布局（也可以叫做回流）。这一阶段浏览器要做的事情是要弄清楚各个节点在页面中的确切位置和大小。通常这一行为也被称为“自动重排”。

布局流程的输出是一个“盒模型”，它会精确地捕获每个元素在视口内的确切位置和尺寸，所有相对测量值都将转换为屏幕上的绝对像素。

布局完成后，浏览器会立即发出“Paint Setup”和“Paint”事件，将渲染树转换成屏幕上的像素。

以上我们详细介绍了浏览器工作流程中的重要步骤，接下来我们讨论几个相关的问题：

几点补充说明

1.async 和 defer 的作用是什么？有什么区别?

接下来我们对比下 defer 和 async 属性的区别：

其中蓝色线代表 JavaScript 加载；红色线代表 JavaScript 执行；绿色线代表 HTML 解析。

1）情况 1<script src="script.js"></script>

没有 defer 或 async，浏览器会立即加载并执行指定的脚本，也就是说不等待后续载入的文档元素，读到就加载并执行。

2）情况 2<script async src="script.js"></script> (异步下载)

async 属性表示异步执行引入的 JavaScript，与 defer 的区别在于，如果已经加载好，就会开始执行——无论此刻是 HTML 解析阶段还是 DOMContentLoaded 触发之后。需要注意的是，这种方式加载的 JavaScript 依然会阻塞 load 事件。换句话说，async-script 可能在 DOMContentLoaded 触发之前或之后执行，但一定在 load 触发之前执行。

3）情况 3 <script defer src="script.js"></script>(延迟执行)

defer 属性表示延迟执行引入的 JavaScript，即这段 JavaScript 加载时 HTML 并未停止解析，这两个过程是并行的。整个 document 解析完毕且 defer-script 也加载完成之后（这两件事情的顺序无关），会执行所有由 defer-script 加载的 JavaScript 代码，然后触发 DOMContentLoaded 事件。

defer 与相比普通 script，有两点区别：载入 JavaScript 文件时不阻塞 HTML 的解析，执行阶段被放到 HTML 标签解析完成之后。

在加载多个 JS 脚本的时候，async 是无顺序的加载，而 defer 是有顺序的加载。

2. 为什么操作 DOM 慢？

把 DOM 和 JavaScript 各自想象成一个岛屿，它们之间用收费桥梁连接。——《高性能 JavaScript》

JS 是很快的，在 JS 中修改 DOM 对象也是很快的。在 JS 的世界里，一切是简单的、迅速的。但 DOM 操作并非 JS 一个人的独舞，而是两个模块之间的协作。

因为 DOM 是属于渲染引擎中的东西，而 JS 又是 JS 引擎中的东西。当我们用 JS 去操作 DOM 时，本质上是 JS 引擎和渲染引擎之间进行了“跨界交流”。这个“跨界交流”的实现并不简单，它依赖了桥接接口作为“桥梁”（如下图）。

过“桥”要收费——这个开销本身就是不可忽略的。我们每操作一次 DOM（不管是为了修改还是仅仅为了访问其值），都要过一次“桥”。过“桥”的次数一多，就会产生比较明显的性能问题。因此“减少 DOM 操作”的建议，并非空穴来风。

3. 你真的了解回流和重绘吗？

渲染的流程基本上是这样（如下图黄色的四个步骤）：

1. 计算 CSS 样式

2. 构建 Render Tree

3.Layout – 定位坐标和大小

4. 正式开画

注意：上图流程中有很多连接线，这表示了 Javascript 动态修改了 DOM 属性或是 CSS 属性会导致重新 Layout，但有些改变不会重新 Layout，就是上图中那些指到天上的箭头，比如修改后的 CSS rule 没有被匹配到元素。

这里重要要说两个概念，一个是 Reflow，另一个是 Repaint

重绘：当我们对 DOM 的修改导致了样式的变化、却并未影响其几何属性（比如修改了颜色或背景色）时，浏览器不需重新计算元素的几何属性、直接为该元素绘制新的样式（跳过了上图所示的回流环节）。

回流：当我们对 DOM 的修改引发了 DOM 几何尺寸的变化（比如修改元素的宽、高或隐藏元素等）时，浏览器需要重新计算元素的几何属性（其他元素的几何属性和位置也会因此受到影响），然后再将计算的结果绘制出来，这个过程就是回流（也叫重排）。

我们知道，当网页生成的时候，至少会渲染一次。在用户访问的过程中，还会不断重新渲染。重新渲染会重复回流 + 重绘或者只有重绘。

回流必定会发生重绘，重绘不一定会引发回流。重绘和回流会在我们设置节点样式时频繁出现，同时也会很大程度上影响性能。回流所需的成本比重绘高的多，改变父节点里的子节点很可能会导致父节点的一系列回流。

1）常见引起回流属性和方法

任何会改变元素几何信息 (元素的位置和尺寸大小) 的操作，都会触发回流，

添加或者删除可见的 DOM 元素；
元素尺寸改变——边距、填充、边框、宽度和高度；
内容变化，比如用户在 input 框中输入文字；
浏览器窗口尺寸改变——resize 事件发生时；
计算 offsetWidth 和 offsetHeight 属性；
设置 style 属性的值。

2）常见引起重绘属性和方法

3）如何减少回流、重绘

使用 transform 替代 top；
使用 visibility 替换 display: none ，因为前者只会引起重绘，后者会引发回流（改变了布局）；
不要把节点的属性值放在一个循环里当成循环里的变量。

复制代码

for(let i=0; i < 1000; i++) {
 // 获取 offsetTop 会导致回流，因为需要去获取正确的值
 console.log(document.querySelector('.test').style.offsetTop)
}

不要使用 table 布局，可能很小的一个小改动会造成整个 table 的重新布局；
动画实现的速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame；
CSS 选择符从右往左匹配查找，避免节点层级过多；
将频繁重绘或者回流的节点设置为图层，图层能够阻止该节点的渲染行为影响别的节点。比如对于 video 标签来说，浏览器会自动将该节点变为图层。

性能优化策略

基于上面介绍的浏览器渲染原理，DOM 和 CSSOM 结构构建顺序，初始化可以对页面渲染做些优化，提升页面性能。

JS 优化： <script> 标签加上 defer 属性和 async 属性用于在不阻塞页面文档解析的前提下，控制脚本的下载和执行。
defer 属性：用于开启新的线程下载脚本文件，并使脚本在文档解析完成后执行。
async 属性： HTML5 新增属性，用于异步下载脚本文件，下载完毕立即解释执行代码。
CSS 优化： <link> 标签的 rel 属性中的属性值设置为 preload 能够让你在你的 HTML 页面中可以指明哪些资源是在页面加载完成后即刻需要的，最优的配置加载顺序，提高渲染性能。

总结

综上所述，我们得出这样的结论：

浏览器工作流程：构建 DOM -> 构建 CSSOM -> 构建渲染树 -> 布局 -> 绘制。
CSSOM 会阻塞渲染，只有当 CSSOM 构建完毕后才会进入下一个阶段构建渲染树。
通常情况下 DOM 和 CSSOM 是并行构建的，但是当浏览器遇到一个不带 defer 或 async 属性的 script 标签时，DOM 构建将暂停，如果此时又恰巧浏览器尚未完成 CSSOM 的下载和构建，由于 JavaScript 可以修改 CSSOM，所以需要等 CSSOM 构建完毕后再执行 JS，最后才重新 DOM 构建。

参考文章

https://segmentfault.com/q/1010000000640869
https://coolshell.cn/articles/9666.html
https://juejin.im/book/5bdc715fe51d454e755f75ef/section/5c024ecbf265da616a476638
https://mp.weixin.qq.com/s?__biz=MzA5NzkwNDk3MQ==&mid=2650588806&idx=1&sn=408a54e7c8102fd6944c9a40b119015a&chksm=8891d6a2bfe65fb42f493fe9a4dab672dd7e440f31e753196cee0cfbc6696e4f8dd3a669e040&mpshare=1&scene=1&srcid=1228ZrXsmbZKcgCSu7zTVDwy#
https://juejin.im/book/5b936540f265da0a9624b04b/section/5bac3a4df265da0aa81c043c
https://juejin.im/book/5c47343bf265da612b13e5c0/section/5c4737375188255de8397ae3
https://juejin.im/book/5a8f9ddcf265da4e9f6fb959/section/5a8f9f7bf265da4e82635e46

、什么是Canvas

想必学习前端的同学们对Canvas 都不陌生，它是 HTML5 新增的“画布”元素，可以使用JavaScript来绘制图形。

Canvas元素是在HTML5中新增的标签用于在网页实时生成图像，并且可以操作图像内容，基本上它是一个可以用JavaScript操作的位图（bitmap）。Canvas 由一个可绘制区域HTML代码中的属性定义决定高度和宽度。JavaScript代码可以访问该区域，通过一套完整的绘图功能的API生成动态的图形。

二. 引入Canvas的重要性

HTML5 在 2012 年已形成了稳定的版本，在此之前很长一段时间，开发者们绘制图形选择的方案更多是SVG来实现。SVG使用XML来定义图形，就像使用HTML标签一样来控制元素的排布，SVG的本质就是一个DOM元素。当图形内容太过丰富后，性能和内存上就会大打折扣。一旦涉及频繁的图片绘制场景，这个实现对于用户的体验将是毁灭性的。

渲染动画的基本原理，无非是反复地擦除和重绘。为了动画的流畅，留给开发者渲染一帧的时间，只有短短的 16.67ms。在这16.67ms中，我不仅需要处理一些绘制逻辑，计算每个对象的位置、状态，还需要把它们都画出来。如果消耗的时间稍稍多了一些，用户就会感受到“卡顿”。所以，在编写动画时，开发者们无时无刻不担忧着动画的性能，唯恐渲染的耗时过长。

在现代 Web 开发中，开发者们更多的会借助 Canvas 提供的API去绘制上下文，可以自由绘制各种2D和3D图形，创建富有视觉冲击力的游戏场景和角色。Canvas的使用可以使得游戏能够实现流畅的动态效果和用户交互。无论是简单的小游戏还是复杂的游戏引擎，Canvas 都被广泛应用。

下面是做的一个简单的对比试验，可以很明显感受到两者的差距，分别使用SVG和Canvas绘制一个包含着100w个圆形的500*500的图片，根据耗时计算对比，Canvas耗费的时间几乎只有SVG的一半：

三. 计算与渲染

把动画的一帧渲染出来，需要经过以下步骤：

计算：处理网页渲染逻辑，计算每个对象的状态和位置。
渲染：真正把对象绘制出来。

JavaScript 调用 DOM API（包括 Canvas API）以进行渲染。
浏览器（通常是另一个渲染线程）把渲染后的结果呈现在屏幕上的过程。

之前提到过，在动画设计和开发中，每帧只有16.67毫秒的时间用于渲染。这个数值是通过计算每秒60帧得出的平均每帧渲染时间。实际上，并不是所有设备都能够稳定地达到60FPS。因此，为了确保在不同设备上实现一致性的动画效果，最好将每帧的渲染时间控制在10毫秒以内。

大家都知道，通常情况下，渲染的开销远大于计算（相差3~4个量级）。除非使用了一些时间复杂度很高的算法，否则不需要过于深入优化计算环节。Canvas的渲染是在JavaScript引擎中执行绘制逻辑，通过构建画布在内存中，并遍历所有像素点的颜色，最终输出到屏幕上。这种强大的功能可能会增加学习成本，但如今仍然有很多开发者选择和接受Canvas，这要归功于Canvas最大的优势：渲染性能的出色表现。

四. Canvas渲染性能优势

当谈论图形渲染技术时，就不得不提到DOM驻留模式和Canvas快速模式。

DOM驻留模式

DOM驻留模式是一种基于文档对象模型（DOM）的渲染技术。在DOM驻留模式下，页面的布局和样式是由DOM树来掌管的。当页面需要更新时，浏览器会重新计算布局和样式并重新渲染。此模式非常灵活，特别适用于处理动态页面交互和多样化的样式控制。然而，由于需要频繁地重新计算布局和样式，对于复杂的图形渲染任务来说，性能开销相对较高。

Canvas快速模式

Canvas快速模式利用HTML5的Canvas元素进行图形渲染。在这种模式下，开发者可以使用Canvas提供的2D或3D绘图API直接在画布上绘制图形。相比于DOM驻留模式，Canvas快速模式更加高效。它不关心页面的布局和样式，而是在需要时只重绘受影响的部分。这样就避免了频繁的布局和样式计算，提高了渲染性能。

分层提高Canvas性能

开发者们通过分析大量实际场景，总结出一套可以进一步提升Canvas性能的策略，即对变化较少和变化较多的内容进行分开渲染。这种策略就是所谓的分层Canvas。它能够显著降低完全没有必要的渲染性能开销。分层渲染的思想被广泛应用于各种图形相关的领域，从古老的皮影戏、套色印刷术，到现代电影/游戏工业以及虚拟现实领域等等。而分层Canvas只是分层渲染思想在Canvas动画上的一个基础应用。

分层Canvas的核心理念是，动态页面中的每种元素（层）对于渲染频率的需求是不同的。对于许多金融会计等大数据行业的从业者来说，主要数据内容的变化频率和幅度较大（他们通常面临数据变动和频繁计算），而背景表格样式的变化频率或幅度相对较小（基本不变，或者变化缓慢，或者仅在特定时机变化）。因此，需要频繁更新和重绘数据，但对于背景，可能只需要绘制一次，或者每隔200毫秒才重绘一次，而没有必要每16毫秒就重绘一次。

视野之外的绘制

在许多情况下，Canvas 仅仅作为数据展示页面的一部分，充当着一个“窗口”的角色。如果在每次数据更新时，都将所有数据完全绘制到 Canvas 上，很可能会出现大量内容绘制到Canvas 范围之外的情况。虽然调用了绘制 API，但实际上并没有产生任何效果。

因此，判断对象是否位于 Canvas 范围内需要进行额外的计算（例如，需要通过对游戏角色的全局模型矩阵求逆来得出对象的世界坐标，这是一项相对耗时的操作），同时也会增加代码的复杂性。因此，关键是是否需要这样做。

通过在本地代码中进行测试，比较了在视野内和视野外分别绘制100万个圆的耗时。在视野内绘制耗时8936ms，而在视野外绘制耗时2540ms。考虑到计算和绘制之间的耗时差距在3~4个数量级，因此通过计算来判断并避免绘制视野外的内容是一种非常有效的方法。

五. Canvas的应用

之前探讨了SVG和Canvas的绘制性能差异以及Canvas常见的优化方法。知道，对于使用快速模式渲染的Canvas来说，浏览器的每次重绘都是由代码驱动的，无须进行多层解析，因此它的速度非常快。除了速度快之外，Canvas的灵活性也显著优于DOM。可以通过代码精确控制何时以及如何绘制出期望的效果。

在资源消耗方面，DOM的驻留模式意味着场景中的每一个新增元素都会导致额外的内存消耗，而Canvas则没有这个问题。这种差异在页面元素数量增多时尤为明显。

在Canvas出现之前，前端渲染表格只能通过构建复杂的DOM来实现。然而，这种方式会导致浏览器性能成为Web应用的瓶颈，许多开发人员因此放弃了在浏览器上实现电子表格的想法。

Canvas出现后，其快速模式带来的出色性能优势成为了一大亮点，大量、复杂的DOM渲染处理所带来的性能问题因此有了解决之道。

回到电子表格的应用场景，现在已经出现了使用Canvas绘制画布的表格组件。这类组件在渲染数据层时无须重复创建和销毁DOM元素，而且在画布的绘制过程中受到的限制也比DOM元素渲染更少。其中，葡萄城公司的纯前端表格控件——SpreadJS就用到了Canvas实现表格绘制，除了表格之外，Canvas也为数字孪生可视化大屏、页面游戏等应用场景带来了变革（如下图所示）。

六、总结

本文通过介绍Canvas的原理、Canvas的重要性、Canvas在计算与渲染上的作用、Canvas渲染性能优势和Canvas的应用这五个部分，全面而系统地阐述了HTML Canvas在高性能渲染方面的相关知识和技巧。希望读者通过阅读本文能够深入了解Canvas的基本原理和特性，认识到Canvas在Web开发中的重要性，并掌握Canvas在计算与渲染上的作用。

思维新建站官网：jz.inspinovation.com

文|李掌柜

前面给大家介绍了《HTML5移动前端性能优化之加载优化》，今天来向大家介绍如何从网页渲染的层面来优化HTML5前端性能。

一、HTML5使用viewport

通俗的讲，移动设备上的viewport就是设备的屏幕上能用来显示我们的网页的那一块区域，在具体一点，就是浏览器上(也可能是一个app中的webview)用来显示网页的那部分区域，但viewport又不局限于浏览器可视区域的大小，它可能比浏览器的可视区域要大，也可能比浏览器的可视区域要小。在默认情况下，一般来讲，移动设备上的viewport都是要大于浏览器可视区域的，这是因为考虑到移动设备的分辨率相对于桌面电脑来说都比较小，所以为了能在移动设备上正常显示那些传统的为桌面浏览器设计的网站，移动设备上的浏览器都会把自己默认的viewport设为980px或1024px（也可能是其它值，这个是由设备自己决定的），但带来的后果就是浏览器会出现横向滚动条，因为浏览器可视区域的宽度是比这个默认的viewport的宽度要小的。下图列出了一些设备上浏览器的默认viewport的宽度。

二、减少DOM节点

当解析的html文件很大时，生成DOM树占用内存较大，同时遍历（不更新）元素耗时也更长。但这都不是重点，DOM的核心问题是：DOM修改导致的页面重绘、重新排版！重新排版是用户阻塞的操作，同时，如果频繁重排，CPU使用率也会猛涨！

三、尽量使用CSS3动画

CSS虽然是由浏览器实现，按理在浏览器支持的前提下性能会更好，然而使用者如果加入了其他干扰，发生频繁的重绘或者回流，自然性能就差了。

四、Touchmove 和Scroll事件会导致多次渲染

类似touchmove，scroll这类的事件可导致多次渲染，对于这种事件可以通过以下手段进行优化:

1.使用requestAnimationFrame监听帧变化，使得在正确的时间进行渲染

2.增加响应变化的时间间隔，减少重绘次数。

五、GPU加速

触发GPU加速的方式有：CSS3 transitions、CSS3 3D transforms、WebGL 3D 绘制、Video。

GPU加速实际上是大幅减少了合成/绘制时间，从而大大地提高了页面速度，但GPU加速有自己的缺点：

过多的GPU层会带来性能开销，主要原因是使用GPU加速其实是利用了GPU层的缓存，让渲染资源可以重复使用，所以一旦层多了，缓存增大，就会引起别的性能问题。

在线咨询

上一篇：警惕“放假通知”类钓鱼邮件，可能在节前攻陷公司设备
下一篇：HTML培训：如何在HTML中更改文本大小

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商