互联网是如何运作的！
基本过程
- 通过过DNS查询找到对应的IP地址
- TCP3次握手建立连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP 响应
- 浏览器解析渲染页面
- 断开结束。
知识点补充
浏览器渲染过程
当渲染首屏时浏览器分别解析 HTML 与 CSS 文件，生成文档对象模型（DOM）与 CSS 对象模型（CSSOM）；合并 DOM 与 CSSOM 成为渲染树（Render Tree）；计算样式（ Style）；计算每个节点在屏幕中的精确位置与大小（Layout）；将渲染树按照上一步计算出的位置绘制到图层上（Paint）；渲染引擎合成所有图层最终人眼可见（Composite Layers）。
Composite Layers：chrome渲染引擎合成的图像层
如果改变页面布局，则是先通过 JS 更新 DOM 再经历计算样式到合成图像这个过程。如果仅仅是非几何变化（颜色、visibility、transform），则可以跳过布局步骤。
概念解释：
性能优化
- 看
webpack打包的依赖分析图 - 看
lighthouse给出的Opportunities和Diagnostics - 看
performance性能面板 - 看
memory分析内存等
重排与重绘
简而言之
- 重排包括Recalculate Style、Layout、Update Layer Tree 等渲染类型事件
- 重绘步骤包括 Paint 和 Composite。
由于计算布局需要大量时间，重排的开销远大于重绘，在达到相同效果的情况下，我们需要尽量避免重排。
- 举个例子，如果 display: none 和 visibility: hidden 都能满足需求，那么后者更优。\
- 举个案列
在如图动画Demo中，饼图显示动画的绘制过程中渲染（重排）占据的大部分的比重，结合代码我们发现原因：循环中多次在刚给 DOM 更新样式位置后，立即通过 offsetTop 获取 DOM 位置。这样的操作会强制启动重排，因为浏览器并不清楚上一个循环内 DOM 有没有改变位置，必须立即重新布局才能计算 DOM 位置。 针对这个问题，我们的优化方案是将 offsetTop 替换成 style.top，后者虽然取的是上一帧动画的元素位置，但并不影响计算下一帧动画位置，省去了重排获取位置的过程，减少了不必要的重排。
我们对比一下优化前后的报告：
常用解决方法：
改写成transform- *
requestanimationframe()可参考requestanimationframe
减少http请求
名词解释：
- Queueing: 在请求队列中的时间。
- Stalled: 从TCP 连接建立完成，到真正可以传输数据之间的时间差，此时间包括代理协商时间。
- Proxy negotiation: 与代理服务器连接进行协商所花费的时间。
- DNS Lookup: 执行DNS查找所花费的时间，页面上的每个不同的域都需要进行DNS查找。
- Initial Connection / Connecting: 建立连接所花费的时间，包括TCP握手/重试和协商SSL。
- SSL: 完成SSL握手所花费的时间。
- Request sent: 发出网络请求所花费的时间，通常为一毫秒的时间。
- Waiting(TFFB): TFFB 是发出页面请求到接收到应答数据第一个字节的时间。
- Content Download: 接收响应数据所花费的时间。
从这个例子可以看出，真正下载数据的时间占比为 13.05 / 204.16 = 6.39%，文件越小，这个比例越小，文件越大，比例就越高。这就是为什么要建议将多个小文件合并为一个大文件，从而减少 HTTP 请求次数的原因。
为静态资源提供缓存
对于不常改变的静态资源比如说css、image等可以进行缓存，打开ngnix配置文件，把缓存配上（这里粗暴把js和css缓存了，实际项目根据实际需要配置缓存）
避免大量的网络负载
Avoid enormous network payloads
- 预加载&&延迟加载
- base64图片
- 图片压缩
