黑科技：LocalStorage 缓存机制

https://segmentfault.com/a/1190000013480580

事情的起因是我的同事金果问我：

- “你知道微信公众号文章的渲染方式吗？”

对此，我的反应是：

- “啊？”

金果继续问：

- “控制台的 Network 里没有发生任何请求，文章里的内容是怎么来的？”

说到这儿我好像大概理解她的意思，于是打开控制台的 Network 确认一下果真如此，文章中的内容并不是通过 http 请求获取的。

首先我想到的是：

- “会不会是服务器端渲染的？”

于是我找到请求得到的 html 文件却发现：

- “只有文章的标题是服务器端渲染的，那么文章的内容就只能在 js 文件中。”

我继续寻找请求得到的 js 文件却发现空空如也：

- “难道 js 文件都被缓存到 localStorage 里？！”

看到 Local Storage 里密密麻麻的 js 文件我心里一阵澎湃：这确实是一种可以尝试的前端加载性能优化的方式。

使用 localStorage 进行资源缓存的解决方案梳理缓存更新机制

我们不直接使用这个 value 动态插入 script 节点来加载该文件，而是根据后端提供的配置信息，判断是选择使用缓存的MOONpages/report.js文件，还是重新发起加载请求。

搭建更新代码的脚手架

（加载 combo 化）使用基于 localStorage 的缓存机制，就需要一个脚手架来管理资源文件的读取和写入，不难看出微信使用的是自己开发的脚手架moon.js，阅读其源码代价较大，暂不分析。

资源配置信息

前端在进行资源更新时需要后端提供一份依据供前端用于判断哪些资源需要更新，并且脚手架 moon.js 需要该资源配置信息才能正常工作，所以配置信息一定要在 moon.js 的 script 标签前输出：

存在 XSS 安全隐患

在MOONpages/report.js文件的入口处加入代码alert('Helo World');如图所示：

刷新页面后弹出提示 “Hello World”，说明使用基于 localStorage 的缓存机制存在一些安全隐患，并且微信尚未对这些攻击漏洞进行处理。

关于使用 localStorage 进行资源缓存其他思考

如果先输出 html 然后用 js 从本地缓存读取样式再插入会出现严重的阻塞和闪烁问题

这种解决方案更加适合单页面应用否则容易产生冗余

存在浏览器兼容性问题（隐身模式 etc.）（微信具有自己的X5内核完美解决该问题）

网络速度快，协商缓存的响应延迟可能比LS读取+eval更小

浏览器对于单次 set 和对 LS（本质是 SQL lite）的总容量存在限制

可以节省流量，并且可以用于 A/B test

移动端的浏览器缓存经常会被清理且网络状态通常较差，更加适合这种解决方案

https://github.com/scrat-team/scrat-site

https://github.com/mtjs/mt

最后突然想起一句话：不要指望代码能解决一切问题。

其它功能正在完善，不定期更新....

觉得本文对你有帮助？请分享给更多人

关注「前端大学」，提升前端技能