Introduction Base64 is a collection of binary-to-text encoding schemes that are utilized to represent binary data in an ASCII string format through the translation of the data into a radix-64 representation. It uses the following alphabet to represent the radix-64 digits, alongside “=” as a padding character A-Z, a-z, 0-9, +, / In URLs, certain characters such as /, ?, and # have special meanings. To optimize the encoding of binary data in URLs, URL Base64 encoding replaces the characters + and / with – and _ to avoid characters that might cause problems in URL path segments or query parameters. Base64 encoding schemes are commonly used to encode binary data for…

强制缓存 强制缓存直接减少请求数，是提升最大的缓存策略。 强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程，强制缓存的情况有三种： 1、不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致），如下图： 2、存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存，如下图： 3、存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果，如下图： 强缓存规则 当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，告诉浏览器当前资源的缓存规则，控制强缓存的响应头字段分别是Cache-Control和Expires，其中Cache-Control优先级比Expires高。如果当前资源被缓存，则浏览器在下次发起请求时会从缓存中寻找资源。 协商缓存 控制强制缓存的响应头字段分别是 Etag和 Last-Modified，请求头字段是 If-None-Match 和 If-Modified-Since 。 每次请求需要进行缓存新鲜度校验。新鲜度校验通过请求头 If-None-Match 与响应头 ETag（由服务端生成） 进行对比，或请求头 If-Modified-Since 与响应头 Last-Modified 进行对比。 协商缓存就是强制缓存失效后（强制缓存时请求的缓存结果失效，只返回缓存标识），浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况： 协商缓存请求数上和没有缓存是一致的，但如果是 304 的话，返回的仅仅是一个状态码而已，并没有实际的文件内容，因此 在响应体体积上的节省是它的优化点。 1、协商缓存生效，返回304，如下： 2、协商缓存失效，返回200和请求结果结果，如下： Etag/If-None-Match Etag Etag是属于HTTP 1.1属性，它是由服务器（Apache或者其他工具）生成保存并返回给前端并，用来帮助服务器控制Web端的缓存验证。 Etag 的优先级高于 Last-Modified If-None-Match 如果If-None-Match传递给后台的缓存ETag值和后台对应该文件的ETag值一样，说明该缓存新鲜，服务器返回 304 状态码，浏览器使用本地缓存； 如果If-None-Match传递给后台的缓存ETag值和后台对应该文件的ETag值不一样，说明该缓存不新鲜，服务器返回更新的资源和新的 Etag值 Last-Modifed/If-Modified-Since的时间精度是秒，而Etag可以更精确。 Etag优先级是高于Last-Modifed的，所以服务器会优先验证Etag Last-Modifed/If-Modified-Since Last-Modified If-Modified-Since 如果If-Modified-Since值 就是 服务器端该文件的最新修改日期，说明缓存是新鲜的，服务器返回304，浏览器使用本地缓存； 如果If-Modified-Since值 小于 服务器端该文件的最新修改日期，说明缓存不新鲜，服务器返回新的该资源，并且更新该资源Last-Modified日期 使用场景 一般来说，我们对经构建工具打包后带有hash的资源进行一年的强制缓存 Cache-Control: max-age=3153600， 对于文件名不带hash的资源进行协商缓存或Cache-Control: max-age=较小值 或 Cache-Control: no-cache。 一种缓存策略是 index.html 适合走协商缓存，文件名带hash | 相对稳定 | 不常更新 的静态资源（JS、CSS、IMAGES） 等使用强缓存。 nginx 配置缓存策略 刷新页面跳过缓存 强制刷新的实现原理：设置 Cache-Control 为 no-cache 清空缓存并强制刷新的功能：清掉本地的缓存再去协商，能保证一定是拿到最新的资源 关于缓存的常见误区 上面提到的知识估计就是平时大家最常背到的，不过大家有没有认真想过一个问题？我们取到的缓存数据，一定缓存在浏览器里面吗？ 实际上是不然的：资源的缓存通常是有多级的，一些缓存专门用于单个用户，一些缓存专用于多个用户。有些是由服务器控制的，有些是由用户控制的，有些则由中介层控制。 另外，我们也经常会使用本地配置的代理，这些代理能够通过配置信任证书来缓存 HTTPS资源。