71-72：从地址栏输入网址到看到页面的完整步骤（前端性能优化点）

当用户在浏览器地址栏中输入网址，到看到页面，经历的步骤

1.解析输入的URL地址（看上一篇70）

2.DNS解析

网站中，每发送一个TCP请求，都要进行DNS解析（一但当前域名解析过一次，浏览器一般会缓存解析记录，缓存时间一般在1分钟左右，后期发送的请求如果还是这个域名，则跳过解析步骤 =>这是一个性能优化点）

真实项目中，一个大型网站，他要请求的资源是分散到不同的服务器上的（每一个服务器都有自己的一个域名解析）

• WEB服务器（处理静态资源文件，例如：html/css/js等 的请求）

• 数据服务器（处理数据请求）

• 图片服务器 （处理图片请求）

• 音视频服务器

• …
  这样导致，我们需要解析的DNS会有很多次

• DNS域名解析是什么？

• 发布站点时配置域名解析

  • 网址访问进行DNS域名反解析

不是所有的资源都可以预加载
当资源为以下列表中的资源时，将阻止预渲染操作：
1.URL 中包含下载资源
2.页面中包含音频、视频
3.POST、PUT 和 DELETE 操作的 ajax 请求
4.HTTP 认证(Authentication)
5.HTTPS 页面
6.含恶意软件的页面
7.弹窗页面
8.占用资源很多的页面
9.打开了 chrome developer tools 开发工具

优化技巧：DNS Prefetch 即 DNS 预获取

• 减少DNS的请求次数
• 进行DNS预获取

让页面加载（尤其是后期资源的加载）更顺畅更快一些

<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="//static.360buyimg.com">
<link rel="dns-prefetch" href="//misc.360buyimg.com">
<link rel="dns-prefetch" href="//img10.360buyimg.com">
<link rel="dns-prefetch" href="//img11.360buyimg.com">
<link rel="dns-prefetch" href="//img12.360buyimg.com">
.......

缓存时间在1分钟左右

3.基于TCP的三次握手，够建客户端和服务器端的连接通道

只有建立好连接通道，才能基于HTTP等传输协议，实现客户端和服务器端的信息交互

• 第一次握手：由浏览器发起，告诉服务器我要发送请求了

• 第二次握手：由服务器发起，告诉浏览器我准备接受了，你赶紧发送吧

• 第三次握手：由浏览器发送，告诉服务器，我马上就发了，准备接受吧

4.发送HTTP请求

基于HTTP等传输协议，客户端把一些信息传递给服务器

• HTTP请求报文（所有客户端传递给服务器的内容，统称为请求报文）

  • 谷歌控制台NetWork中可以看到
  • 请求起始行
  • 请求首部（请求头）
  • 请求主体

• 强缓存 和 协商缓存（性能优化：减少HTTP请求的次数）

  • 强缓存 ( Cache-Control 和 Expires )
  • 协商缓存 ( Last-Modified 和 Etag )

5.服务器接受到请求，并进行处理，最后把信息返回给客户端

• WEB（图片）服务器和数据服务器
  Tomcat
  Nginx
  Apache
  IIS
  ……

HTTP响应报文
响应状态码
200 / 201 / 204
301 / 302 / 304 / 307
400 / 401 / 404
500 / 503

响应头（首部）
响应主体

• HTTP响应报文（所有服务器返回给客户端的内容）
  • 响应起始行
  • 响应首部（响应头）
    • date存储的是服务器的时间
    • …
  • 响应主体
  • 服务器返回的时候是：先把响应头信息返回，然后继续返回响应主体中的内容（需要的信息大部分都是基于响应主体返回的）

6.断开TCP链接通道 （四次挥手）

• 当客户端把请求信息发送给服务器的时候，就挥第一次手：客户端告诉服务器端，我已经把请求报文都给你了，你准备关闭吧
• 第二次挥手：由服务器发起，告诉浏览器，我接收完请求报文，我准备关闭，你也准备吧；
• 第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完毕，你准备关闭吧；
• 第四次挥手：由浏览器发起，告诉服务器，我响应报文接收完毕，我准备关闭，你也准备吧；

Connection: Keep-Alive 保持TCP不中断（性能优化点，减少每一次请求还需要重新建立链接通道的时间）

7.客户端渲染服务器返回的结果

画图理解

前端性能优化点

1. 减少HTTP请求的次数和大小

• 合并压缩 webpack（代码比较少的情况下，尽可能使用内嵌式）
• 雪碧图或者图片BASE64
• 对于动态获取的图片，采用图片懒加载（数据也做异步分批加载：开始只请求加载第一屏的数据，滑动到第几屏在加载这一屏的数据和图片）
  • 骨架屏技术（首屏内容由服务器渲染；再或者开始展示占位结构，客户端在单独获取数据渲染；）
• 音视频取消预加载（播放的时候再去加载音视频文件，对于自动播放采取延迟播放的处理）
• 服务器采用GZIP压缩
• …

2.建立缓存机制

把一些请求回来的信息进行本地存储（缓存存储），在缓存有效期内，再次请求资源，直接从缓存中获取数据，而不是服务器上从新拉取

