关于前端缓存优化

关于缓存，大概可以分为以下几种：

① CDN缓存

② DNS缓存

③ 客户端缓存（无需哀求的memory cache,disk cache；须要发哀求验证的Etag/Last-Modified304）

④ Service Worker与缓存及离线缓存

⑤ PageCache与ajax缓存

一、 CDN缓存

CDN可以明白为分布在每个县城或州里的火车票代售点，用户在欣赏网站时，CDN会选择一个离用户近来的CDN边沿节点来相应用户哀求。其上风很显着（1）CDN节点办理了跨运营商和跨地域访问的标题，访问延时大大低落；（2）大部门哀求在CDN边沿节点完成，CDN起到了分流作用，减轻了源站的负载。

关于CDN缓存，在欣赏器当地缓存失效后，欣赏器会向CDN边沿节点发起哀求。雷同欣赏器缓存，CDN边沿节点也存在着一套缓存机制。CDN边沿节点缓存计谋因服务商差别而差别，但一样寻常都会依照http尺度协议，通过http相应头中的cache-control:max-age字段来设置CDN边沿节点数据缓存时间。

当客户端向CDN节点哀求数据时，CDN节点会判定缓存数据是否逾期，若缓存数据并没有逾期，则直接将缓存数据返回给客户端；否则，CDN节点会向源站发出回源哀求，从源站拉取最新数据，更新当地缓存，并将最新数据返回给客户端。

CDN服务商一样寻常会提供基于文件后缀、目次多个纬度来指定CDN缓存时间，为用户提供更风雅化的缓存管理。

CDN缓存革新：

CDN边沿节点对开发者是透明的，相比于欣赏器ctrl+f5的欺压革新来使欣赏器当地缓存失效，开发者可以通过CDN服务商提供的"革新缓存"接口来到达清算CDN边沿节点缓存的目标。如许开发者在更新数据后，可以利用"革新缓存"功能来欺压CDN节点上地数据缓存逾期，包管客户端在访问时，拉倒最新数据。

二、 DNS缓存

DNS（Domain Name System）:负责将域名URL转化为服务器主机IP。

DNS查找流程：起首检察欣赏器缓存是否存在，不存在则访问本机DNS缓存，再不存在则访问当地DNS服务器。以是DNS也是开销，通常欣赏器查找一个给定URL的IP地点要耗费20-120ms，在DNS查找完成前，欣赏器不能从host那边下载任何东西。

TTL（Time To Live）：表现查找返回的DNS记录包罗的一个存活时间，逾期则这个DNS记录将被扬弃。欣赏器DNS缓存也有本身的逾期时间，这个时间是独立于本机DNS缓存的，相对也比力短，比方chrome只有1分钟左右。

DNS性能优化最佳实践

当客户端的DNS缓存为空时，DNS查找的数量与web页面中唯一主机名的数量相称。以是镌汰唯一主机名的数量就可以镌汰DNS查找的数量。

而偶然间须要多设置主机数量来增长DNS点负载平衡，因此镌汰DNS查找和增长主机数量形成了抵牾关系，颠末实战DNS设置2-4个主机名是最佳的。更多负载平衡可以用其他方式实现，比方用nginx做负载平衡。

三、欣赏器缓存计谋之客户端缓存

1. Cache-control:max-age

假设你的站点引用了一个脚本文件一年都不会改变，那么就渴望欣赏器将这个脚本文件缓存起来，不消每一次都哀求服务器返回雷同的内容。如许可以或许节省带宽开销而且能提升性能。

只须要设置文件返回的http头中的cache-control设置为：cache-control:max-age=31536000。  // 可以控制缓存时间

尺度中规定max-age值最大不能凌驾一年，又由于是以秒为单位，以是值为31536000。

如果这个稳定的脚当地点是www.haorooms.com/never-expire.js，那么接下来每次用户哀求这个地点时，欣赏器都不会再向服务器发出哀求，而是直接从当地的欣赏器缓存中取。直到一年后或用户手动扫除了。

但是期间发现脚本内容须要更改怎么办？改变哀求的文件名就好了，比方never-expire-v2.js。

cache-control是http1.1的特性，cache-control尚有别的信息：

（1）no-cache:先不要读取缓存中的文件，向web服务器哀求验证缓存是否希奇，希奇则利用缓存。

（2）no-store:这个字段很关键，它表现数据不在硬盘中临时生存only-if-cached:就是在客户端有缓存时就利用客户端的缓存，这个一样寻常都是在无网时利用

（3）max-stale:只要缓存的时间没有凌驾max-stale指定的时间，就可以加载利用。可以在无网络的环境下利用must-revalidate：作用雷同，但是更为严酷，每次哀求都校验缓存和服务器源文件，划一就利用缓存，不划一就取最新的。

