spa Appcache 方案 性能优化总结

1、背景

spa项目最大的特点就是js随着项目越来越大越来越多,导致拉取js的时间很长,虽然拉取过一次之后都有缓存,但是每次发布总会拉新代码,还是会拉取很慢尤其再网速慢的情况下,现在很多app都内嵌了h5 混合 js拉取慢导致了 app显示就慢 需要提高js加载新能。 虽然现在的spa可以通过拆路由懒加载等解决包太大的问题,但是效果还是不是很理想,当然最终的方案还得SSR啊。

2、一些常用的技术方案

· 减少请求

· 合并公共脚本

· 懒加载资源

· cdn

....

这些常用切正常的操作我们就不多说了 网上文章一大堆,今天来讲下 appcache 缓存解决方案。首先这套appcache的方案已经不推荐了但是这种强缓存的策略还是牛逼的 所以我们可以继续尝试下。

3、appcache方案

1、首先appcache 是离线缓存,即使你没网也会直接访问得到东西。

2、缓存严重也会有问题,比如更新了之后线上代码还是老的

先说下原理:

appcache缓存需要 一个

manifest="./service.appcache"

放到html的标签里面这些就是缓存清单的一些配置 。浏览器会根据清单里面的内容进行缓存。

由于是spa项目基本没有html代码 只有一小段 其他都是js跟css。由于html 是整个缓存的 有可能会缓存原来老的js 跟css 更新不及时的问题, 所以我们把js 跟css 全部放到一个js里面 通过这一个js去加载该版本的js跟css。并且每次版本迭代这个js的随机数都不一样可以保持代码不会错乱掉。

所以最终spa项目需要改2点。第一html模板生成需要把manifest appcache的缓存列表生成好,第二 统一脚本生成好,用来加载核心脚本,基本也就三个  第一 dll或者公共脚本 第二app.js 的入口脚本 第三app.css的公共样式,只需要这三个就行,因为懒加载的脚本是通过app.js入口定的,只要app.js 入口脚本加载好其他的脚本就会加载好。之后appcache会根据列表里面的缓存开始缓存脚本,其他之后的请求就会直接命中缓存。

总结:

1、生成缓存配置文件

2、生成统一拉取js css的核心脚本 带有版本号随机数

3、访问拉取 二次命中缓存 加载速度快

4、pwa也用了但是明显没有 appcache快,还有地段下serviceworks拉取本地脚本会失败的问题

5、缓存配置文件需要同源

6、生成appcache manifest 文件跟生成核心js的代码 可以用webpack或者gulp 按照打包工具不一样自己实现。


无标签
分享到: