前言
在这互联网高速发展的时代，人们对于网页打开的速度要求越来越高。加载时间过长，兼容处理不够全面等很容易造成用户流失。作为一名前端开发，优化用户体验是一件永无止境的事情，没有最优，只有更优。前端性能优化方向有很多，今天主要讲解在网络请求上的优化。因涉及的优化方向较多，对于具体细节不再赘述。
总体按以下三个方向优化:
- 请求数据控制
- 请求体积减少
- 请求尽其所能
请求之数量减少
减少DNS查询
DNS查询首先查看浏览器缓存是否存在，不存在则访问本机DNS缓存，再不存在则访问本地DNS服务器，在这期间浏览器是无法下载其他任何内容资源，这是一笔不小的开销。所以理想的方法是将静态资源尽可能的放在同一个域下，这样就只会发生一次DNS查找，但这也会引发另一个问题，浏览器的并行下载数量是有限制的，不同的浏览器有所差异，超出限制就会排队等待，建议一个站点使用2-4个域请求资源，不要太分散，也不要太集中。
请求合并
一个网页加载完成所需要的请求数量少则几十，多则上百。这里面包括XHR，JS，CSS，Img，Font，Doc等等。不同的浏览器对请求的并发数量都是有限制的，如果你已升级HTTP2.0，那么这个优先级可以放后。
针对同类型资源排查是否有合并请求的可能性，合并的前提也要考虑业务场景及合并后的体积是否会过大。图片资源小图标考虑雪碧图(CSS Sprites) 配合 `background-position` 使用。过小的图片可转换为Base64，可在webpack中的`url-loader`配置。除开针对静态资源的合并处理，在不影响接口性能的前提下，和后端的接口交互也可以视情况做合并处理。
按需加载
排查每一个请求是否都是当前页面必要存在的，尽可能做到按需加载，避免不必要的资源占用，这样不仅可以提升网页打开速度节省用户流量资源，也能减少服务器流量请求。Vue中可开启路由懒加载，页面JS&CSS只会在页面加载时才触发请求。图片开启懒加载可以让一些不可视区域的图片不去加载，避免一次性加载过多的图片导致请求阻塞，提高网站的加载速度，提高用户体验。
重复请求处理
用户频繁切换Tab栏数据；表单提交频繁点击；路由切换时还有未完成的请求。这些都会产生无效请求，对服务器和用户体验来说都是不好的。
重复请求可在每个请求发起的时候存储当前存储的标记在一个数组或Map中, 针对每个请求的时候在请求拦截中查询是否重复, 如果已重复则取消历史中重复的请求, 再发起当前请求, 如果没有重复, 则添加存储标记并正常请求, 已请求完成的清除存储标记，Axios 中提供了 `CancelToken` 函数，该函数的作用就是用来取消接口请求；Vue中当路由切换页面的时候，可在router的`beforeEach`钩子函数中取消当前正在进行中的所有请求。
添加到请求记录：
constaddPendingXHR= (config) => { if (!cancelDuplicated) { return } constduplicatedKey=JSON.stringify({ duplicatedKey: duplicatedKeyFn(config), type: REQUEST_TYPE.DUPLICATED_REQUEST }) config.cancelToken=config.cancelToken||newaxios.CancelToken((cancel) => { if (duplicatedKey&&!pendingXHRMap.has(duplicatedKey)) { pendingXHRMap.set(duplicatedKey, cancel) } }) }
取消请求并删除请求记录：
constremovePendingXHR= (config) => { if (!cancelDuplicated) { return } constduplicatedKey=JSON.stringify({ duplicatedKey: duplicatedKeyFn(config), type: REQUEST_TYPE.DUPLICATED_REQUEST }) if (duplicatedKey&&pendingXHRMap.has(duplicatedKey)) { constcancel=pendingXHRMap.get(duplicatedKey) cancel(duplicatedKey) pendingXHRMap.delete(duplicatedKey) } }
axios中使用：
// 请求拦截处理axios.interceptors.request.use(config=> { removePendingXHR(config) addPendingXHR(config) returnconfig}) // 响应拦截处理axios.interceptors.response.use(response=> { removePendingXHR(response.config) }, error=> { // 如果是取消请求类型则忽略异常处理letisDuplicatedType; try { consterrorType= (JSON.parse(error.message) || {}).typeisDuplicatedType=errorType===REQUEST_TYPE.DUPLICATED_REQUEST; } catch (error) { isDuplicatedType=false } if (!isDuplicatedType) { // 其他异常处理 } })
Vue中当路由切换页面的时候，将上一个页面的所有请求取消：
router.beforeEach((to, from, next) => { pendingXHRMap.forEach((cancel) => { cancel(); }); pendingXHRMap.clear() })
缓存接口数据
减少数据的交互就意味着减少了网络带宽的压力，能够提供更大并发量的服务，减少网络传输的时间，也大大的减小了服务器的开销。
解决：首次请求数据后缓存在前端本地，后续数据来源均从缓存获取数据解析使用，从中取出页面操作所需要的信息然后再进行展现，有效减少请求后台服务器的次数，缓存格式可以是 `Map` 或是 `JSON` 。需设置相应缓存策略，定期清除历史数据，如接口数据是变动较为频繁，可从缓存获取后再触发一次接口数据覆盖页面内容。
CORS OPTIONS预检请求
当前端使用脚本请求一个跨域资源时，如果是**非简单请求**，浏览器会自动先发出一个OPTIONS查询请求，称为预检(cors-preflight-request)，作用是询问服务器当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段；只有得到肯定答复，浏览器才会发出正式的跨域请求。那么如何节省掉OPTIONS请求来提升性能呢？
1. 发出简单请求；
1. 服务端设置`Access-Control-Max-Age`字段缓存该OPTIONS预检请求的响应结果，该缓存只针对这一个请求 URL 和相同的 header，无法针对整个域或者模糊匹配 URL 做缓存。
请求之体积减小
资源压缩
部署上线的代码开启压缩，并可在编译阶段去除代码中的 `console` 和注释 ，进一步减小文件的体积。UI切图文件需检查是否体积过大，对于过大图片类型资源可压缩后再使用，压缩可使用 tinypng。
HTTP压缩
gzip是使用最为普遍，支持的浏览器最多的数据压缩方式。浏览器请求头发送 `Accept-Encoding` 字段，表明所支持的压缩算法，以及各自的优先级，服务器则从中选择一种压缩方式，并且返回响应头 `Content-Encoding` 字段来告知浏览器选择的哪一种算法。下图可见开启gzip压缩后原始资源182kb压缩后只有75kb，节省了约60%的数据传输。对于接口请求不管是发送数据还是接收数据，不需要的字段尽可能的不传，这一点需要多和服务端同学沟通，避免过多的数据影响请求的传输的速度。
HTTP压缩能大大减小网络传输的数据量，提升页面显示的速度，但是压缩的过程也会给服务器带来一定的开销。
使用WebP
webp格式是谷歌开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器宽带资源和数据空间。使用webp不仅能节省用户流量资源，也可以降低服务器流量资源。
缺点是还有部分浏览器还不支持webp格式，使用的时候需要注意兼容性的处理。首先检测当前浏览器是否支持webp，检测的方式可通过canvas或JS加载1像素的webp图片，如支持webp可在根节点添加 webp 标识 class 来处理图片是否可以加载webp格式的文件。目前各大cdn服务都支持webp格式输出，如还有未接入cdn服务，需要生成webp格式的图片，可在前端编译过程中生成，也可以在nginx层做转换。
检测是否支持webp
// 使用 canvas 的 toDataURL 进行判断functionisSupportWebp() { try { returndocument.createElement('canvas').toDataURL('image/webp', 0.5).indexOf('data:image/webp') ===0; } catch(err) { returnfalse; } } // 通过加载一张 webp 图片判断functioncheckWebpFeature(feature, callback) { varkTestImages= { lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA", lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==", alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==", animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA" }; varimg=newImage(); img.onload=function () { varresult= (img.width>0) && (img.height>0); callback(feature, result); }; img.onerror=function () { callback(feature, false); }; img.src="data:image/webp;base64,"+kTestImages[feature]; }
CSS中sass写法
@mixinwebpbg($url) { background-image: url($url); @at-root.webpa & { background-image: url($url+'.webp'); } } @includewebpbg('../image/header.jpg');
HTML中img检测使用
constchangeToWebp= (url) => { if (isSupportWebp()) { return`${url}${url.indexOf('?') >0?'&' : '?'}x-oss-process=image/format,webp` } else { returnurl } }
前后对比
Cookie 传输优化
- 合理使用Cookie字段，除去不必要的Cookie，避免Cookie数据过大。
- 使用Cookie跨域操作时注意在适应级别的域名上设置Cookie（domain）以便使子域名不受其影响。
- 设置合理Cookie的过期时间，合理地Expire时间和不要过早去清除Cookie，浏览器对存储大小和数量都是有限制的，要避免存满浏览器可用空间。
- 静态资源使用使用独立域名访问策略，避免请求静态资源时发送Cookie，减少http的请求体积。
请求之尽其所能
开启CDN加速
CDN的全称是Content Delivery Network，即内容分发网络. 当用户向该业务内容发起请求时，请求会被调度至最接近用户的服务节点，直接由服务节点快速响应，有效降低用户访问延迟，提升可用性。除了常见的对静态资源 JS & CSS & IMG 等开启cdn，对一些数据不常变化的接口请求也可开启cdn加速。
开启HTTP缓存
HTTP缓存主要用在对一些实时性要求不高的静态文件进行的缓存，缓存在浏览器端，防止这些“多余”的请求重复的访问服务器，对服务器造成压力，直接从浏览器缓存获取资源，从而提高网站的性能。缓存分为强制缓存和协商缓存两种。
强制缓存指服务端返回缓存时间给到浏览器，在下次请求前只要还在缓存时间内，则不发起请求，直接使用缓存。超过缓存时间，则发起请求获取文件。响应header中会有两个字段来标明失效规则（Expires/Cache-Control）。
协商缓存 指通过查询文件对比上次请求是否修改来决定是否使用缓存。浏览器第一次请求数据时，服务端会将缓存标识与数据一起返回给客户端，客户端将二者备份至缓存数据库中。
再次请求数据时，客户端将备份的缓存标识发送给服务端，服务端根据缓存标识进行判断，判断缓存有效后，返回304状态码，通知客户端使用缓存数据。缓存标识区分两种方式：
文件最后修改时间标识：
- Response：`Last-Modified`
- Request：`If-Modified-Since`
文件内容标识：
- Response：`E-tag`
- Request：`If-None-Match`
尽可能去避免304请求，因为会多发出一次请求，让浏览器直接从缓存读取文件，减少带宽消耗和服务器的负载。
升级HTTP 2.0
在 HTTP/1.1 协议中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制，超过限制数目的请求会被阻塞。HTTP2.0主要有以下新特性：
- 多路复用 允许同时通过单一的http/2.0连接发起多重的请求，所有的请求都是通过一个TCP 连接并发完成，真正做到了并行传输。
- HTTP/1.x 每次请求，都会携带大量冗余头信息，浪费了很多带宽资源，http/2.0的**头部压缩**，减少了数据传输量，能够节省消息头占用的网络的流量。
- Server Push 能够更快的把资源推送给客户端。例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不需要客户端解析 HTML 再发送这些请求。当客户端需要的时候，资源已经在客户端了。
预加载
DNS Prefetch 是一种DNS 预解析技术，当浏览网页时，浏览器会在加载网页时对网页中的域名进行解析缓存，这样在你从当前网页中跳转新的连接时就无需进行DNS 的解析，减少用户等待时间，提高用户体验。
<linkrel="dns-prefetch"href="//img.cdn.com">
浏览器要建立一个连接，首先需要经过DNS查找，TCP三次握手和TLS协商（https），这些过程都是需要相当的耗时的，所以preconnet，就是一项使浏览器能够预先建立一个连接，等真正需要加载资源的时候就能够直接请求。
<linkrel="preconnect"href="//example.com">
让浏览器预加载一个资源（HTML，JS，CSS或者图片等），可以让用户跳转到其他页面时，响应速度更快。
<linkrel="prefetch"href="prefetch.js">
总结
前端页面使用场景多变，受外界因素影响较多，网络环境，用户设备，浏览器内核等都会影响性能体验。所以针对每一个请求都要想想是否有优化的空间，是否有省去的可能，让每发起一个请求都尽其所能，达到请求的极致。前端性能优化是一件永无止境的事情，也是一件严肃的事情，一定要对优化的方向有系统的理解，不能盲目优化，否则会得不偿失。
参考
1. [HTTP/2 相比 1.0 有哪些重大改进？](https://www.zhihu.com/question/34074946)
1. [dns-prefetch对网站速度能提升有多少？](https://www.sojson.com/blog/218.html)
1. [Head标签里面的dns-prefetch，preconnect，prefetch和prerender](https://segmentfault.com/a/1190000011065339)
1. [tinypng](https://tinypng.com/)
1. [HTTP 缓存详解](https://blog.csdn.net/i6448038/article/details/80090495?share_token=9762F62A-452B-442A-ADC9-25B0C6FAA673&tt_from=copy_link&utm_source=copy_link&utm_medium=toutiao_ios&utm_campaign=client_share)
1. [对CORS OPTIONS预检请求的一些思考](https://blog.csdn.net/sD7O95O/article/details/112210506?share_token=AE81360A-20E1-4E4F-AD27-4A334FD82261&tt_from=copy_link&utm_source=copy_link&utm_medium=toutiao_ios&utm_campaign=client_share)
