技术成就梦想

代码如诗

面试的妹纸问我:web缓存设置不是后台的事情吗?

2017年8月31日 Java 前端开发 架构 0

背景介绍

团队最近在招前端开发,早上收到一封简历,是个妹纸,从技能点来看还算符合要求,于是约了下午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就那么几个,业务/技术场景可能成百上千,这个时候,前端可以看作甲方,后台可以看作是乙方,需求只有前端知道。

写在后面

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

PS:云汉金融科技招聘前端开发人员,坐标深圳,年薪15w – 30w,有意者可私信或投递简历。岗位介绍可点击 传送门