浏览器主要组成与浏览器线程

1 浏览器进程和线程

浏览器的主要进程包括浏览器browser进程、渲染进程、GPU进程等。

Browser进程：浏览器的主进程（负责协调、主控），只有一个
浏览器渲染进程（内核）：默认每个Tab页面一个渲染进程，互不影响，控制页面渲染，脚本执行，事件处理等（有时候会优化，如多个空白tab会合并成一个进程）。该进程内分为GUI渲染线程、JS引擎线程等，GUI渲染线程负责渲染浏览器界面HTML元素,当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时，该线程就会执行。在Javascript引擎运行脚本期间,GUI渲染线程都是处于挂起状态的，也就是说被冻结了。
GPU进程：最多一个，用于3D绘制

2 常见的渲染模式 csr/ssr

前序：简述SEO SEO(Search Engine Optimization)是指搜索引擎优化，通俗说就是总结搜索引擎的检索排名规则，合理的优化网站，使得你的网站在百度或者谷歌这样的搜索引擎中的排名进步，让更多的用户能够访问到你的网站。

客户端渲染csr 客户端渲染（Client Side Render）,就是用户在通过URL请求访问网站时，服务器端返回给的是html文档，再让浏览器去解析渲染展示页面，其中的js，css,图片文件等均需再次发送请求去服务端请求数据加载。

在这里插入图片描述

服务端渲染ssr 与客户端渲染相对应的就是服务器端渲染(SSR)，在服务端看来，所有的前端渲染显示页面都是一串字符串，包括html, js, css都是如此，服务端渲染即是将一段处理好后的html字符串返回给客户端，而在返回的这个html字符串中，服务端只是将需要展示到html的服务端数据等信息直接写入到了这段html字符串中让客户端浏览器能够直接对其进行显示，这样客户端不用再去多次不断的请求服务端加载数据了。

在这里插入图片描述

服务端渲染 VS 客户端渲染 CSR和SSR最大的区别在于CSR进行页面的渲染是服务端直接返回HTML给客户端渲染显示，而SSR则是将页面的渲染交给了服务端的JS执行。

传统的CSR的弊端

由于直接返回HTML到客户端进行渲染，客户端需要多次发送AJAX到服务端拉取JS代码执行，导致了页面的首屏加载速度会变慢。
对于SEO是不友好的，因为我们客户端是从服务端拉取JS过来执行的，而搜索引擎的爬虫只能识别html结构的内容，对于js代码则不能够进行识别。

因此SSR的出现就是可以解决了传统CSR存在的这种弊端，因为此时客户端请求拿到的就将是我们服务端渲染好的html,这样对于SEO也足够的友好。

重排(reflow)和重绘(repaint)

页面生成的过程

1.HTML 被 HTML 解析器解析成 DOM 树；

2.CSS 被 CSS 解析器解析成 style 树；

3.结合 DOM 树和 CSSOM 树，生成一棵渲染树 (Render Tree)，这一过程称为 Attachment；

4.生成布局(flow)，浏览器在屏幕上“画”出渲染树中的所有节点；

5.将布局绘制(paint)在屏幕上，显示出整个页面。

第四步和第五步是最耗时的部分，这两步合起来，就是我们通常所说的渲染。

渲染

在页面的生命周期中，网页生成的时候，至少会渲染一次。在用户访问的过程中，还会不断触发重排(reflow)和重绘(repaint) ，不管页面发生了重绘还是重排，都会影响性能，最可怕的是重排，会使我们付出高额的性能代价，所以我们应尽量避免。

重排比重绘代价大：

重绘：某些元素的外观被改变，例如：元素的填充颜色
重排：重新生成布局，重新排列元素。

就如上面的概念一样，单单改变元素的外观，肯定不会引起网页重新生成布局，但当浏览器完成重排之后，将会重新绘制受到此次重排影响的部分。比如改变元素高度，这个元素乃至周边dom都需要重新绘制。

也就是说：重绘不一定导致重排，但重排一定会导致重绘。

重排(reflow)

概念

当DOM的变化影响了元素的几何信息(元素的的位置和尺寸大小)，浏览器需要重新计算元素的几何属性，将其安放在界面中的正确位置，这个过程叫做重排。

重排也叫回流，简单的说就是重新生成布局，重新排列元素。

发生重排的情况

