本文的主要内容包括：

1. DNS缓存机制，以及相关的优化方案
2. 浏览器缓存(http缓存)的机制和相关的性能优化点

之所以提及DNS缓存这一看起来与浏览器缓存关联不大的话题，是因为在这几次面试中缓存机制往往伴随着优化一并考察。而DNS往往是最容易遗漏，也是最容易形成首屏性能瓶颈的方面之一。

以某平台的列表页项目为例，在客户端请求阶段，DNS 查询时间大概是 385 ms，而一个请求下来大约是 1233 ms。这还是在强网（WiFi/4G）的情况下，弱网环境下所需要的的时间可能更多。假如能压缩DNS查询的时间，就可以立刻实现强网下秒开。

有dns的地方,就有缓存。浏览器、操作系统、Local DNS、根域名服务器，它们都会对DNS结果做一定程度的缓存。

DNS查询过程如下:

1. 首先搜索浏览器自身的DNS缓存,如果存在，则域名解析到此完成。
2. 如果浏览器自身的缓存里面没有找到对应的条目，那么会尝试读取操作系统的hosts文件看是否存在对应的映射关系,如果存在，则域名解析到此完成。
3. 如果本地hosts文件不存在映射关系，则查找本地DNS服务器(ISP服务器,或者自己手动设置的DNS服务器),如果存在,域名到此解析完成。
4. 如果本地DNS服务器还没找到的话,它就会向根服务器发出请求,进行递归查询。

DNS 之所以会成为前端性能瓶颈点，是因为每进行一次 DNS 查询，都要经历从手机到移动信号塔，再到认证 DNS 服务器的过程。这中间需要很长的时间。但用户是不想等待的。

想要节省时间，一个办法就是让 DNS 查询走缓存。而我们这几个环节能操控的就只有浏览器这一环节，浏览器提供了 DNS 预获取的接口，我们可以在打开浏览器或者 WebView 的同时就进行配置。这样真正请求时，DNS 域名解析可以检查一下浏览器缓存，一旦缓存命中，就不需要去 DNS 服务器查询了。

以上是淘宝网的dns-prefetch策略，DNS预解析在某个页面中包含非常多的域名非常有效，如搜索结果页。遇到网页中的超链接，从中提取域名并将其解析为IP地址，这些工作在用户浏览网页时，使用最少的CPU和网络在后台进行解析。当用户点击这些已经预解析的域名，可以平均减少200毫秒耗时（假设用户最近还未访问过该域名），更重要的是用户不会遇到DNS解析最坏的情况（往往超过1秒）。

DNS Prefetch 应该尽量的放在网页的前面，推荐放在 后面。具体使用方法如下：

预解析的实现：

1. 用meta信息来告知浏览器, 当前页面要做DNS预解析:
2. 在页面header中使用link标签来强制对DNS预解析:

dns-prefetch需慎用，多页面重复DNS预解析会增加重复DNS查询次数。

需要注意的是，虽然使用 DNS Prefetch 能够加快页面的解析速度，但是也不能滥用，因为有开发者指出 禁用DNS 预读取能节省每月100亿的DNS查询 。如果需要禁止隐式的 DNS Prefetch，可以使用以下的标签：

浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。

Cache-Control

最高优先级的缓存控制！

这是一个HTTP/1.1中规定的头字段，在请求和响应阶段哦付可以使用。但是缓存指令是单向的，这也就意味着在请求中设置的指令，不一定被包含在响应中。而再次强调：浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。

客户端可以在HTTP请求中使用的标准 Cache-Control 指令。

服务器可以在响应中使用的标准 Cache-Control 指令。

这一字段的具体配置规则如下：

可缓存性

public

表明响应可以被任何对象（包括：发送请求的客户端，代理服务器，等等）缓存，即使是通常不可缓存的内容。（例如：1.该响应没有指令或消息头；2. 该响应对应的请求方法是 POST 。）

private

表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。私有缓存可以缓存响应内容，比如：对应用户的本地浏览器。

no-cache

在发布缓存副本之前，强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证)。

no-store

缓存不应存储有关客户端请求或服务器响应的任何内容，即不使用任何缓存。

期限

max-age=

设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。与相反，时间是相对于请求的时间。

s-maxage=

覆盖或者头，但是仅适用于共享缓存(比如各个代理)，私有缓存会忽略它。

max-stale[=]

