也会有团队将静态资源缓存至localstorage中，以期做离线应用，但是我一般用它存json数据，没有做过静态资源的存储，想要尝试的朋友一定要做好资源更新的策略，然后localstorage的读写也有一定损耗，不支持的情况还需要做降级处理，这里便不多介绍。

Hybrid载入

如果是Hybrid的话，情况有所不同，需要将公共资源打包至native中，业务类就不要打包了，否则native会越来越大。

服务器资源合并

之前与淘宝的一些朋友做过交流，发现他们居然做到了零散资源在服务器端做合并的地步了......这方面我们还是望洋兴叹吧

工程化&前端优化

所谓工程化，可以简单认为是将框架的职责拓宽再拓宽，主旨是

重复工作；如通用的流程控制机制，可扩展的UI组件、灵活的工具方法 重复优化；如降低框架层面升级带给业务团队的耗损、帮助业务在无感知情况下做掉大部分优化（比如打包压缩什么的） 开发效率；如帮助业务团队写可维护的代码、让业务团队方便的调试代码（比如Hybrid调试）

构建工具

要完成前端工程化，少不了工程化工具，requireJS与grunt的出现，改变了业界前端代码的编写习惯，同时他们也是推动前端工程化的一个基础。

requireJS是一伟大的模块加载器，他的出现让javascript制作多人维护的大型项目变成了事实；grunt是一款javascript构建工具，主要完成压缩、合并、图片压缩合并等一系列工作，后续又出了yeoman、Gulp、webpack等构建工具。

这里这里要记住一件事情，我们的目的是完成前端工程化，无论什么模块加载器或者构建工具，都是为了帮助我们完成目的，工具不重要，目的与思想才重要，所以在完成工程化前讨论哪个加载器好，哪种构建工具好是舍本逐末的。

理想的载入速度

现在站在前端优化的角度，以下面这个页面为例，最优的载入情况是什么呢：

以这个看似简单页面来说，如果要完整的展示涉及的模块比较多：

① 框架MVC骨架模块&框架级别CSS

② 几个UI组件（header组件、日历、弹出层、消息框......）

③ 业务HTML骨架

④ 业务CSS

⑤ 业务Javascript代码

⑥ 服务接口服务

上面的很多资源事实上对于首屏渲染是没有帮助的，根据之前的探讨，得出的理想首屏加载所需资源是：

① 框架MVC骨架&框架级别CSS => main.css+libs.js

② 业务入口文件 => main.js

③ 业务交互控制器 => page.js

有了这些资源，便能完成完整的交互，包括接口请求，列表展示，但若是只需要给用户“看见”首页，便能采用一种fake的手段，只需要这些资源：

① 业务HTML骨架 => 最简单的index.hrml载入

② 内嵌CSS

这个时候，页面一旦下载结束便可完成渲染，在其它资源加载结束后再将页面重新渲染即可，很多时候前端优化要做的就是靠近这种理想载入速度，解决那些制约的因素，比如：

CSS Sprite

由于现代浏览器的与解析机制，在拿到一个页面的时候马上会分析其静态资源，然后开线程做下载，这个时候反而会影响首屏渲染，如图（模拟2G）：

如果做fake页优化的话，便需要将样式也做异步载入，这样document载入结束便能渲染页面，2G情况都能3S内可见页面，大大避免白屏时间，而后面的单个背景图片便是需要解决的工程问题。

CSS Sprite旨在降低请求数，但是与去处冗余问题一样，半年后一个CSS Sprite资源反而不好维护，容易烂掉，grunt有一插件支持将图片自动合并为CSS Sprite，而他也会自动替换页面中的背景地址，只需要按规则操作即可。

PS：其它构建工具也会有，各位自己找下吧

CSS Sprite构建工具：https://www.npmjs.com/package/grunt-css-sprite

正确的使用该工具便可以使业务开发摆脱图片合并带来的痛苦，当然一些弊端需要去克服，比如在小屏手机使用小屏背景，大屏手机使用大屏背景的处理办法

其它工程化的体现

又比如，前端模板是将html文件解析为function函数，这一步骤完全可以在发布阶段，将html模板转换为function函数，免去了生产环境的大量正则替换，效率高还省电；

然后ajax接口数据的缓存也直接在数据请求底层做掉，让业务轻松实现接口数据缓存；

而一些html压缩、预加载技术、延迟加载技术等优化点便不一一展开......

渲染优化

当请求资源落地后便是浏览器的渲染工作了，每一次操作皆可能引起浏览器的重绘，在PC浏览器上，渲染对性能影响不大，但因为配置原因，渲染对移动端性能的影响却非常大，错误的操作可能导致滚动迟钝、动画卡帧，大大降低用户体验。

减少重绘、减少回流降低渲染带来的耗损基本人尽皆知了，但是引起重绘的操作何其多，每次重绘的操作又何其微观：

① 页面滚动

② javascript交互

③ 动画

④ 内容变化

⑤ 属性计算（求元素的高宽）

......

与请求优化不同的是，一些请求是可以避免的，但是重绘基本是不可避免的，而如果一个页面卡了，这么多可能引起重绘的操作，如何定位到渲染瓶颈在何处，如何减少这种大消耗的性能影响是真正应该关心的问题。

Chrome渲染分析工具

工程化其中要解决的一个问题是代码调试问题，以前端开发来说Chrome以及Fiddler在这方面已经做的非常好了，这里就使用Chrome来查看一下页面的渲染。

Timeline工具

timeline可以展示web应用加载过程中的资源消耗情况，包括处理DOM事件，页面布局渲染以及绘制元素，通过该工具基本可以找到页面存在的渲染问题。

Timeline使用4种颜色表示不同的事件：

蓝色：加载耗时 黄色：脚本执行耗时 紫色：渲染耗时 绿色：绘制耗时

以上图为例，因为刷新了页面，会加载几个完整的js文件，所以js执行耗时必然会多，但也在50ms左右就结束了。

Rendering工具

Chrome还有一款工具为分析渲染而生：