页面初始渲染，这是开销最大的一次重排
添加/删除可见的DOM元素
改变元素位置
改变元素尺寸，比如边距、填充、边框、宽度和高度等
改变元素内容，比如文字数量，图片大小等
改变元素字体大小
改变浏览器窗口尺寸，比如resize事件发生时
激活CSS伪类（例如：:hover）
设置 style 属性的值，因为通过设置style属性改变结点样式的话，每一次设置都会触发一次reflow
查询某些属性或调用某些计算方法：offsetWidth、offsetHeight等，除此之外，当我们调用 getComputedStyle方法，或者IE里的 currentStyle 时，也会触发重排，原理是一样的，都为求一个“即时性”和“准确性”。

常见引起重排属性和方法	--	--	--
width	height	margin	padding
display	border-width	border	position
overflow	font-size	vertical-align	min-height
clientWidth	clientHeight	clientTop	clientLeft
offsetWudth	offsetHeight	offsetTop	offsetLeft
scrollWidth	scrollHeight	scrollTop	scrollLeft
scrollIntoView()	scrollTo()	getComputedStyle()
getBoundingClientRect()	scrollIntoViewIfNeeded()

重排影响的范围

由于浏览器渲染界面是基于流失布局模型的，所以触发重排时会对周围DOM重新排列，影响的范围有两种：

全局范围：从根节点html开始对整个渲染树进行重新布局。
局部范围：对渲染树的某部分或某一个渲染对象进行重新布局

全局范围重排

<body>
  <div class="hello">
    <h4>hello</h4>
    <p><strong>Name:</strong>BDing</p>
    <h5>male</h5>
    <ol>
      <li>coding</li>
      <li>loving</li>
    </ol>
  </div>
</body>
复制代码

当p节点上发生reflow时，hello和body也会重新渲染，甚至h5和ol都会收到影响。

局部范围重排

用局部布局来解释这种现象：把一个dom的宽高之类的几何信息定死，然后在dom内部触发重排，就只会重新渲染该dom内部的元素，而不会影响到外界。

重绘(Repaints)

概念

当一个元素的外观发生改变，但没有改变布局,重新把元素外观绘制出来的过程，叫做重绘。

引起重绘的属性

属性：	--	--	--
color	border-style	visibility	background
text-decoration	background-image	background-position	background-repeat
outline-color	outline	outline-style	border-radius
outline-width	box-shadow	background-size

重排优化建议

重排的代价是高昂的，会破坏用户体验，并且让UI展示非常迟缓。通过减少重排的负面影响来提高用户体验的最简单方式就是尽可能的减少重排次数，重排范围。下面是一些行之有效的建议，大家可以用来参考。

减少重排范围

我们应该尽量以局部布局的形式组织html结构，尽可能小的影响重排的范围。

尽可能在低层级的DOM节点上，而不是像上述全局范围的示例代码一样，如果你要改变p的样式，class就不要加在div上，通过父元素去影响子元素不好。
不要使用 table 布局，可能很小的一个小改动会造成整个 table 的重新布局。那么在不得已使用table的场合，可以设置table-layout:auto;或者是table-layout:fixed这样可以让table一行一行的渲染，这种做法也是为了限制reflow的影响范围。

减少重排次数

1.样式集中改变

不要频繁的操作样式，对于一个静态页面来说，明智且可维护的做法是更改类名而不是修改样式，对于动态改变的样式来说，相较每次微小修改都直接触及元素，更好的办法是统一在 cssText 变量中编辑。虽然现在大部分现代浏览器都会有 Flush 队列进行渲染队列优化，但是有些老版本的浏览器比如IE6的效率依然低下。

// bad
var left = 10;
var top = 10;
el.style.left = left + "px";
el.style.top = top + "px";

// 当top和left的值是动态计算而成时...
// better 
el.style.cssText += "; left: " + left + "px; top: " + top + "px;";

// better
el.className += " className";

复制代码

2.分离读写操作

DOM 的多个读操作（或多个写操作），应该放在一起。不要两个读操作之间，加入一个写操作。

// × 强制刷新 触发四次重排+重绘
div.style.left = div.offsetLeft + 1 + 'px';
div.style.top = div.offsetTop + 1 + 'px';
div.style.right = div.offsetRight + 1 + 'px';
div.style.bottom = div.offsetBottom + 1 + 'px';


// √ 缓存布局信息 相当于读写分离 触发一次重排+重绘
var curLeft = div.offsetLeft;
var curTop = div.offsetTop;
var curRight = div.offsetRight;
var curBottom = div.offsetBottom;

