Web前端性能优化（一）

• 减少http请求数、压缩js，css等文件

Webpack使用

 

• 使用CDN

内容分发网络（Content Delivery Network，CDN）是建立并覆盖在承载网上，由不同区域的服务器组成的分布式网络。将源站资源缓存到全国各地的边缘服务器，供用户就近获取，降低源站压力，提高web端响应性能。

具体的过程如下图，下面是阿里云CDN的工作原理图，DNS调度系统是阿里云部署解析IP。

从而，就近获取访问网页的内容，降低源服务器的压力，也提高了页面响应速度

• 浏览器缓存

浏览器缓存是将网页资源缓存到内存中，访问资源时直接从内存中读取而不是从服务端获取。浏览器分为强缓存和协商缓存。

这里，我们必须知道的是HttpStatus 200（From Cache）和 304（Not Modified）背后是什么一种工作模式？

1、首先我先了解一下，浏览器在“刷新”下的处理模式：

1）URL回车或者链接访问URL，浏览器获取资源的时候不会设置 Cache-Control:max-age=0，所以如果expire设置的max-age如果仍有效的话会优先从本地cache中获取。

2）刷新或者强制刷新（mac下的Command+R，win下的F5，Ctrl+F5等），发起Request的时候浏览器给 header 里设置的 Cache-Control:max-age=0，我们都知道一旦max-age为0，则不会从本地cache获取数据了，所以会发起一次http请求，服务器根据header里传来的If-Modified-Since或者If-None-Match分别与Last-Modified，Etag做对比，从而做出返回304还是200的选择，而强制刷新是将 header 设置为 Cache-Control:no-cache，直接返回200，下载资源.

所以我们就知道浏览器的一个请求过程了，首先会先根据缓存字段决定读取缓存还是去请求服务器。

2、强缓存，强缓存不会向服务器发送请求，直接从缓存中读取资源，在chrome控制台的Network选项中可以看到该请求返回200的状态码，并且Size显示from disk cache或from memory cache。如下图所示，强缓存可以通过设置两种 HTTP Header 实现：Expires 和 Cache-Control

 

1. cache和Expires

cache是http1.1版本的，Expires是http1.0版本的，Expires在使用过程中有某些缺点：

a、指定的时间是以服务端为准但是客户端进行过期判断时是将本地的时间和这个时间进行对比

b、如果客户端端时间和服务端时间存在差异，则会存在问题

为了解决 Expires 的缺点，HTTP 1.1 增加了新的 header 字段 Cache-control 来更精准的控制缓存常用的 Cache-control 信息

（2）cache字段解析

 public：所有内容都将被缓存（客户端和代理服务器都可缓存）。具体来说响应可被任何中间节点缓存。

private：所有内容只有客户端可以缓存，Cache-Control的默认取值。

no-cache：客户端缓存内容，是否使用缓存则需要经过协商缓存来验证决定。表示不使用 Cache-Control的缓存控制方式做前置验证，而是使用 Etag 或者Last-Modified字段来控制缓存。

no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存

max-age：max-age=xxx (xxx is numeric)表示缓存内容将在xxx秒后失效

s-maxage（单位为s)：同max-age作用一样，只在代理服务器中生效（比如CDN缓存）。比如当s-maxage=60时，在这60秒中，即使更新了CDN的内容，浏览器也不会进行请求。max-age用于普通缓存，而s-maxage用于代理缓存。s-maxage的优先级高于max-age。如果存在s-maxage，则会覆盖掉max-age和Expires header。

max-stale：能容忍的最大过期时间。max-stale指令标示了客户端愿意接收一个已经过期了的响应。如果指定了max-stale的值，则最大容忍时间为对应的秒数。如果没有指定，那么说明浏览器愿意接收任何age的响应（age表示响应由源站生成或确认的时间与当前时间的差值）。

min-fresh：能够容忍的最小新鲜度。min-fresh标示了客户端不愿意接受新鲜度不多于当前的age加上min-fresh设定的时间之和的响应。

 

3、协商缓存，就是在强缓存失效的情况下进行协商缓存判定

 

浏览器请求服务器，服务器响应浏览器，并在响应头里面加入ETag和Last-modified，浏览器再次发出请求时，会把相应的ETag和Last-modified的值写入请求头里的If-Modified-Since和If-None-Match里，然后在服务器对比结果，ETag是Last-modified的升级，因为Last-modified可能存在毫秒的误差，不可感知的时间内修改完成文件。

既然根据文件修改时间来决定是否缓存尚有不足，能否可以直接根据文件内容是否修改来决定缓存策略？所以在 HTTP / 1.1 出现了 ETag 和If-None-Match

1. Last-Modified和If-Modified-Since
2. ETag和If-None-Match

1）、2）对比，首先在精确度上，Etag要优于Last-Modified。

Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。

第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。

第三在优先级上，服务器校验优先考虑Etag