记一次将请求改为协商缓存的艰难过程

Vgbire

于 2024-08-26 15:34:58 发布

阅读量113

点赞数 1

文章标签：缓存前端性能优化

本文链接：https://blog.csdn.net/RkHker/article/details/141565553

版权

简单回顾一下前端缓存策略 ⛏️

强缓存：在请求头规定的max-age和expirse过期之前直接读取本地缓存的资源，如果已经过期则调用协商缓存
协商缓存：也叫弱缓存，以下都称为协商缓存。协商缓存是缓存过期，刷新缓存时间或者文件更新，返回新文件的缓存阶段。
- 以下是协商缓存的过程：
- 前端首次请求文件、静态资源时，请求响应头带上Etag/Last-Modified请求头
- 告诉浏览器下一次同样的资源请求需要在请求头带上If-None-Match：值为上一个请求响应头的Etag，If-Modified-Since:值为上一个请求响应头的Last-Modified，服务器根据请求头的这两个字段匹配资源是否变更
- 如果未变更，他们的值应该是一样的，返回304即可。如果变更了，值不一样，返回200和新的资源内容
- 所以非首次请求资源才会带上If-None-Match/If-Modified-Since
- 但是响应头每次都会带上Etag/Last-Modified（文件、静态资源会自动携带因为可能需要缓存，json字符串接口不会自动携带，普通接口不需要也不应该缓存）
新手请记住强缓存和协商缓存容易混淆的地方，强缓存和协商缓存不是非我即他的两种独立使用的策略。而是包含关系的缓存策略。强缓存开启一定包含协商缓存，因为强缓存资源到期需要使用协商缓存刷新强缓存的缓存时间。
协商缓存的策略使用也是使用Cache-Control: max-ag=0（或者设置为no-cache）将强缓存时间设置为0强制开启协商缓存。强缓存和协商缓存可以理解为是前端缓存的不同阶段

需求背景 🔥

项目有一个全局请求配置文件的轮询接口，他会在发版时变更，轮询发现配置文件有变更则提示用户刷新页面，启用新版本。
但是有一天出BUG了，发版成功，但是客户端没有检测到版本变化。
打开Console控制台一看，原来接口被强缓存了，接口返回200（from disk cache），读取本地缓存文件肯定没有变化，检测不到发版更新。

开始爬坑 ✏️

开始发现问题是开启了强缓存，心想这还不简单，直接改为弱缓存解决，easy。
还是太年轻了🤡🤡🤡

查阅MDN将Cache-Control设置为no-cache即可开启协商缓存
这里注意一下，no-cache不是不使用缓存，是每次都去服务器验证一下资源是否变更，变更则返回200和变更后的资源，未变更则返回304使用缓存。no-store才是不使用缓存。

第一个坑：本地调试开启https没有合法证书缓存无效，本地改为http正常

查看请求，请求头加上了Cache-Control: no-cache，响应头也返回了Etag，但是没有返回304
但接口没有被缓存，依然每次直接请求服务器（304才是协商缓存，它返回了200）

第一个坑问题解决

 最后发现是本地当时开了https联调第三方https的接口，但是没有本地关联证书，裸奔https
 而浏览器不会缓存没有合法证书的https请求
 后面一次发到测试上发现缓存是有效的，线上是https有合法证书
 然后本地去掉https，缓存也有效了，🤮吐血，浪费了我好多时间

第二个坑：Cache-Control: no-cache缓存无效，需要改为Cache-Control: max-age=0

总所周知，程序解决了第一个坑，总会有第二个坑等着你

查看MDN、谷歌、百度看网友示例，设置为no-cache都可以开启协商缓存，但是我这里第二次请求没有带上弱缓存的请求头（If-None-Match/If-Modified-Since）
如下图所示(非首次请求截图)，Cache-Control为no-cache，响应头带上了Etag/Last-Modified，但是请求头没有带上弱缓存的请求头，接口直接返回200而不是304没有使用协商缓存
花了很多时间找不到答案，累了毁灭吧，又不是不能用，协商缓存可能也就快了一点点而已，折腾啥又不能涨工资，无所谓.jpg QAQ。

在我快要放弃的时候，我看到了可以试一下将Cache-Control设置为max-age=0，果然了就可以了

 max-age表示在给定的时间内(单位秒)使用强缓存，直接读取本地缓存文件
 超过时间则请求服务器验证文件是否变更

虽然对了，但为什么no-cache不行，我看MDN和别人的代码示例都说no-cache是可以，我认为实际上应该也是可以的，可能是中间网关做了什么处理？我也尝试过是否开启了Disable cache，但是我一直都是关的。百撕不得其姐，有没有懂哥赐教🫡（respect）！

问题来了，最开始的代码根本没有配置Cache-Control怎么默认开启了强缓存

又发现了一个奇怪现象，当我将Cache-Control请求头去掉，还原场景。获取该配置文件的接口刚开始还是304好好的，然后穿插了几个200强缓存（而且后面强缓存还变成连续的），然后又变成了304到底怎么回事？（该请求轮询时间是30s）
最后在知乎找到了答案，明明没有配置任何缓存策略，浏览器还是给我强缓存了？
大概意思是没有配置任何缓存策略时会启用启发式缓存，则缓存时间cacheTime为响应头返回的(Date-lastModified)*0.1，所以就会一开始都是304因为cacheTime很小马上就过期了（不够30s），当cacheTime随着时间推移（资源未被更改）会越来越大，超过轮询的30s就变成了200强缓存。然后变成2个连续的200强缓存。当这个资源10天都未更改，那么这个请求一天都是强缓存，然后造成了项目发版了，但是没有发版提醒的BUG。
前端福尔摩斯(自封)🧐

结论 🏆

协商缓存无效可能是本地开启了https，改为http
设置Cache-Control: no-cache可能无效，使用Cache-Control: max-age=0
此次爬坑其实对业务来说无关痛痒，因为根本都没有遇到性能问题，这点性能提升对用户来说也是无感知的，但是此次爬坑让我对前端的强弱缓存有了更深的了解，之前我的理解前端的强弱缓存因为需要依赖后端返回的Etag、Last-Modified字段，所以应该需要后端或者负责Nginx配置的运维去负责管理的，原来前端也可以进行控制。也算是不枉费自己瞎折腾吧。