表明客户端愿意接收一个已经过期的资源。可以设置一个可选的秒数，表示响应不能已经过时超过该给定的时间。

min-fresh=

表示客户端希望获取一个能在指定的秒数内保持其最新状态的响应。

还有一些不是很常用的配置，可以参考MDN文档。

示例

以相对常用的为例，这一配置并不能按照字面意思理解。真正的禁止缓存是

指定 或 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性。这意味着每次都会发起 HTTP 请求，但当缓存内容仍有效时可以跳过 HTTP 响应体的下载。这样既可以保证内容的有效性，又可以保证能获取到最新的内容。

Expiers

这是一个HTTP/1.0的字段，定义了缓存到期的绝对时间。同样，我们也可以在html文件里直接使用:

如果当前时间已经超过了这个时间，就会重新向服务器请求。这一属性也是强缓存阶段的判断指标，但是有一个缺点——这是一个绝对时间，比较的对象是客户端时间。而如果客户端时间被调整，可能导致缓存失效。所以之前的就可以很好的解决这一问题。如果在max-age期限内，或者Expires时间未到，便会直接使用缓存的资源。

From disk cache 还是 From memory cache?

Chrome会根据本地内存的使用率来决定缓存存放在哪，如果内存使用率很高，放在磁盘里面，内存的使用率很高会暂时放在内存里面。这就可以比较合理的解释了为什么同一个资源有时是from memory cache有时是from disk cache的问题了。

而如果缓存已经过期，是继续使用缓存还是抛弃缓存重新请求呢？之前提到过可以设置，这样不是相当于缓存时即过期么？确实如此，所以此时需要和服务器通讯确定内容是否已更改，如果未更改可以继续使用缓存。这样只耗费了建立连接的时间，仍然节省了下载响应体的时间。

ETag/If-Match/If-None-Match

HTTP响应头是资源的特定版本的标识符。这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web服务器不需要发送完整的响应。而如果内容发生了变化，使用ETag有助于防止资源的同时更新相互覆盖（“空中碰撞”）。

可以在提交资源的时候用于检查是否未最新版本，以防空中碰撞（基于旧版本的修改覆盖了修改期间产生的新版本）

在请求时的值为之前的Etag值，服务器将客户端的ETag（作为If-None-Match字段的值一起发送）与其当前版本的资源的ETag进行比较，如果两个值匹配（即资源未更改），服务器将返回不带任何内容的304未修改状态，告诉客户端缓存版本可用。

Last-Modified/If-Modified-Since/If-Unmodified-Since

这三个的作用和Etag组合的类似，用于标识最后一个版本时间，确定最后一次更改时间以防空中碰撞，是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 响应。

而假如以上所有的缓存期限设置都不存在怎么办？比如：

启发式缓存机制会根据响应头中2个时间字段 Date 和 Last-Modified 之间的时间差值，取其值的10%作为缓存时间周期。

这就是启发式缓存阶段。这个阶段很容让人忽视，但实际上每时每刻都在发挥着作用。所以在今后的开发过程中如果遇到那种的坑，不要叫嚣，不要生气，浏览器只是在遵循启发式缓存协议而已。

有缓存

无缓存

是

否

是

否

是

否

文档无更新返回304

文档有更新返回200

缓存失效

浏览器请求

是否有缓存

是否过期

向Web服务器请求

上一次请求是否有Etag

从缓存读取

请求头携带If-None-Match

上一次请求是否有Last-Modified

请求头携带If-Modified-Since

服务器决策是200还是304

从缓存读取

请求响应+缓存协商

呈现页面

1. 问题：请求被缓存，导致新代码未生效

解决方案:

• 服务端响应添加指令；
• 修改请求头或；
• 修改请求URL，请求URL后加随机数，随机数可以是时间戳，哈希值，比如：http://damonare.cn?a=1234

2. 问题：服务端缓存导致本地代码未更新

解决方案：

• 合理设置Cache-Control:s-maxage指令；
• 设置Cache-Control:private指令，防止代理服务器缓存资源；
• CDN缓存可以使用管理员设置的缓存刷新接口进行刷新；

3. 问题： Cache-Control: max-age=0 和 no-cache有什么不同

回答：

和应该是从语气上不同。是告诉客户端资源的缓存到期应该向服务器验证缓存的有效性。而则告诉客户端使用缓存前必须向服务器验证缓存的有效性。