PC端支持到IE8，不支持则请求。
目前一个新项目准备这样架构，但隐隐担忧有什么致命缺点，因为现在还没有被广泛应用。
回复内容：
谢邀。经常用，所以过来回答一下。
我的看法是： PC上用的价值不大，移动端单页面应用(也有叫webapp)值得尝试。
这里要首先提出一个关于静态资源管理和SEO(搜索引擎优化)方面的关联问题： 如果要做SEO，那么CSS必然不能进行LS(localstorage)的本地缓存优化 。这个原因很简单：
要进行SEO，必须直接 输出完整HTML，因此必须让样式在头部以link标签加载。如果先 输出HTML，后用js从本地缓存读取样式再插入，会出现严重的阻塞和闪烁问题，相信正常人是不会这么干的。
然后再更正一件事，就是取出localstorage的代码不一定要eval，eval很evil，一个eval函数很有可能影响整个js文件的压缩（出现eval之后不能对变量名进行替换），当然，我们可以通过一些hack避免这种压缩问题，不过我喜欢这样搞：
var script = document . createElement ( 'script' );
var code = '!function(){' + getCodeFromLocalStorage () + '\n}();' ;
script . appendChild ( document . createTextNode ( code ));
document . head . appendChild ( script );
先说说主要会面临的问题1、执行速度，读取后使用eval或创建 标签的时间会比浏览器直接加载慢。
2、版本控制，需要自己写一套版本控制机制。
3、localStorage是公共资源，如果你的产品域名下有很多应用共享这份资源会有风险。
4、localStorage以页面的域名划分，而常见的静态资源都以资源本身的域名来缓存，意味着如果你的应用有多个等价域名，它们之间的localStorage不互通，会造成缓存多份浪费。
5、兼容性需要处理（不支持、隐私模式、写满、http/https、写的正确性等等）
=====================================
下面开始胡扯时间！
如果上述2、3、4、5你觉得都不是问题的话，1一定程度上是可以量化来评估的。
方案1：使用原始的缓存机制
做静态资源缓存率的收集得到比例：A%
完整请求所需时间：t0
304所需时间：t1
在使用浏览器内建机制的情况下代码执行所需时间：t2
那么使用浏览器内建机制所需的时间期望就是 ：T1 = t0 * (1-A%) + t1 * A% + t2
* 如果使用expires方式的HTTP缓存可以让t1为0
方案2：使用自定义的localStorage缓存机制
做localStorage缓存命中率测试得到比例：B%
在使用localStorage读取并执行的情况下代码执行所需时间：t3
使用localStorage的缓存命中情况比较复杂，可以稍微梳理一下：
1、B%概率命中localStorage，所需时间为t3
2、(1-B%)概率未命中localStorage，A%概率命中HTTP缓存，所需时间为t1 + t2
3、(1-B%)未命中localStorage，(1-A%)概率未命中HTTP缓存，所需时间为t0 + t2
其中2和3加起来就是(1-B%) * T1对吧
那么使用localStorage缓存机制所需的时间期望就是 ：T2 = t3 * B% + T1 * (1-B%)
* 上面忽略了localStorage缓存机制的加载器自己加载的时间、它的逻辑内部消耗和写入localStorage等时间。
不严谨，不过我觉得还是有参考价值的
从上面的两个时间上看，我们预期是T2 delta = T2 - T1 = t3 * B% - T1 * B% = (t3 - T1) * B%
因为B%肯定>=0，要让delta 其实说了这么半天，也就是楼上@小爝 所言
读localstorage再eval的速度比直接加载304缓存在当成js的执行速度要慢，而且不少……呵呵。。。浏览器都帮你缓存好了，干嘛多此一举缓存到LS里？
耗费成本是多少？解决了多少问题？价值几何？维护是否方便？是否简单易用？有足够的开发时间么？
如果你真的很闲，并且要炫酷吊炸天，搞起吧 https:// mtjs.github.io/
在快速迭代版本过程中，我们有时候只修改了某个js中的几行代码，却需要用户下载整个js文件，这在重视流量的移动端显得非常浪费，mt独创的增强更新算法实现了修改多少代码就只下载修改代码的功能，为用户和公司节省大量流量
localstorage里面存储的上个版本的js内容和版本号，当本次版本号和上次版本号不一致的时候，mt拼接出增量文件url去拉取增量文件，并和上个版本的js内容合并生成新版本内容。整个方案得核心在于增量文件得计算和合并
吊炸天 两年前看到这篇文章，有些启发： http://HdhCmsTest mobify测试数据/blog/smartph one-localstorage-outperforms-browser-cache
不过貌似现在这个网站有点问题，我贴几张文章中比较核心的数据比较图，两年前的文章了，不知道现在是否还适用：
20% trimmed mean results of native browser cache vs localStorage performance. Mean performance for localStorage is always faster than the browser's native cache and for iOS 5 & 6, dramatically so. 20% trimmed mean results of native browser cache vs localStorage performance. Mean performance for localStorage is always faster than the browser's native cache and for iOS 5 & 6, dramatically so.
stdDev 是标准方差的意思。
另外说到容量问题，之前貌似是5mb，不知道现在啥情况了- - 目前主流的网站的静态文件都使用了缓存，比如在 nginx 中只需要加几行配置就可以实现。只要浏览器不清空，某个固定链接的静态文件只需要加载一次。除非文件链接改变后，或者页面强制刷新，浏览器才会从服务器端重新读取静态文件。
从这个方面看，使用 localStorage 和传统缓存实际上是差不多的，并不能带来较明显的好处。另外还要考虑改造成本和兼容性等。
而一些移动站点（貌似包括腾讯首页）是使用 localStorage 来存储 js/css 静态文件，每次 js/css 升级时，只需要从服务器端获取一份包含静态文件变动信息的文件就好了。这样避免了静态文件升级一次，浏览器就要从服务器完整地加载一份新版本的静态文件。
如此采取 localStorage，可以为移动用户节省一些流量。
但是后面的这种方式有一定成本和门槛。
以上抛个砖。 是时候做广告了，基于localstorage的js存储更新解决方案，可以做到字符级别的资源增量更新：mtjs/mt · GitHub 偶凑热闹的，碎碎念几句。
首先不是移动端完全没有兼容问题，问题还是有的。
1、Safari 处于隐私模式时，LS set 数据会抛异常
2、不同移动端浏览器，对单次set数据大小是有区别的，印象（懒得换机器查PPT了）中是 3-5M 不等
3、不同移动端浏览器对LS总容量大小是有区别的，印象（懒得换机器查PPT了）中是 5-10M 不等（这里指的是单子域限制）
其次，IE 上可以封装userData作为兼容。
最后，关键不在于LS，而在LS的控制是个问题。
如：
1、一个项目，LS 任何人可CURD。其中值被其他功能修改以及删除很有可能，导致难查找的问题。
2、多人写LS，可能会写满，LS 总量控制如何监控，不超限
3、LS 过期问题，都写LS，过期机制是怎么样的，过期了优先删除哪些腾出空间
4、都没过期的情况下，有新数据进来，删除哪些腾出空间
5、如有LS控制器封装控制以上问题，但第三方代码（如接入的广告js）不使用控制器直接写LS如何处理 ls叫做本地存储，不叫本地缓存loadcache，还是有他一定道理的。证明他更多的作用在于存储数据，而不是缓存资源！HTML5针对缓存已经有了一套方案。其次，把js，CSS代码存在ls，意义不大。把其中的数值存在ls，意义会更大些。因为ls在用户浏览器中，有些交互体验的个性数值，你可以存在ls中。或者APP形式的页面更有意义了。把东西用得恰到好处，叫充分利用资源。避免弄巧成拙。 localStorage是一个js对象，而浏览器的缓存技术是基于浏览器的。
你说是js快还是浏览器快。
查看更多关于静态资源（JS/CSS）存储在localStorage有什么缺点？为什么没有被广泛应用？的详细内容...
声明：本文来自网络，不代表【好得很程序员自学网】立场，转载请注明出处：http://haodehen.cn/did66423