共计 3925 个字符,预计需要花费 10 分钟才能阅读完成。
浏览器渲染原理
前言
浏览器的次要性能总结起来就是一句话:将用户输出的 URL
转变成可视化的图像。
- 从
URL
到DOM
树; - 从
DOM
树到可视化图像; - 这两个过程之间的关系并没有那么明确,咱们能够统称这两个过程为页面的渲染;
1. 网页的解析过程
- 思考一下:一个网页从
url
输出到浏览器,经验过怎么的解析过程?
- 要想深刻了解下载的过程,咱们还要先了解,一个
index.html
被下载下来后是如何被解析和显示在浏览器上的;
2. 浏览器的性能与组成
2.1 浏览器内核
Trident
(三叉戟):IE、360 平安浏览器、UC 浏览器Gecko
(壁虎):Mozilla FirefoxPresto
(急板乐曲)-> Blink(眨眼):OperaWebkit
:Safari、360 极速浏览器、搜狗高速浏览器、挪动端浏览器(Android、iOS)Webkit
->Blink
:Google Chrome,Edge
浏览器的内核相当于汽车的发动机,是最外围的存在,它负责将代码转换成用户眼中的界面。
咱们常常说的浏览器内核指的是浏览器的排版引擎:
- 排版引擎 (layout engine),也称为浏览器引擎 (browser engine)、页面渲染引擎 (rendering engine) 或样版引擎;
- 也就是一个网页下载下来后,就是由咱们的渲染引擎来帮忙咱们解析的;
2.2 过程与线程
过程与线程的解释:
- 过程:程序的一次执行,它占有一片独有的内存空间,是操作系统执行的根本单元;
- 线程:是过程内的一个独立执行单元,是 CPU 调度的最小单元;
浏览器:多过程、多线程模型
Browser
过程:- 浏览器的主过程,负责浏览器界面的显示,和各个页面的治理;
- 浏览器中所有其余类型过程的先人,负责其余过程的的创立和销毁,它有且只有一个!
Renderer
过程:- 网页渲染过程,负责页面的渲染,能够有多个渲染过程的数量,不肯定是关上页面的数量;
GPU Process
:负责 GPU 相干;Plugin Process
:负责管制一个网页用到的Plugin
;
3. 浏览器渲染流程
3.1 渲染引擎解析过程
渲染引擎在拿到一个页面后,如何解析整个页面并且最终呈现出咱们的网页呢?
- 咱们通过上面的这幅图,让咱们更加具体的学习它的过程;
3.2 渲染引擎次要模块
一个渲染引擎次要包含:
HTML
解析器,CSS
解析器,javascript
引擎,布局layout
模块,绘图模块;HTML
解析器:解释 HTML 文档的解析器,次要作用是将 HTML 文本解释成 DOM 树;CSS
解析器:它的作用是为 DOM 中的各个元素对象计算出款式信息,为布局提供基础设施;Javascript
引擎:应用 Javascript 代码能够批改网页的内容,也能批改 css 的信息,javascript 引擎可能解释 javascript 代码,并通过 DOM 接口和 CSS 树接口来批改网页内容和款式信息,从而扭转渲染的后果- 布局 (
layout
):在 DOM 创立之后,Webkit 须要将其中的元素对象同样式信息联合起来,计算他们的大小地位等布局信息,造成一个能表白这所有信息的外部示意模型 - 绘图模块 (
paint
):应用图形库将布局计算后的各个网页的节点绘制成图像后果
4. 渲染页面的具体流程
浏览器渲染页面的整个过程:浏览器会从上到下解析文档。
4.1 HTML 解析过程
遇见
HTML
标记,调用HTML
解析器解析为对应的token
(一个token
就是一个标签文本的序列化)并构建DOM
树(就是一块内存,保留着tokens
,建设它们之间的关系)
4.2 生成 CSS 规定
遇见
style/link
标记调用解析器解决CSS
标记并构建CSS
款式树。
4.3 构建 Render Tree
当有了
DOM Tree
和CSSOM Tree
后,就能够两个联合来构建Render Tree
了
留神一:
link
元素不会阻塞DOM Tree
的构建过程,然而会阻塞Render Tree
的构建过程- 这是因为
Render Tree
在构建时,须要对应的CSSOM Tree
;
- 这是因为
留神二:
Render Tree
和DOM Tree
并不是一一对应的关系- 比方对于
display
为none
的元素,压根不会呈现在render tree
中;
- 比方对于
4.4 布局 (layout) 和绘制 (Paint)
第四步是:在渲染树(Render Tree)上运行 布局(Layout) 来计算每个节点的几何体。
- 渲染树会示意显示哪些节点以及其余款式,然而不示意每个节点的尺寸、地位等信息;
- 布局是确定出现树中所有节点的宽度、高度和地位信息;
第五步是:将每个节点绘制(Paint)到屏幕上。
- 在绘制阶段,浏览器将布局阶段计算的每个 frame 转为屏幕上理论的像素点;
- 包含将元素的可见局部进行绘制,比方文本、色彩、边框、暗影、替换元素(比方 img)
5. 重绘和回流解析
5.1 重绘(Repaint)
第一次渲染内容称之为绘制(paint)
- 之后从新渲染称之为重绘
重绘不会带来从新布局,所以并不一定随同重排。
- 浏览器会依据元素的新属性从新绘制,使元素出现新的外观。
什么属性会导致重绘呢?
color background box-shadow..
(比方批改背景色、文字色彩、边框色彩、款式等)
5.2 回流 / 重排(reflow)
了解回流 reflow
:也能够称之为重排
第一次确定节点的大小和地位,称之为布局(layout)
- 之后对节点的大小、地位批改从新计算称之为回流
“ 重排 / 回流 ” 必然导致 ” 重绘 ”
- 比方扭转一个网页元素的地位,就会同时触发 ” 重排 ” 和 ” 重绘 ”,因为布局扭转了
- 所以 回流是一件很耗费性能的事件
什么属性会导致回流呢?
width top position..
(比方 DOM 构造产生扭转 / 批改了布局)
5.3 常见的触发 ” 回流 / 重排 ” 操作
- Reflow 的老本比 Repaint 的老本高得多的多。
所以在开发中要尽量避免产生回流:
批改款式时尽量一次性批改
- 将屡次 扭转款式属性的操作合并成一次操作
- 事后定义好 class,而后批改 DOM 的 className
尽量避免频繁的操作
DOM
- 咱们能够在一个
DocumentFragment
或者父元素中将要操作的DOM
操作实现,再一次性的操作;
- 咱们能够在一个
- 尽量避免通过
getComputedStyle
获取尺寸、地位等信息; 对某些元素应用
position
的absolute
或者fixed
- 并不是不会引起回流,而是开销绝对较小,不会对其余元素造成影响。
5.4 合成和性能优化
绘制的过程,能够将布局后的元素绘制到多个合成图层中
- 这是浏览器的一种优化伎俩
- 默认状况下,规范流中的内容都是被绘制在同一个图层(Layer)中的
而一些非凡的属性,会创立一个新的合成层(CompositingLayer),并且新的图层能够利用 GPU 来减速绘制
- 因为 每个合成层都是独自渲染 的
那么哪些属性能够造成新的合成层呢? 常见的一些属性:
- 3D transforms
- video、canvas、iframe
- opacity 动画转换时
- position: fixed
- will-change:一个实验性的属性,提前通知浏览器元素可能产生哪些变动
- animation 或 transition 设置了 opacity、transform
- 分层的确能够进步性能,然而它以内存治理为代价,因而不应作为 web 性能优化策略的一部分适度应用
5.5 script 元素和页面解析的关系
咱们当初曾经晓得了页面的渲染过程,然而
JavaScript
在哪里呢?- 事实上,浏览器在解析
HTML
的过程中,遇到了script
元素是不能持续构建DOM
树的; - 它会进行持续构建,首先下载
JavaScript
代码,并且执行JavaScript
的脚本; - 只有等到
JavaScript
脚本执行完结后,才会持续解析HTML
,构建DOM
树;
- 事实上,浏览器在解析
为什么要这样做呢?
- 这是因为
JavaScript
的作用之一就是操作DOM
,并且能够批改DOM
; - 如果咱们等到
DOM
树构建实现并且渲染再执行JavaScript
,会造成重大的回流和重绘,影响页面的性能; - 所以会在遇到
script
元素时,优先下载和执行JavaScript
代码,再持续构建DOM
树;
- 这是因为
然而这个也往往会带来新的问题,特地是古代页面开发中:
- 在目前的开发模式中(比方
Vue
、React
),脚本往往比HTML
页面更“重”,解决工夫须要更长; - 所以会造成页面的解析阻塞,在脚本下载、执行实现之前,用户在界面上什么都看不到;
- 在目前的开发模式中(比方
- 为了解决这个问题,
script
元素给咱们提供了两个属性(attribute
):defer
和async
。
6. defer 和 async 属性
6.1 defer 属性
defer
属性:通知浏览器 不要期待脚本下载 ,而 持续解析 HTML,构建 DOM Tree。- 脚本会由浏览器来进行下载,然而不会阻塞
DOM Tree
的构建过程; - 如果脚本提前下载好了,它会期待 DOM Tree 构建实现,在 DOMContentLoaded 事件之前先执行 defer 中的代码;
- 脚本会由浏览器来进行下载,然而不会阻塞
- 所以 DOMContentLoaded 总是会期待 defer 中的代码先执行实现。
另外多个带
defer
的脚本是能够放弃正确的程序执行的。- 从某种角度来说,
defer
能够进步页面的性能,并且举荐放到head
元素中; - 留神:
defer
仅实用于内部脚本,对于script
默认内容会被疏忽。
- 从某种角度来说,
6.2 async 属性
sync
个性与defer
有些相似,它也可能让脚本不阻塞页面。async 是让一个脚本齐全独立的:
- 浏览器不会因
async
脚本而阻塞(与defer
相似); async
脚本不能保障程序,它是独立下载、独立运行,不会期待其余脚本;- async 不会能保障在 DOMContentLoaded 之前或者之后执行
- 浏览器不会因
defer
通常用于须要在文档解析后操作 DOM 的 JavaScript 代码,并且对多个 script 文件有程序要求的;async
通常用于独立的脚本,对其余脚本,甚至 DOM 没有依赖的;