【译】-【缓存】最佳实践

本文译自: 这里

本文已同步到个人博客

引言

缓存利用得当的话，有很大益处，好比节省带宽，下降服务器压力等，可是不少网站没可以很好地利用缓存，形成一些相互依赖的资源出现不一样步的状况。

关于缓存的处理方案主要能够分为如下两种：

方案一：资源内容保持不变+超长的max-age

Cache-Control: max-age=31536000

• 这个url对应的资源永远保持不变
• 浏览器/CDN能够将该资源缓存好久
• 对于没有超过max-age的缓存内容能够直接使用，而没必要再向服务器请求

以下图所示：

在这种状况下，一个url对应的资源应该是一直保持不变的，若是咱们想更新资源，只能经过更改url的方式来实现：

<script src="/script-f93bca2c.js"></script>
<link rel="stylesheet" href="/styles-a837cb1e.css">
<img src="/cats-0e9a2ef4.jpg" alt="…">

能够看到，url中带有一串码，该码是与资源内容相关的，能够是版本号，修改日期，或者文件内容的hash值。

大部分服务器端的框架会有一些工具来让这件事情变得简单，

但是，这种方式并不适用于一些文章或者博客之类的网站，这些网站的url不能经过版本号来管理，并且内容也是常常须要改变的。

方案二：内容可变，每次都须要服务器再次校验（revalidated）

Cache-Control: no-cache

• 这个url对应的资源是可变的
• 本地缓存只有在服务器验证过是最新的以后才能够使用

（译者注：可参照304场景）

以下图所示：

注意：no-cache并非指不缓存，而是指在使用缓存以前，必须首先向服务器端确认资源是否为最新。
no-store指不容许缓存。一样的must-revalidate并不是是指必须从新验证，它的意思是，只有当本地的缓存已经超过最长缓存时间时，才须要从新验证。

在这种场景下，能够在响应头中添加ETag或者Last-Modified。这样，当客户端在下次请求的时候，就会在请求头中带上这些信息，分别对应的是If-None-Match和If-Modified-Since。服务器端根据该标识判断资源是否为最新的，若是是，则返回304状态码。

这种设置老是会须要一次网络请求的（来验证本地的缓存资源是否为最新），所以相比于第一种方式，增长了网络请求。