div.style.left = curLeft + 1 + 'px';
div.style.top = curTop + 1 + 'px';
div.style.right = curRight + 1 + 'px';
div.style.bottom = curBottom + 1 + 'px';
复制代码

原来的操作会导致四次重排，读写分离之后实际上只触发了一次重排，这都得益于浏览器的渲染队列机制：

当我们修改了元素的几何属性，导致浏览器触发重排或重绘时。它会把该操作放进渲染队列，等到队列中的操作到了一定的数量或者到了一定的时间间隔时，浏览器就会批量执行这些操作。

3.将 DOM 离线

“离线”意味着不在当前的 DOM 树中做修改，我们可以这样做：

使用 display:none

一旦我们给元素设置 display:none 时（只有一次重排重绘），元素便不会再存在在渲染树中，相当于将其从页面上“拿掉”，我们之后的操作将不会触发重排和重绘，添加足够多的变更后，通过 display属性显示（另一次重排重绘）。通过这种方式即使大量变更也只触发两次重排。另外，visibility : hidden 的元素只对重绘有影响，不影响重排。
通过 documentFragment 创建一个 dom 碎片,在它上面批量操作 dom，操作完成之后，再添加到文档中，这样只会触发一次重排。
复制节点，在副本上工作，然后替换它！

4.使用 absolute 或 fixed 脱离文档流

使用绝对定位会使的该元素单独成为渲染树中 body 的一个子元素，重排开销比较小，不会对其它节点造成太多影响。当你在这些节点上放置这个元素时，一些其它在这个区域内的节点可能需要重绘，但是不需要重排。

5.优化动画

可以把动画效果应用到 position属性为 absolute 或 fixed 的元素上，这样对其他元素影响较小。

动画效果还应牺牲一些平滑，来换取速度，这中间的度自己衡量：比如实现一个动画，以1个像素为单位移动这样最平滑，但是Layout就会过于频繁，大量消耗CPU资源，如果以3个像素为单位移动则会好很多
启用GPU加速 GPU 硬件加速是指应用 GPU 的图形性能对浏览器中的一些图形操作交给 GPU 来完成，因为 GPU 是专门为处理图形而设计，所以它在速度和能耗上更有效率。

GPU 加速通常包括以下几个部分：Canvas2D，布局合成, CSS3转换（transitions），CSS3 3D变换（transforms），WebGL和视频(video)。
```
  /*
  * 根据上面的结论
  * 将 2d transform 换成 3d
  * 就可以强制开启 GPU 加速
  * 提高动画性能
  */
  div {
    transform: translate3d(10px, 10px, 0);
  }
复制代码
```

前端性能优化

前端性能优化指标RAIL

RAIL是一个以用户为中心的性能模型，它把用户的体验拆分成几个关键点（例如，tap，scroll，load），并且帮你定义好了每一个的性能指标。

有以下四个方面：

Response
Animation
Idle
Load

以下是用户对性能延迟的感知：

延迟时间	用户感知
0-16ms	很流畅
0-100ms	基本流畅
100-1000ms	感觉到网站上有一些加载任务
1000ms or more	失去耐心了
10000ms or more	直接离开，不会再访问了

Response: 事件处理最好在50ms内完成

目标

用户的输入到响应的时间不超过100ms，给用户的感受是瞬间就完成了。

优化方案

事件处理函数在50ms内完成，考虑到idle task的情况，事件会排队，等待时间大概在50ms。适用于click，toggle，starting animations等，不适用于drag和scroll。
复杂的js计算尽可能放在后台，如web worker，避免对用户输入造成阻塞
超过50ms的响应，一定要提供反馈，比如倒计时，进度百分比等。

idle task：除了要处理输入事件，浏览器还有其它任务要做，这些任务会占用部分时间，一般情况会花费50ms的时间，输入事件的响应则排在其后。

下图是idle task对input response的影响：

Animation: 在10ms内产生一帧

目标

产生每一帧的时间不要超过10ms，为了保证浏览器60帧，每一帧的时间在16ms左右，但浏览器需要用6ms来渲染每一帧。
旨在视觉上的平滑。用户对帧率变化感知很敏感。

优化方案

在一些高压点上，比如动画，不要去挑战cpu，尽可能地少做事，如：取offset，设置style等操作。尽可能地保证60帧的体验。
在渲染性能上，针对不同的动画做一些特定优化

