前端性能优化-网络层

一、URL请求

1、用户在浏览器地址栏中输入地址之后经历了哪些事情（一次完整页面请求所发生的事情）面试题常问
1）URL解析
2) DNS解析
3）建立TCP连接（TCP三次握手）
4、发送HTTP请求，
6、服务器处理请求，返回响应结果
7、关闭TCP连接通道（TCP四次挥手）
8、浏览器渲染
9、代码执行

各步骤详解

• 1、URL解析

    1）地址解析和编码
  
    2）HSTS（HTTP严格传输安全协议）
  
    3）缓存检查
  

• 2、DNS解析
  
  
• 3、TCP三次握手
  
• 4、发送HTTP请求，服务器处理请求，返回响应结果
• 5、TCP四次挥手
  
• 6、 浏览器渲染
• 7、代码运行中

二、 前端网络交互层面上的性能优化

1. DNS方面的优化

因为DNS解析时要花时间的，每一次DNS解析时间预计在20~120毫秒。
解决方案：
1）减少DNS请求次数
2）DNS预获取（DNS Prefetch）

大型网站，如京东淘宝等一个页面通常要从不同的服务器上获取资源，需要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="//d.3.cn"/>
<link rel="dns-prefetch" href="//d.jd.com"/>

2、减少HTTP请求次数和请求资源大小

1）资源合并压缩 （如vue、react等框架基于webpack将多个js、css压缩打包成一个文件、减少了http的请求次数）

2）字体图标（使用iconfont的图标减少http请求）

3）Base64（将一些大图片，比如活动图片等使用Base64渲染，会加载得很快，就是代码上恶心了一些，不过现在使用的vue、react框架会基于webpack将图片资源转成base64位，我们在开发的时候不用做任何处理）

4）GZIP（一般的文件能压缩60%多）（这个是服务器做的事情）

5）图片懒加载（加载图片比较多的的页面、如新闻列表、或者商城页面都使用懒加载处理）

6）数据延迟分批加载（分页）

7）CDN资源 （CDN资源加载比较快）

…

3. 应用缓存

1）Service Worker：浏览器独立线程进行缓存

2）Memory Cache : 内存缓存

3）Disk Cache：硬盘缓存

4）Push Cache：推送缓存（HTTP/2中的）

我们先了解浏览器是使用缓存的三种情况：
1）打开网页，地址栏输入地址=> 查找 disk cache中是否有匹配，如有则使用，如没有则发送网络请求。
2）普通刷新 (F5)=>因为 TAB 并没有关闭，因此 memory cache是可用的，会被优先使用(如果匹配的话)，其次才是 disk cache。（先看memory cache中是否有缓存，没有再查看disk cache中有没有）
3）强制刷新 (Ctrl + F5)=>浏览器不使用缓存，因此发送的请求头部均带有 Cache-control:
no-cache(为了兼容，还带了 Pragma: no-cache)，服务器直接返回 200 和最新内容。

我们打开浏览器，打开某个网页，在不关闭浏览器的情况下浏览器会默认将get请求、一些图片、css、js等缓存，可能存在Memory 中或Disk上，刷新的时候浏览器会从缓存中去取。但浏览器关闭了，重新打开，浏览器会重新拉取服务器的信息。
如果想关闭浏览器之后依然能从缓存中或者资源。需要服务器来做一些设置：如强缓存、协商缓存。

1）强缓存 Expires / Cache-Control

在响应头中我们可以看到Expires （设置过期时间点）或Cache-Control（设置过期时长）都是用来设置强缓存的：

浏览器对于强缓存的处理：根据第一次请求资源时返回的响应头来确定的

• Expires：缓存过期时间，用来指定资源到期的时间（HTTP/1）
• Cache-Control：cache-control: max-age=2592000第一次拿到资源后的2592000秒内（30天），再次发送请求，读取缓存中的信息（HTTP/1.1）
• 两者同时存在的话，Cache-Control优先级高于Expires

2）协商缓存 Last-Modified / ETag

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程

• 协商缓存生效，返回304和Not Modified
  
• 协商缓存失效，返回200和请求结果

Last-Modified和If-Modified-Since
第一次访问资源，服务器返回资源的同时，响应头中设置 Last-Modified（服务器上的最后修改时间），浏览器接收后，缓存文件和响应头；
下一次请求这个资源，浏览器检测到有 Last-Modified，于是添加If-Modified-Since请求头，值就是Last-Modified中的值；
服务器再次收到这个资源请求，会根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比，如果没有变化，返回304和空的响应体，直接从缓存读取，如果If-Modified-Since的时间小于服务器中这个资源的最后修改时间，说明文件有更新，于是返回新的资源文件和200；
但是Last-Modified 只能以秒计时，如果在不可感知的时间内修改完成文件，那么服务端会认为资源还是命中了，不会返回正确的资源；

ETag和If-None-Match
Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，只要资源有变化，Etag就会重新生成；下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到请求头If-None-Match里，服务器只需要比较客户端传来的If-None-Match跟自己服务器上该资源的ETag是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现ETag匹配不上，那么直接以常规GET 200回包形式将新的资源（当然也包括了新的ETag）发给客户端；如果ETag是一致的，则直接返回304知会客户端直接使用本地缓存即可。

3）数据缓存：LocalStorage本地存储