前端拾遗--http-前端缓存

前端缓存

先简单介绍一下现有的前端缓存技术方案,主要分为http缓存和浏览器缓存。javascript

http缓存

http缓存都是第二次请求时开始的,这也是个老生常谈的话题了。无非也是那几个http头的问题:css

image

Expires

HTTP1.0的内容,服务器使用Expires头来告诉Web客户端它可使用当前副本,直到指定的时间为止。前端

Cache-Control

HTTP1.1引入了Cathe-Control,它使用max-age指定资源被缓存多久,主要是解决了Expires一个重大的缺陷,就是它设置的是一个固定的时间点,客户端时间和服务端时间可能有偏差。java

  • 因此通常会把两个头都带上,这种缓存称为强缓存,表现形式为:

Last-Modified / If-Modified-Since

Last-Modified是服务器告诉浏览器该资源的最后修改时间,If-Modified-Since是请求头带上的,上次服务器给本身的该资源的最后修改时间。而后服务器拿去对比。react

  • 若资源的最后修改时间大于If-Modified-Since,说明资源又被改动过,则响应整片资源内容,返回状态码200;git

  • 若资源的最后修改时间小于或等于If-Modified-Since,说明资源无新修改,则响应HTTP 304,告知浏览器继续使用当前版本。github

Etag / If-None-Match

前面提到由文件的修改时间来判断文件是否改动,仍是会带来必定的偏差,好比注释等可有可无的修改等。因此推出了新的方式。web

  • Etag是由服务端特定算法生成的该文件的惟一标识,而请求头把返回的Etag值经过If-None-Match再带给服务端,服务端经过比对从而决定是否响应新内容。这也是304缓存。

浏览器缓存

  • storage 简单的缓存方式有cookie,localStorage和sessionStorage。这里就不详细介绍他们的区别了,这里说下经过localStorage来缓存静态资源的优化方案。面试

  • localStorage一般有5MB的存储空间,咱们以微信文章页为例。算法

查看请求发现,基本没有js和css的请求,由于它把所有的不须要改动的资源都放到了localStorage中:

image

因此微信的文章页加载很是的快。

service workers

基本使用

  • 基本架构和生命周期

一般遵循如下基本步骤来使用 service workers:

  1. service worker URL 经过 serviceWorkerContainer.register() 来获取和注册。
  2. 若是注册成功,service worker 就在 ServiceWorkerGlobalScope 环境中运行; 这是一个特殊类型的 woker 上下文运行环境,与主运行线程(执行脚本)相独立,同时也没有访问 DOM 的能力。
  3. service worker 如今能够处理事件了。
  4. 受 service worker 控制的页面打开后会尝试去安装 service worker。最早发送给 service worker 的事件是安装事件(在这个事件里能够开始进行填充 IndexDB和缓存站点资源)。这个流程同原生 APP 或者 Firefox OS APP 是同样的 — 让全部资源可离线访问。
  5. 当 oninstall 事件的处理程序执行完毕后,能够认为 service worker 安装完成了。
  6. 下一步是激活。当 service worker 安装完成后,会接收到一个激活事件(activate event)。 onactivate 主要用途是清理先前版本的service worker 脚本中使用的资源。
  7. Service Worker 如今能够控制页面了,但仅是在 register() 成功后的打开的页面。也就是说,页面起始于有没有 service worker ,且在页面的接下来生命周期内维持这个状态。因此,页面不得不从新加载以让 service worker 得到彻底的控制。

下图展现了 service worker 全部支持的事件:

image

调试方法

一个网站是否启用Service Worker,能够经过开发者工具中的Application来查看:

具体使用

参考

外链

相关文章
相关标签/搜索