妹纸问：web缓存设置不是后台的事情吗？

背景介绍

团队最近在招前端开发，早上收到一封简历，是个妹纸，从技能点来看还算符合要求，于是约了下午3点过来面试。

整个面试过程持续了大约40分钟，问的题目也比较常规，其中一道题就是“常见的性能优化手段”。期间妹纸提到她看过《图解HTTP》，我就顺带问了下，“是否了解HTTP协议中常见的跟缓存相关的header”。

如果妹纸能够答上一两个，比如max-age之类的，基本这道题就放行了。不过妹纸的回复让我觉得有些意外：（字眼记不清了，大致这么个意思）

“web缓存设置不是后台的事情吗？”

为什么觉得web缓存设置是后台的事

妹纸的逻辑其实不难理解，因为web所需要的资源，如网页、JavaScript、CSS、图片等，都是放在服务器上的。而服务器大部分时候，要嘛是后台同学，要嘛是运维同学在管理，很多前端同学并没有多少机会接触到服务器，更别说上去对静态资源做缓存设置了。

相信不少前端新人也是这么认为的。已经记不清有多少次，在技术群里面，每当有人讨论HTTP协议等似乎跟前端“关系不是特别大”的内容的时候，总会有那么一两个群友怒气值满满地来上一句：

别老装逼成吗，前端不就写写网页切切图片，这些东西有毛用，又不能涨工资。

对于这种言论，我一般是选择潜水逃离，绝不恋战。

柳暗花明：凡事皆有因

对于这个“web缓存设置不是后台的事情吗”这个问题，我内心有自己的答案。

直接抛出结论容易，但并不意味着别人容易接受。于是我采取迂回战术，问妹纸：“你们的线上项目有没有设置缓存？”

妹纸的回答再次让我感到意外：

“没有，设置了缓存后，有用户访问到了错误的版本，所以没有设置缓存。”

从这回答可以大致判断，妹纸除了不了解缓存设置外，对于静态资源的版本控制应该也不熟悉。

我突然脑海中灵光一闪 —— 传教的机会到了。于是现场瞬间从面试模式切换到上课模式。

缓存设置带来的问题及解决方案

问题一：没有设置缓存会带来什么问题？

答：首先当然是性能问题。用户每次访问都需要重新访问服务器，用户访问速度、服务器负载堪忧。

其次是成本问题。用了云服务的同学应该了解，带宽跟流量都是用毛爷爷换来的。

问题二：是缓存导致了版本访问错误的问题吗？

答：从出错场景上来看，的确是缓存导致的。但缓存其实无辜的，罪魁祸首是不恰当的静态资源版本控制。

问题三：有什么解决方案？

答：首先对静态资源进行版本控制（比如给静态资源的文件名加上hash值），其次对网页设置合适时长的缓存时间（长短取决于实际场景）。这样就兼顾了版本升级和性能。

终极发问：web缓存设置真的只跟后台有关吗

看到这里，相信各位已经得出了自己的答案。

从前端开发的角度来看，对静态资源进行缓存设置，可以减少用户的访问耗时，提升用户的访问体验，在绝大部分时候都是基础而重要的优化。

那么，静态资源的缓存应该设置多长呢？永不缓存？10分钟？1小时？1年？。。。

其实并没有标准答案，很多时候，都取决于技术架构、业务场景。

比如：像上面妹纸提到的，她们没有做静态资源的版本控制，那么永不缓存也是可以接受的。毕竟很多时候，相对于性能不佳，用户对于服务出错的容忍度是更低的。

再比如：如果已经实现类似文件名加hash这样的版本控制方案，那么大可将JavaScript、CSS、图片等静态资源的缓存时间设置长一些，比如1个月；而网页的缓存时间可以短一些，比如每隔10分钟校验一次。

如果前端同学缺少对web缓存设置的了解，认为那是后台的事，那么很多时候就很难提出合理的技术方案。

退一万步讲，web缓存设置这件事假设就是由后台包办了（大公司里很有可能就是这样），那么缓存该怎么设置？其实最终还是由前端的场景说了算。缓存相关的header就那么几个，业务/技术场景可能成百上千，这个时候，前端可以看作甲方，后台可以看作是乙方，需求只有前端知道。

写在后面

前面啰啰嗦嗦讲了一大通，实际上这个问题只占了整个面试环节的很小一部分，当时也没有在这个问题上过于纠缠。只是觉得不少同学在类似的问题上存在一定的误区，觉得不吐不快。