最新消息:看到那些跳动的图片、文字了吗?点击点击 O(∩_∩)O~~

Web静态资源缓存、版本号

山外有山 onlyling 7644浏览

Web前端开发中有一个很有趣的东西,缓存,及惹人爱,又惹人厌。

为了响应时间减少,很多静态资源我们都会尽量缓存在浏览器中,避免http请求消耗时间,同时也减少了许多不必要的流量资源。

同样因为缓存的缘故,上线了新资源,可能用户开到或使用到的确实旧资源。例如可能造成了新html资源搭配就的css文件,页面就错位或新效果没起作用。

于是乎,我们理想状态是每次上线或更新,都是最新的。已访问过或无更新的时候,都从浏览器的缓存中取资源。

那么,我们就需要对静态资源进行一个版本控制,现目前比较多的方案是这两种。

例如 /mobile/app.js 这个资源。

方案一

给静态资源加一个查询参数,例如/mobile/app.js?v=20170101 ,每次上线修改后面的查询参数达到更新文件,同时需要服务器针对资源进行一个缓存时间的最大限制。

大体的原理是,服务器端针对资源进行了缓存时间限制,可能是一天,可能是一小时,可能是一年。每次请求同一个地址,第一次,哎哟浏览器里面没有,赶紧下载下来放好,第二次请求,服务器说,没有更新,你回去吧,第三次、第四次、第N次都是如此。当参数变化,就是一个新的请求地址,又重复以上循环,达到更新资源的目的。

有一个缺陷,那就是运营商的服务器可能缓存了资源,也即是并不是每次都是从自家服务器上取资源,也可能是从运营商服务器上面拿的。谁知道运营商服务器是怎么设置的呢?

方案二

给静态资源的文件名称增加md5,例如/mobile/app_374934637943.js,每次上线都是一个新的文件地址,完全不会和上一次版本有任何相似的地方。

这个方案在运行上没什么缺点,就是在发布上有点麻烦,需要在开发前期就要做好一个发布系统。另外,每次更新都是全部重新发布,一起打包发布,和传统的修改一个文件,替换一个文件不同。也不是所有文件都会重命名,只要文件没有修改过,那么md5号码就不会变,也就是说还是可以用原来的资源,只是新改动的资源更新了。

对比

没有对比就没有伤害,从来都是选适合的,而不是说最好的。

比如,我司在一些项目上,比较偏向传统,前端说话权不重,采取了方案一,临时单文件上线频繁、技术选型比较落后、后端开发人员改动前端代码等一些原因,没法做到前后端分离,如果使用一个发布工具,每次上线、修改等,都很繁琐,于是只有配合浏览器端的模块加载器做一些小动作,实现版本更新。在一些前后端分离的项目上,例如手机端,前端想怎么玩就怎么玩,采用了方案二。

转载请注明:OnlyLing - Web 前端开发者 » Web静态资源缓存、版本号