网页的解析过程

◼ 一个网页URL从输入到浏览器中，到显示经历过怎么样的解析过程呢？
image.png
要想深入理解下载的过程，我们还要先理解，一个index.html被下载下来后是如何被解析和显示在浏览器上的.

浏览器内核

◼ 常见的浏览器内核有

  • Trident （ 三叉戟）：IE、360安全浏览器、搜狗高速浏览器、百度浏览器、UC浏览器；
  • Gecko（ 壁虎） ：Mozilla Firefox；
  • Presto（急板乐曲）-> Blink （眨眼）：Opera
  • Webkit ：Safari、360极速浏览器、搜狗高速浏览器、移动端浏览器（Android、iOS）
  • Webkit -> Blink ：Google Chrome，Edge

image.png
◼ 我们经常说的浏览器内核指的是浏览器的排版引擎：

  • 排版引擎（layout engine），也称为浏览器引擎（browser engine）、页面渲染引擎（rendering engine）或样版引擎。

◼ 也就是一个网页下载下来后，就是由我们的渲染引擎来帮助我们解析的。

浏览器渲染过程

◼ 渲染引擎在拿到一个页面后，如何解析整个页面并且最终呈现出我们的网页呢？

  • 我们之前学习过下面的这幅图，现在让我们更加详细的学习它的过程；

image.png
更详细的解析过程如下：
image.png
图片出处

解析一：HTML解析过程

◼ 因为默认情况下服务器会给浏览器返回index.html文件，所以解析HTML是所有步骤的开始：
◼ 解析HTML，会构建DOM Tree：
image.png

解析二：生成CSS规则

◼ 在解析的过程中，如果遇到CSS的link元素，那么会由浏览器负责下载对应的CSS文件：

  • 注意：下载CSS文件是不会影响DOM的解析的；

◼ 浏览器下载完CSS文件后，就会对CSS文件进行解析，解析出对应的规则树：

  • 我们可以称之为 CSSOM（CSS Object Model，CSS对象模型）；

image.png

解析三：构建Render Tree

◼ 当有了DOM Tree和 CSSOM Tree后，就可以两个结合来构建Render Tree了
image.png
◼ 注意一：link元素不会阻塞DOM Tree的构建过程，但是会阻塞Render Tree的构建过程

  • 这是因为Render Tree在构建时，需要对应的CSSOM Tree；

◼ 注意二：Render Tree和DOM Tree并不是一一对应的关系，比如对于display为none的元素，压根不会出现在render tree中；

解析四：布局（layout）和绘制（paint）

◼ 第四步是在渲染树（Render Tree）上运行布局（Layout）以计算每个节点的几何体。

  • 渲染树会表示显示哪些节点以及其他样式，但是不表示每个节点的尺寸、位置等信息；
  • 布局是确定呈现树中所有节点的宽度、高度和位置信息；

◼ 第五步是将每个节点绘制（Paint）到屏幕上

  • 在绘制阶段，浏览器将布局阶段计算的每个frame转为屏幕上实际的像素点；
  • 包括将元素的可见部分进行绘制，比如文本、颜色、边框、阴影、替换元素（比如img）

image.png

回流和重绘解析

◼ 理解回流reflow：（也可以称之为重排）

  • 第一次确定节点的大小和位置，称之为布局（layout）。
  • 之后对节点的大小、位置修改重新计算称之为回流。

◼ 什么情况下引起回流呢？

  • 比如DOM结构发生改变（添加新的节点或者移除节点）；
  • 比如改变了布局（修改了width、height、padding、font-size等值）
  • 比如窗口resize（修改了窗口的尺寸等）
  • 比如调用getComputedStyle方法获取尺寸、位置信息；

◼ 理解重绘repaint：

  • 第一次渲染内容称之为绘制（paint）。
  • 之后重新渲染称之为重绘。

◼ 什么情况下会引起重绘呢？

  • 比如修改背景色、文字颜色、边框颜色、样式等；

◼ 回流一定会引起重绘，所以回流是一件很消耗性能的 事情。
◼ 所以在开发中要尽量避免发生回流：
◼ 1.修改样式时尽量一次性修改

  • 比如通过cssText修改，比如通过添加class修改

◼ 2.尽量避免频繁的操作DOM

  • 我们可以在一个DocumentFragment或者父元素中 将要操作的DOM操作完成，再一次性的操作；

◼ 3.尽量避免通过getComputedStyle获取尺寸、位置等信息；
◼ 4.对某些元素使用position的absolute或者fixed

  • 并不是不会引起回流，而是开销相对较小，不会对 其他元素造成影响。

    合成（composite）和性能优化

    ◼ 绘制的过程，可以将布局后的元素绘制到多个合成图层中。

  • 这是浏览器的一种优化手段；

◼ 默认情况下，标准流中的内容都是被绘制在同一个图层（Layer）中的；
◼ 而一些特殊的属性，会创建一个新的合成层（ CompositingLayer ），并且新的图层可以利用GPU来加速绘制；

  • 因为每个合成层都是单独渲染的；

◼ 那么哪些属性可以形成新的合成层呢？常见的一些属性：

  • 3D transforms
  • video、canvas、iframe
  • opacity 动画转换时；
  • position: fixed
  • will-change：一个实验性的属性，提前告诉浏览器元素可能发生哪些变化；
  • animation 或 transition 设置了opacity、transform；

