前端静态资源部署

作者: anOnion | 来源:发表于2020-04-24 20:37 被阅读0次

    前几天厂里的网突然渣掉了,某些网页变得极度卡顿,但是划水网站依旧流畅;我觉得很有趣就打开 DevTools 对比了一下,结果看到某卡顿网页的 Network 状况如下,我大概猜到了一些缘由。这期就借机讲讲前端部署里的一些小技巧吧。

    Network

    原始前端

    OK,这期讨论的原始前端当然也没那么“原始”,我无意追述到 JSP,thymeleaf 这类传统后端渲染的技术。只是说“原始前端”开发比较简单,只需要一页文本编辑器,一份 html 模版和一款打包工具(webpack);部署更简单,webpack 构建并打包出 html、css、js,然后一股脑丢到服务器上就行。当请求到来时,服务器返回 index.html, 然后再把它的相关引用(js、css)返回给客户端即可。

    Server

    但是这里有个问题是,html 的引用文件名——onion.js——是固定的:一旦部署更新后,就得防止客户端缓存旧文件,所以一般会设置Cache-Control: no-cache。这就是文章开头提到的一个问题,每次打开页面都得重新加载一遍所有引用文件,一旦网络渣渣了,首页渲染就会十分缓慢。

    版本管理

    看样子缓存策略还是需要保留的,可如何兼顾更新呢?有人就想到了给引用路劲加个版本号:

    Version

    p.s. index.html 始终是 no-cache

    新版本上线后,浏览器请求 html,发现资源路劲更改了,便主动放弃相关缓存,重新加载引用文件。这个小小的改变很实用,兼顾了缓存策略和新旧版本文件冲突。至于这个版本号怎么添加,各色打包工具都能实现,最简单的策略就是在 index.html 模版里加个时间戳。

    摘要算法

    当然,随着业务增长,js 和 css 文件会变得愈发巨大,仅仅加载单个文件就可能需要数秒。遇到问题就解决问题,把大文件拆成小份就行了!利用浏览器有异步加载多个文件的机制,拆分 JS 迅速提速。(当然,浏览器并发加载数有限,拆太细会适得其反)。

    multi-link

    这时候有聪明人就发现了:每次更新时,某些 js 文件我并没有修改,为什么也要增加版本号呢?让客户无端加载一个一模一样的 js 文件,不是很浪费吗?

    反正版本号就是一个 unique 值——防冲突用的,不如换成别的数值吧?比如,经典的MD5(消息摘要)算法生成的content hash值,该哈希值与文件内容一一对应的,这就有了精确到单个文件的版本控制信息了。

    Content Hash

    我自己开发时,会利用 webpack 的 splitChunks 功能,把 Vue 全家桶打包成单个 js 文件、UI 框架也打包成单个 js;这种文件体积不小,但基本不会变动,cache-control/max-age可以写大一些,客户端除了首次访问会慢一点,其他时候基本就disk cache了。

    CDN

    上面提到服务器存放静态资源文件,但这种形式在性能上也有缺陷:

    • 受地理环境影响,离服务器越远资源加载较慢
    • 频繁请求资源对服务器压力较大

    为了进一步提升性能,大家开始把动态网页(index.html)和静态资源(js、css、image...)分开部署。静态资源被会放置于 CDN 上。

    CDN

    但是 CDN 也有缓存策略:新的静态资源发布后,需要一定的时间去覆盖各个边缘站点的旧资源。若某客户端获得了新的动态网页,但是附近的 CDN 节点尚未更新最近发布的静态资源,客户端即便放弃本地缓存,它加载到的依旧是位于 CDN 上的“脏数据”。怎么办呢?干脆把文件名也给改了——让摘要信息成为文件名的一部分!具体实现还是可以仰仗 webpack,将 output.filename 设为 [name].[contenthash].js,输出文件和 html 模版都会帮你更改好。

    Hash Name

    用摘要信息重命名后的资源文件,不再需要以覆盖旧文件的形式主动更新各个地区的边缘站点。新版本发布后,浏览器首次请求资源,若 CDN 不存在该资源,便会向就近的边缘站点加载该文件,同时更新 CDN 缓存;这样就彻底避免了 CDN 脏数据的问题。

    Build

    关于构建,我自己项目的做法是前端单独部署:git 接收 MR 后触发 AWS 的 code pipeline 和 code build;Webpack 自动打包生成dist文件夹(里面包含 html、js、css 等资源),html 部署到服务器上,其他静态资源发布到 CDN 上。这一套下来也不贵:一个月十几刀,每次部署也就几分钟。但是,但是!我后来看到有些厂的做法,觉得实在是太“抠”了——成本控制得真好!

    他们的做法是这样的:build 在开发环境就完成了,然后把打包生成的dist文件夹也 push 到 git 上。好处很明显:

    • 节省了一套 code pipeline + code build 的花费:大公司就不是一个月十几刀的事了
    • 大大缩短 build 时间:构建环境是不包含node_modules的,大型项目光npm install就要很久,build 时间更是感人

    而开发人员本地 build,可以很完美地绕开上面两个缺点。配置上写个 hook,在git commit时多加如下三个 changes 即可:

    modified: dist/index.html
    delete:   dist/garlic.6b58.js
    new file: dist/garlic.e5i1.js
    

    最后的牺牲只是 git repo 上包含了一个 dist 文件夹而已,真的是很“抠门”啊。

    小结

    这期内容很简单,讲了讲静态资源文件名的那些事,算是螺蛳壳里做道场吧。一直在想一件事,我们追求新技术的本质是什么?我觉得是降低成本!软件本质上还是属于“工业产品”的范畴,新闻上能看到一些重工业单位通过调整工艺大大降低成本的案例。我们做软件的也应该不断地调整工艺,降低成本、减少设备消耗,从而帮助公司赚取更多的利润。我曾看过有人形容软件开发就是一种缓慢地破坏+重建的过程,这种观点还是挺有道理的,分享给大家。

    相关文章

      网友评论

        本文标题:前端静态资源部署

        本文链接:https://www.haomeiwen.com/subject/cypqwhtx.html