动画不只是UI的视觉效果，以下行为都属于

视觉动画，如渐隐渐显，tweens，loading等

滚动，包含弹性滚动，松开手指后，滚动会持续一段距离

拖拽，缩放，经常伴随着用户行为

Idle: 最大化利用空闲时间

目标

最大化空闲时间，以增大50ms内响应用户输入的几率

优化方案

用空闲时间来完成一些延后的工作，如先加载页面可见的部分，然后利用空闲时间加载剩余部分，此处可以使用 requestIdleCallback API
在空闲时间内执行的任务尽量控制在50ms以内，如果更长的话，会影响input handle的pending时间
如果用户在空闲时间任务进行时进行交互，必须以此为最高优先级，并暂停空闲时间的任务

Load: 传输内容到页面可交互的时间不超过5秒

如果页面加载比较慢，用户的交点可能会离开。加载很快的页面，用户平均停留时间会变长，跳出率会更低，也就有更高的广告查看率

目标

优化加载速度，可以根据设备、网络等条件。目前，比较好的一个方式是，让你的页面在一个中配的3G网络手机上打开时间不超过5秒
对于第二次打开，尽量不超过2秒

优化方案

在手机设备上测试加载性能，选用中配的3G网络（400kb/s，400ms RTT），可以使用 WebPageTest 来测试
要注意的是，即使用户的网络是4G，但因为丢包或者网络波动，可能会比预期的更慢
禁用渲染阻塞的资源，延后加载
可以采用 lazy load，code-splitting 等其他优化手段，让第一次加载的资源更少

分析RAIL用的工具

加载时的优化

第一点：减少HTTP请求

一个完整的 HTTP 请求需要经历 DNS 查找，TCP 握手，浏览器发出 HTTP 请求，服务器接收请求，服务器处理请求并发回响应，浏览器接收响应等等一系列复杂的过程。当你请求较多时，直接体现在了消耗性能上面，这就是为什么要将多个小文件合并为一个大文件，从而减少 HTTP 请求次数的原因。

第二点：使用服务器端渲染

我们知道，当客户端渲染时，他是获取 HTML 文件，根据需要下载 JavaScript 文件，运行文件，生成 DOM，再渲染。这个在无形之中会拖慢我们的性能

那么服务器端渲染又是怎么一回事呢？他就是，服务端返回 HTML 文件，客户端只需解析 HTML即可。

第三点：静态资源使用 CDN

什么是CDN，CDN就是，内容分发网络，它是一组分布在多个不同地理位置的 Web 服务器。我们都知道，当服务器离用户越远时，延迟越高。CDN 就是为了解决这一问题，在多个位置部署服务器，让用户离服务器更近，从而缩短请求时间。

CDN* 原理：*

当用户访问一个网站时，如果没有 CDN，过程是这样的：

1.浏览器要将域名解析为 IP 地址，所以需要向本地 DNS 发出请求。

2.本地 DNS 依次向根服务器、顶级域名服务器、权限服务器发出请求，得到网站服务器的 IP 地址。

3.本地 DNS 将 IP 地址发回给浏览器，浏览器向网站服务器 IP 地址发出请求并得到资源。

如果用户访问的网站部署了 CDN，过程是这样的：

1.浏览器要将域名解析为 IP 地址，所以需要向本地 DNS 发出请求。

2.本地 DNS 依次向根服务器、顶级域名服务器、权限服务器发出请求，得到全局负载均衡系统（GSLB）的 IP 地址。

3.本地 DNS 再向 GSLB 发出请求，GSLB 的主要功能是根据本地 DNS 的 IP 地址判断用户的位置，筛选出距离用户较近的本地负载均衡系统（SLB），并将该 SLB 的 IP 地址作为结果返回给本地 DNS。

4.本地 DNS 将 SLB 的 IP 地址发回给浏览器，浏览器向 SLB 发出请求。

5.SLB 根据浏览器请求的资源和地址，选出最优的缓存服务器发回给浏览器。

6.浏览器再根据 SLB 发回的地址重定向到缓存服务器。

7.如果缓存服务器有浏览器需要的资源，就将资源发回给浏览器。如果没有，就向源服务器请求资源，再发给浏览器并缓存在本地。

第四点：CSS 写头部，JavaScript 写底部