◼ 分层确实可以提高性能，但是它以内存管理为代价，因此不应作为 web 性能优化策略的一部分过度使用。
image.png

script标签的defer和async属性

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。

defer属性

◼ defer 属性告诉浏览器不要等待脚本下载，而继续解析HTML，构建DOM Tree。

  • 脚本会由浏览器来进行下载，但是不会阻塞DOM Tree的构建过程；
  • 如果脚本提前下载好了，它会等待DOM Tree构建完成，在DOMContentLoaded事件之前先执行defer中的代码；

◼ 所以DOMContentLoaded总是会等待defer中的代码先执行完成。
image.png
◼ 另外多个带defer的脚本是可以保持正确的顺序执行的。
◼ 从某种角度来说，defer可以提高页面的性能，并且推荐放到head元素中；
◼ 注意：defer仅适用于外部脚本，对于script默认内容会被忽略。

async属性

◼ async 特性与 defer 有些类似，它也能够让脚本不阻塞页面。
◼ async是让一个脚本完全独立的：

  • 浏览器不会因 async 脚本而阻塞（与 defer 类似）；
  • async脚本不能保证顺序，它是独立下载、独立运行，不会等待其他脚本；
  • async不会能保证在DOMContentLoaded之前或者之后执行；

image.png
◼ defer通常用于需要在文档解析后操作DOM的JavaScript代码，并且对多个script文件有顺序要求的；
◼ async通常用于独立的脚本，对其他脚本，甚至DOM没有依赖的；

作业与总结

一.说出浏览器输入一个URL到页面显示的过程

  • 首先通过DNS服务器进行域名解析
  • 解析出对应的IP地址 然后从ip地址对应的主机发送http请求 获取对应的静态资源
  • 默认情况服务器会返回index.html文件
  • 然后浏览器内核开始解析HTML
  • 首先 会解析对应的html 生成DOM Tree
  • 解析过程中 如果遇到css的link标签 则会下载对应的css文件
    • 下载css文件和生成DOM树是同时进行
  • 下载完对应的css文件后会进行css解析 生成CSSOM( CSS object model)
  • 当DOM Tree和CSSTree都解析完成之后 会进行合并用来生成Render Tree(渲染树)
  • 初步生成的渲染树会显示节点以及部分样式 但是并不表示每个节点的尺寸 位置信息 于是进行Layout(布局)来生成渲染树中节点的宽度 高度位置信息
  • 经过Layout之后 浏览器内核将布局时的每个frame转屏幕上的每个像素点 将每个节点绘制到屏幕上

注意: 第一次确定节点的大小位置 称之为布局(Layout) 之后对节点大小位置改变后的重新计算称之为回流

引起回流的情况:

  • DOM结构发生改变(节点的增删)
  • 修改了节点的布局(宽度 高度 字体大小等)
  • 修改窗口的尺寸
  • 调用getComputedStyle获取位置信息

第一次绘制节点 渲染到页面上称之为绘制(paint) 之后重新绘制 称之为重绘

引起重绘情况:

  • 修改背景色颜色 等

回流一定会引起重绘 所以回流非常消耗性能

如何避免回流

  • 尽量一次性的修改样式
    • 通过添加classList
  • 避免频繁的操作DOM
  • 避免通过getComputedStyle获取尺寸位置信息等
  • 对于某些元素使用position:absolute/fixed
    • 开销较小 不会对其他元素造成影响

      二.说说async和defer的使用以及区别

      为了防止js文件过大而导致加载过久影响网页的加载，script标签可以添加defer和async属性，两个属性能异步加载js文件，两者不同的是，下载完成之后，defer是在DOMContentLoaded事件之前按照顺序执行代码，而async不能保证在DOMContentLoaded之前或之后执行，执行顺序是不可控的。

      适当的使用defer可以提高页面加载速度（优化手段）

三. 写出v8引擎执行代码的大致流程(了解)

  • Parse模块 将JavaScript代码转成AST Tree
  • Ignition :解释器 将ASTTree 转换为字节码(byte Code)
    • 同时收集TurboFan 优化需要的信息
  • TurboFan :编译器 将字节码编译为CPU可以直接执行的机器码(machine code)
    • 如果某一个函数呗被多次调用 则会被标记为热点函数 会经过TurBoFan转换的优化的机器码 让CPU执行 提高代码性能
    • 如果后续执行代码过程中 改函数调用时的参数类型发生了改变 则会逆向的转成字节码 让CPU执行

执行流程:

  • 首先会编译JavaScript 编译过程分为三步
  • 1 词法分析(scanner)
    • 会将对应的每一行的代码的字节流分解成有意义的代码块 代码块被称为词法单元(token 进行记号化)
  • 2 语法分析(parser)
    • 将对应的tokens分析成一个元素逐级嵌套的树 这个树称之为 抽象语法树(Abstract Syntax Tree AST)
    • 这里也有对应的 pre-parser
  • 3 将AST 通过Ignition解释器转换成对应的字节码(ByteCode) 交给CPU执行 同时收集信息
    • 将可优化的信息 通过TurBoFan编译器 编译成更好使用的机器码交给CPU执行
    • 如果后续代码的参数类型发生改变 则会逆优化(Deoptimization)为字节码