浏览器底层渲染机制（笔记）

浏览器底层渲染机制
从服务器获取的是文件流（进制编码内容）
1.浏览器首先把16进制的字符信息编译为"代码字符串"
2.按照W3c规则进行字符解析，生成对应的Tokens,最后转化为浏览器内部可以识别渲染的DOM节点
3.按照节点最后解析为对应的树DOM-TREE/CSS-TREE
进程是一个应用程序，一个进程中可能包含多个线程。一个线程同时只能干一件事情，浏览器渲染页面的叫做GUI线程，请求资源就是HTTP线程，浏览器是多线程的。link和import(从服务器获取我们的样式文件)的区别：浏览器资源请求并发6-7个
1.遇到link 浏览器会派发一个新的线程 HTTP线程去加载资源文件，与此同时GUI线程会继续向下渲染代码（不论CSS是否请求回来，代码继续渲染）２.遇到＠import时候会停止GUI，直到资源文件请求回来再继续执行GUI
３.如果是style，GUI直接执行

页面渲染第一步　：在ｃｓｓ资源还没有请求回来之前，先生成DOM树（DOM层级关系／节点关系）
页面渲染第二步：当所有的CSS请求回来之后，浏览器按照CSS导入顺序，依次进行渲染，最后生成CSSOM树
页面渲染第三步：把DOM树和CSSOM树结合到一起，生成有样式有结构的RENDER-TREE渲染树最后浏览器按照渲染树在页面进行渲染和解析
1）计算元素在设备视口中的大小和位置 布局/回流
2）根据渲染树以及回流得到的几何信息，得到节点的绝对像素 重绘

性能优化(CRP性能节点优化)
1.减少DOM树渲染时间（THML层级不要太深，标签语义化）
2.减少CSSOM树渲染时间（选择器是从右向左解析，尽可能减少选择器的层级【less／sass的层级嵌套虽然好用，但是性能会不好】）
3.减少HTTP的请求次数和请求大小
４.一般会把CSS放到CSS页面开始的位置（对于移动端来讲，如果CSS比较少，尽可能使用内嵌样式）
５.为了避免白屏，可以进来第一件事情，快速生成一套Lodging的渲染树（前端骨架屏）；服务器的SSR骨架屏所提高的渲染是避免了客户端再次单独请求数据，而不是样式和结构的；
6.正常情况下JS也会阻碍GUI的渲染，所以一般放在底部，确保DOM生成完才去加载JS，使用async和defer异步去管控js 请求defer等待所有的JS加载完，根据顺序去分别渲染JS（JS中有相互依赖的必须用defer）
<link href='xxx.css'><style> </style> //此段代码要等 Link请求完，即使下面的是内嵌样式。才能让下面生成CSSOMtree 、DOM TREE
=>遇到JS都是先把JS执行的，
按照指定的顺序依次渲染CSS代码 CSSOM树RENDER TREE
LAOUT 计算元素在页面中的位置和大小
PATING 按照计算的结果进行绘制【分图层绘制】
defer async
defer 遇到 script defer：GUI继续渲染，同时HTTP去请求，请求回来也不会立即执行，而是等到GUI渲染完，再去按照之前引入的SCRIPT顺序 依次去执行 （依赖顺序的）
ASYNC ： GUI继续，HTTP请求，当请求回来后，立即执行JS（GUI暂停），JS执行完GUI继续 谁先回来谁执行（没有依赖顺序）

理论上 只有 DOM TREE +CSSOM TREE =>RENDER TREE LAYOUT PATING 页面才会呈现出内容
真实情况下 如果一个CSS资源请求时间过长，浏览器也不等了，自己先把渲染好的 呈现处理