所有放在 head 标签里的 CSS 和 JS 文件都会堵塞渲染。如果这些 CSS 和 JS 需要加载和解析很久的话，那么页面就空白了。所以 JS 文件要放在底部，等 HTML 解析完了再加载 JS 文件。

那为什么 CSS 文件还要放在头部呢？

因为先加载 HTML 再加载 CSS，会让用户第一时间看到的页面是没有样式的、“丑陋”的，为了避免这种情况发生，就要将 CSS 文件放在头部了。

另外，JS 文件也不是不可以放在头部，只要给 script 标签加上 defer 属性或async属性就可以了。

defer

这个属性的用途是表明脚本在执行时不会影响页面的构造。也就是说，脚本会被延迟到整个页面都解析完毕后再运行。因此，在<script>元素中设置defer属性，相当于告诉浏览器立即异步下载，但延迟执行。

HTML5规范要求脚本按照它们出现的先后顺序执行，因此第一个延迟脚本会先于第二个延迟脚本执行，而这两个脚本会先于DOMContentLoaded事件执行。在现实当中，延迟脚本并不一定会按照顺序执行，也不一定会在DOMContentLoad时间触发前执行，因此最好只包含一个延迟脚本。

async

这个属性与defer类似，都用于改变处理脚本的行为。同样与defer类似，async只适用于外部脚本文件，并告诉浏览器立即异步下载文件。但与defer不同的是，下载完成后即会立即执行。

第二个脚本文件可能会在第一个脚本文件之前执行。因此确保两者之间互不依赖非常重要。指定async属性的目的是不让页面等待两个脚本下载和执行，从而异步加载页面其他内容。

概括来讲，就是这两个属性都会使script标签异步加载，然而执行的时机是不一样的。图片描述蓝色线代表网络读取，红色线代表执行时间，这俩都是针对脚本的；绿色线代表 HTML 解析。

当script同时有async和defer属性时，执行效果和async一致。

也就是说async是乱序的，而defer是顺序执行，这也就决定了async比较适用于百度分析或者谷歌分析这类不依赖其他脚本的库。从图中可以看到一个普通的<script>标签的加载和解析都是同步的，会阻塞DOM的渲染，这也就是我们经常会把<script>写在<body>底部的原因之一，为了防止加载资源而导致的长时间的白屏，另一个原因是js可能会进行DOM操作，所以要在DOM全部渲染完后再执行。

第五点：字体图标代替图片图标

字体图标就是将图标制作成一个字体，使用时就跟字体一样，可以设置属性，例如 font-size、color 等等，非常方便。并且字体图标是矢量图，不会失真。还有一个优点是生成的文件特别小。

第六点：利用缓存不重复加载相同的资源

为了避免用户每次访问网站都得请求文件，我们可以通过添加 Expires 来控制这一行为。Expires 设置了一个时间，只要在这个时间之前，浏览器都不会请求文件，而是直接使用缓存。

第七点：图片优化

图片延迟加载；就是在页面中，先不给图片设置路径，只有当图片出现在浏览器的可视区域时，才去加载真正的图片，这就是延迟加载。对于图片很多的网站来说，一次性加载全部图片，会对用户体验造成很大的影响，所以需要使用图片延迟加载。
降低图片质量；图片100% 的质量和 90% 的质量通常看不出来区别，尤其是用来当背景图的时候。我们可以在用 PS 切背景图时，将图片切成 JPG 格式，并且将它压缩到 60% 的质量，这样基本看不出来区别。
尽可能利用 CSS3 效果代替图片；有很多图片使用 CSS 效果（渐变、阴影等）就能画出来，这种情况选择 CSS3 效果更好。因为代码大小通常是图片大小的几分之一甚至几十分之一。
雪碧图。将多张图片合并到一张图片后，只需一次网络请求就可以将所需的资源全部下载，减小建立连接的消耗。

第八点：通过 webpack 按需加载代码

懒加载或者按需加载，是一种很好的优化网页或应用的方式。这种方式实际上是先把你的代码在一些逻辑断点处分离开，然后在一些代码块中完成某些操作后，立即引用或即将引用另外一些新的代码块。这样加快了应用的初始加载速度，减轻了它的总体体积，因为某些代码块可能永远不会被加载。

运行时的优化

第一点：减少重绘重排