• DNS预获取
• 资源文件的强缓存和协商缓存（304）
• 数据也可以做缓存（把从服务器获取的数据存储到本地：cookie/localStorage/redux/vuex等，设定期限，在期限内，直接从本地获取数据即可）
• 离线存储（一般很少用）manifest
• CDN区域分布式服务器开发部署（费钱 效果会非常的好）
• …

3.代码上的优化

• 减少DOM的重绘和回流
• 在JS中尽量减少闭包的使用（内存优化）
• 在JS中避免“嵌套循环”和“死循环”
• 尽可能使用事件委托
• 尽量减少CSS表达式的使用(expression)
• CSS选择器解析规则是从右向左解析（基于less/sass开发的时候尽可能减少层级嵌套，目的是让选择器的前缀短一点） 【 a{} 和 .box a{}对比，.box a 性能差 大神尽量少用less sass会导致过量嵌套】
• 尽可能实现JS的封装（低耦合高内聚），减少页面中的冗余代码
• 在CSS导入的时候尽量减少使用@import导入式
• 使用window.requestAnimationFrame（JS中的帧动画）代替传统的定时器动画（能用CSS3动画的绝对不用JS动画）
• 减少递归的使用，避免死递归，避免由于递归导致的栈内存嵌套
• 基于SCRIPT调取JS的时候，可已使用 defer或者async 来异步加载
  ……

4.安全优化

5.webpack上的优化

其他权威资料补充

面试官：讲一讲三次握手四次挥手，为什么是三次握手四而不是两次握手？

客户端和服务端之间通过三次握手建立连接，四次挥手释放连接

三次握手，客户端先向服务端发起一个SYN包，进入SYN_SENT状态，服务端收到SYN后，给客户端返回一个ACK+SYN包，表示已收到SYN，并进入SYN_RECEIVE状态，最后客户端再向服务端发送一个ACK包表示确认，双方进入establish状态。

之所以是三次握手而不是两次，是因为如果只有两次，在服务端收到SYN后，向客户端返回一个ACK确认就进入establish状态，万一这个请求中间遇到网络情况而没有传给客户端，客户端一直是等待状态，后面服务端发送的信息客户端也接受不到了。

四次挥手，首先客户端向服务端发送一个FIN包，进入FIN_WAIT1状态，服务端收到后，向客户端发送ACK确认包，进入CLOSE_WAIT状态，然后客户端收到ACK包后进入FIN_WAIT2状态，然后服务端再把自己剩余没传完的数据发送给客户端，发送完毕后在发送一个FIN+ACK包，进入LAST_ACK（最后确认）状态，客户端收到FIN+ACK包后，再向服务端发送ACK包，在等待两个周期后在关闭连接

之所以等待两个周期是因为最后服务端发送的ACK包可能会丢失，如果不等待2个周期的话，服务端在没收收到ACK包之前，会不停的重复发送FIN包而不关闭，所以得等待两个周期

面试官：从浏览器输入url后都经历了什么⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐具重要！

先进行DNS域名解析，先查看本地hosts文件，查看有没有当前域名对应的ip地址，若有直接发起请求，没有的话会在本地域名服务器去查找，该查找属于递归查找，如果本地域名服务器没查找到，会从根域名服务器查找，该过程属于迭代查找，根域名会告诉你从哪个与服务器查找，最后查找到对应的ip地址后把对应规则保存到本地的hosts文件中。

*> 如果想加速以上及之后的http请求过程的话可以使用缓存服务器CDN，CDN过程如下：

用户输入url地址后，本地DNS会解析url地址，不过会把最终解析权交给CNAME指向的CDN的DNS服务器
CDN的DNS服务器会返回给浏览器一个全局负载均衡IP 用户会根据全局负载均衡IP去请求全局负载均衡服务器
全局负载均衡服务器会根据用户的IP地址，url地址，会告诉用户一个区域负载均衡设备，让用户去请求它。
区域负载均衡服务器会为用户选择一个离用户较近的最优的缓存服务器，并把ip地址给到用户
用户想缓存服务器发送请求，如果请求不到想要的资源的话，会一层层向上一级查找，知道查找到为止。*

进行http请求，三次握手四次挥手建立断开连接
服务器处理，可能返回304也可能返回200
返回304说明客户端缓存可用，直接使用客户端缓存即可，该过程属于协商缓存
返回200的话会同时返回对应的数据
客户端自上而下执行代码
其中遇到CSS加载的时候，CSS不会阻塞DOM树的解析，但是会阻塞DOM树的渲染，并且CSS会阻塞下面的JS的执行
然后是JS加载，JS加载会影响DOM的解析，之所以会影响，是因为JS可能会删除添加节点，如果先解析后加载的话，DOM树还得重新解析，性能比较差。如果不想阻塞DOM树的解析的话，可以给script添加一个defer或者async的标签。
defer：不会阻塞DOM解析，等DOM解析完之后在运行，在DOMContentloaed之前
async: 不会阻塞DOM解析，等该资源下载完成之后立刻运行
进行DOM渲染和Render树渲染
获取html并解析为Dom树
解析css并形成一个cssom（css树）
将cssom和dom合并成渲染树（render树）
进行布局（layout）
进行绘制（painting）
回流重绘
回流必将引起重绘，重绘不一定引起回流