（4）s-maxage同max-age，覆盖max-age/Expires，但仅实用共享缓存，在私有缓存中被忽略。public表明相应可以呗任何对象（发送哀求的客户端、署理服务器等等）缓存。private表明相应只能被单个用户（大概是利用体系用户、欣赏器用户）缓存，黑白共享的，不能被署理服务器缓存。

2. Expires

设置了Expires也可以克制欣赏器和服务器发哀求，直到时间逾期。

注：Expires是http1.0特性，比cache-control要早，有一些缺陷。由于失效时间是一个绝对时间，以是当客户端当地时间被修改后，服务器与客户端时间弊端变大后，就会导致缓存紊乱。

以上两个缓存依照三级缓存原理，cache-control与expires可以在服务端设置同时启用大概启用恣意一个，同时启用的时间cache-control优先级高。

3. Last-Modified 304 协商缓存

服务器为了关照欣赏器当前文件的版本，会发送一个前次修改时间的标签，比方：

Last-Modified: Tue, 06 Jan 2018 08:26:32 GMT

如果是304协商缓存，验证步调如下：

① 欣赏器：Hey，我须要jquery.min.js这个文件，如果是在Last-Modified:Tue,06 Jan 2018 08:26:32 GMT之后修改过的，请发给我

② 服务器：查抄文件修改时间

③ 服务器：Hey，这个文件在谁人时间之后没有被修改过，你已经有最新版本了

④ 欣赏器：太好了，那我就表现给用户啦

4. ETag

Etag和304雷同，但是级别比Last-Modified高一些

哀求过程：

① 欣赏器： Hey，我须要haorooms的main.css这个文件，有没有不匹配"61213-1762a-50bf790757204"这个串的

② 服务器：（查抄ETag...）

③ 服务器：Hey，我这里的版本也是"61213-1762a-50bf790757204"，你已经是最新版本了

④ 欣赏器：好，那就可以利用当地缓存了

四、Service Worker与缓存及离线缓存

随着Service Worker（以下简称SW）的遍及和规范，可以利用SW提供的缓存接口更换HTTP缓存。固然SW的功能是强盛的，除了缓存本事，还能实现离线、数据同步、配景编译等等。

一个标配版的sw缓存代码应该有以下的片断：

const version = '2';

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => cache.addAll([
        '/styles.css',
        '/script.js'
      ]))
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => response || fetch(event.request))
  );
});

网络哀求起首到达的是SW脚本中，如果未掷中再转发给http缓存。

这段代码的意思是，在SW的install阶段我们将script.js和styles.css放入缓存中；而在哀求发起的fetch阶段，通过资源的URL去缓存内查找匹配，乐成后立即返回，否则走正常的网络哀求流程。

但是在install阶段的资源内容是那里来的？仍然是从http缓存中来的。如许SW缓存机制又大概随着HTTP缓存陷入之前说的版本不划一中。

办理办法是让SW中的哀求必须向服务端验证：

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => cache.addAll([
        new Request('/styles.css', { cache: 'no-cache' }),
        new Request('/script.js', { cache: 'no-cache' })
      ]))
  );
});

如今并非全部的欣赏器都支持cache选项的设置，但我们可以通过添加随机数来包管每次哀求的URL都不雷同，间接的使得缓存失效。

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(`static-${version}`)
      .then(cache => Promise.all(
        [
          '/styles.css',
          '/script.js'
        ].map(url => {
          // cache-bust using a random query string
          return fetch(`${url}?${Math.random()}`).then(response => {
            // fail on 404, 500 etc
            if (!response.ok) throw Error('Not ok');
            return cache.put(url, response);
          })
        })
      ))
  );
});

五、PageCache与Ajax可缓存

PageCache是facebook提出的，办理ajax缓存的一种方案。

facebook计划了一个框架来辨认一个页面是否来自缓存（推测：页面初次加载完毕后将全部Ajax的Callback和Result缓存在当地。Facebook页面时基于AJAX获取页面内容，参加BigPipe），若来自缓存，通过ajax来更新所需更新到模块（推测：通过js预先界说本页面所需带薪的div id及对应的callback handler，并在页面下载时同时下载下来）。

其提到了三种更新范例：增量更新，用户复写（比方用户在页面上复兴了一则品评）及跨页更新（比方在消息具体页面将一则消息标识为已读，需将首页的未读消息数举行更新）。核心思绪照旧依据AJAX举行更新。

（1）增量更新：只要页面来自于缓存，即更新全部预界说的需增量更新的模块

（2）用户复写：通过HistoryManager记任命户利用并在cache页面读取后重放全部被标志为"replayable"的利用

（3）跨页更新：通过服务端Database API发送信号至客户端将逾期缓存标识为invaild。得到了缓存逾期信息后，通过ajax更新须要更新的信息。

facebook顺带提到一个更新Ajax内容克制页面厘革/闪灼的小本事，就是先将须要更新到地方设置为blank，而非直接更新其内容。