背景介绍
团队最近在招前端开发,早上收到一封简历,是个妹纸,从技能点来看还算符合要求,于是约了下午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,有意者可私信或投递简历。岗位介绍可点击 传送门。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。