利用Localstorage对静态资源进行缓存的尝试
shellzhang
2015-07-24
1. 动机
2. 方案设计的考虑
3. 实现方案
4. 局限性
5. 以后的改进
动机
- 最大可能地减少HTTP请求
方案设计上的考虑
- 页面要预先处理,避免浏览器解析加载对应的资源
- 解析的过程交由前端js逻辑处理
- 静态资源跨域获取
- 不要破坏原先js处理顺序
- 不要破坏目前fis的编译逻辑
- 不要破坏目前开发的流程(开发过程无需localstorage)
预选方案
1. 通过FIS插件
优势
a. mod.js (v1.0.5)本身内建支持
b. 这个功能本身也属于fis应该做的
c. 不受后端语言变迁的影响
不足
a. 需要在前端处理各种兼容
http://caniuse.com/#search=localstorage
http://caniuse.com/#search=cors
b. mod.js仅对amd方式定义的模块进行cache,lib库下的不会处理(jquery.js, zepto.js等)
预选方案 (2)
2. 通过处理模板字符串
优势
a. 在服务器端通过UA即可判断基本的兼容性,进而按需替换字符串来处理,避免前端处理的延迟
b. 所有js资源都可以纳入缓存,包括lib库文件
不足
a. 依赖后端语言,语言更换对应逻辑要重写
b. hack行为,总觉得怪怪的,毕竟这个职责不属于后端
结论——此次还是采用了方案2,通过后端语言解决,比较方便快速出原型
方案实现
1. 字符串转换模块
ss_site/djangosite/neihan/search/views.py
def replace_script_tag_and_render
a. 浏览器版本检测
b. 开发环境与产品环境监测
c. async_load_script脚本解析并注入
2. 资源加载模块
site_fe/neihan_wap/page/in-app/async_load_script.html
a. 注意考虑脚本执行顺序
方案实现 (2)
3. 不足:
a. 目前前端模块没有考虑兼容性
b. localstorage存储时候,会出现资源项越来越多的问题,应该采用mod.js方式,将资源名作为key,版本号作为存储值的一部分
c. 模板中字符串替换操作应该交由前端发布流程来处理
未来的改进
1. 通过FIS插件来实现,并结合mod.js (v1.0.5)
2. 结合前后端来共同实现,确保兼容性与加载性能
2.1 FIS对模板解析时候,生成普通版本和localstorage版本
2.2 在服务端通过UA做一轮过滤,将不支持H5新特性的导入普通版本的模板;将支持的导入localstorage版本的模板
3. localstorage版本尽量只在app内的H5页面来应用(包括微信内的回流页等)。对wap页,还是回归自然的好,因为:
3.1 浏览器本身的刷新机制会被破坏,当遇到local资源出现异常,用户可能无法按照正常刷新方式获取服务器资源
3.2 各个厂商的浏览器实现机制不同,可能会存在不确定因素(localstorage的本地存储空间、同域不同域可用空间大小等)
Thanks~
利用Localstorage对静态资源进行缓存的尝试
By shellzhang
利用Localstorage对静态资源进行缓存的尝试
- 1,209