浏览器缓存机制

浏览器缓存机制

数据请求步骤：

• 网络请求

• 后端处理

• 浏览器响应

• 浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。

浏览器缓存机制

• 缓存位置
• 缓存策略
• 实际场景英语缓存策略

缓存位置

• Service Worker
• Memory Cache
• Disk Cache
• Push Cache
• 网络请求

Service Worker

Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。

实现缓存功能步骤：

• 注册 Service Worker

• 监听 install 事件，回调中缓存所需文件

• 拦截所有请求事件，如果缓存中已经有请求的数据就直接用缓存，否则去请求数据

  // index.js
  if (navigator.serviceWorker) {
    navigator.serviceWorker
      .register('sw.js')
      .then(function(registration) {
        console.log('service worker 注册成功')
      })
      .catch(function(err) {
        console.log('servcie worker 注册失败')
      })
  }
  // sw.js
  // 监听 `install` 事件，回调中缓存所需文件
  self.addEventListener('install', e => {
    e.waitUntil(
      caches.open('my-cache').then(function(cache) {
        return cache.addAll(['./index.html', './index.js'])
      })
    )
  })
  
  // 拦截所有请求事件
  // 如果缓存中已经有请求的数据就直接用缓存，否则去请求数据
  self.addEventListener('fetch', e => {
    e.respondWith(
      caches.match(e.request).then(function(response) {
        if (response) {
          return response
        }
        console.log('fetch source')
      })
    )
  })
  

• Service Worker 可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。

• 当 Service Worker 没有命中缓存的时候，我们需要去调用 fetch 函数获取数据。也就是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。

Memory Cache

• Memory Cache 也就是内存中的缓存
• 读取内存中的数据肯定比磁盘快。
• 但是内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了

Disk Cache

• 存储在硬盘中的缓存
• 读取速度慢点，但是什么都能存储到磁盘中
• 覆盖面是最大
  • 它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。

Push Cache

• Push Cache 是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。并且缓存时间也很短暂，只在会话（Session）中存在，一旦会话结束就被释放。
  • 所有的资源都能被推送，但是 Edge 和 Safari 浏览器兼容性不怎么好
  • 可以推送 no-cache 和 no-store 的资源
  • 一旦连接被关闭，Push Cache 就被释放
  • 多个页面可以使用相同的 HTTP/2 连接，也就是说能使用同样的缓存
  • Push Cache 中的缓存只能被使用一次
  • 浏览器可以拒绝接受已经存在的资源推送
  • 你可以给其他域名推送资源

网络请求

• 如果所有缓存都没有命中的话，那么只能发起请求来获取资源了。

缓存策略

• 强缓存
• 协商缓存

强缓存

• 强缓存可以通过设置两个HTTP Header实现：Expires和Cache-Control
• 强缓存表示在缓存期间不需要请求，state code为200

Expire 设置过期时间

Expires: Wed, 22 Oct 2018 08:41:00 GMT

• 表示资源会在Wed, 22 Oct 2018 08:41:00 GMT 后过期，需要再次
• Expire受限于本地时间，如果修改了本地时间，可能造成缓存失败

Cache-control

Cache-control: max-age=30

• Cache-Control 出现于 HTTP/1.1，优先级高于 Expires 。该属性值表示资源会在 30 秒后过期，需要再次请求。
• Cache-Control可以在请求头或响应头中设置，并且可以组合使用多种指令，以下是常见指令
  • public：表示响应可以被客户端和代理服务器缓存
  • private：表示响应只可以被客户端缓存
  • max-age=30：缓存30秒后过期，需要重新请求
  • s-maxage=30：覆盖max-age,作用一样，只在代理服务器中生效
  • no-store：不缓存任何响应
  • no-cache：资源被缓存，但是立即失效，下次会发起请求验证资源是否过期
  • max-stale=30：30秒内，及时缓存过期，也使用该缓存
  • min-fresh=30：希望在30秒内获取最新响应

协商缓存

• 如果缓存过期了，就需要发起请求验证资源是否有更新。
• 协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag 。
• 当浏览器发送请求验证资源时，如果资源没有改变，那么服务器就会返回304状态码（304 Not Modified)，并且更新浏览器有效期

Last-Modified和If-Modified-Since

• Last-Modified表示本地文件最后修改日期，If-Modified-Since会将Last-Modified的值发送给服务器，并询问服务器在该日期后资源十分有更新，有更新会将新的资源发送回来，否则返回304

Last-Modified弊端

• 如果本地打开缓存文件，即使没有对文件进行修改，还是会造成Last-Modified被修改，服务器不能命中缓存导致发送相同的资源
• 因为Last-Modified只能以秒计时，如果在不可感知的时间内修改完成文件，那么服务端会认为资源还是命中了，不会返回正确的资源
• 所有出现了ETag

ETag 和 If-None-Match

• ETag类似于指纹
• If-None-Match会将当前ETag发送给服务器，询问该资源Etag是否变动，
• 有变动的话将新的资源发送回来
• ETag优先级比Last-Modified高

如果什么缓存策略都没有设置

• 通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间。

实际场景应用缓存策略

频繁变动的资源

• 首先需要使用Cache-Control: no-cache使浏览器每次都请求服务器，然后配合Etag或者Last-Modified来验证资源十分有效
• 不能节省请求数量，但是能显著减少响应数据大小

代码文件

1. 这里特指除了 HTML 外的代码文件，因为 HTML 文件一般不缓存或者缓存时间很短。

• 一般来说，现在都会使用工具来打包代码，那么我们就可以对文件名进行哈希处理，只有当代码修改后才会生成新的文件名。基于此，我们就可以给代码文件设置缓存有效期一年 Cache-Control: max-age=31536000，这样只有当 HTML 文件中引入的文件名发生了改变才会去下载最新的代码文件，否则就一直使用缓存。