用 JavaScript 修改样式时，最好不要直接写样式，而是替换 class 来改变样式。再一个就是，如果要对 DOM 元素执行一系列操作，可以将 DOM 元素脱离文档流，修改完成后，再将它带回文档。推荐使用隐藏元素（display:none）或文档碎片，都能很好的实现这个方案。

第二点：使用事件委托

事件委托利用了事件冒泡，只指定一个事件处理程序，就可以管理某一类型的所有事件。所有用到按钮的事件（多数鼠标事件和键盘事件）都适合采用事件委托技术，使用事件委托可以节省内存。

第三点：if-else 对比 switch

当判断条件数量越来越多时，越倾向于使用 switch 而不是 if-else。不过，switch 只能用于 case 值为常量的分支结构，而 if-else 更加灵活。

第四点：不要覆盖原生方法

无论你的 JavaScript 代码如何优化，都比不上原生方法。因为原生方法是用低级语言写的，并且被编译成机器码，成为浏览器的一部分。当原生方法可用时，尽量使用它们，特别是数学运算和 DOM 操作。

第五点：降低CSS 选择器的复杂性

浏览器读取选择器，遵循的原则是从选择器的右边到左边读取。所以，尽可能的降低CSS 选择器的复杂性

第六点：使用 flexbox 布局

在早期的 CSS 布局方式中我们能对元素实行绝对定位、相对定位或浮动定位。而现在，我们有了 flexbo布局方式，它比起早期的布局方式来说更有优势，那就是性能比较好。不过 flexbox 兼容性还是有点问题，不是所有浏览器都支持它，所以要谨慎使用。

第七点：用 transform 和 opacity 属性更改来实现动画

在 CSS 中，transforms 和 opacity 这两个属性更改不会触发重排与重绘，它们是可以由合成器单独处理的属性。

如何在浏览器中查看页面渲染时间

1.打开开发者工具：点击 Performance 左侧有个小圆点点击刷新页面会录制整个页面加载出来时间的分配情况。如下图

蓝色: 网络通信和HTML解析
黄色: JavaScript执行
紫色: 样式计算和布局，即重排
绿色: 重绘

哪种色块比较多，就说明性能耗费在那里。色块越长，问题越大。

2.点击 Event Log：单独勾选 Loading 项会显示 html 和 css 加载时间。如下图：

3.解析完 DOM+CSSOM 之后会生成一个渲染树 Render Tree，就是 DOM 和 CSSOM 的一一对应关系。

4.通过渲染树中在屏幕上“画”出的所有节点，称为渲染。

小结：

渲染的三个阶段 Layout，Paint，Composite Layers。 Layout：重排，又叫回流。 Paint:重绘，重排重绘这些步骤都是在 CPU 中发生的。 Compostite Layers：CPU 把生成的 BitMap（位图）传输到 GPU，渲染到屏幕。
CSS3 就是在 GPU 发生的：Transform Opacity。在 GPU 发生的属性比较高效。所以 CSS3 性能比较高。

一些相当基础的知识-浏览器渲染部分

浏览器主要组成与浏览器线程

1 浏览器进程和线程

2 常见的渲染模式 csr/ssr

重排(reflow)和重绘(repaint)

页面生成的过程

渲染

重排(reflow)

概念

发生重排的情况

重排影响的范围

重绘(Repaints)

概念

引起重绘的属性

重排优化建议

减少重排范围

减少重排次数

1.样式集中改变

2.分离读写操作

3.将 DOM 离线

4.使用 absolute 或 fixed 脱离文档流

5.优化动画

前端性能优化

前端性能优化指标RAIL

Response: 事件处理最好在50ms内完成

Animation: 在10ms内产生一帧

Idle: 最大化利用空闲时间

Load: 传输内容到页面可交互的时间不超过5秒

分析RAIL用的工具

加载时的优化

第一点：减少HTTP请求

第二点：使用服务器端渲染

第三点：静态资源使用 CDN

第四点：CSS 写头部，JavaScript 写底部

defer

async

第五点：字体图标代替图片图标

第六点：利用缓存不重复加载相同的资源

第七点：图片优化

第八点：通过 webpack 按需加载代码

运行时的优化

第一点：减少重绘重排

第二点：使用事件委托

第三点：if-else 对比 switch

第四点：不要覆盖原生方法

第五点：降低CSS 选择器的复杂性

第六点：使用 flexbox 布局

第七点：用 transform 和 opacity 属性更改来实现动画

如何在浏览器中查看页面渲染时间

小结：