网页的性能指标：
1. 首屏加载时长 （指页面可以看见，不一定可交互）
2. 网页的流程性（是否卡顿）
首先对浏览器有个基本认识：
① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流
② 浏览器在 document 下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染
③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高
前端优化，其实就几句话：
传输层面：减少请求数，降低请求量
执行层面：减少重绘&回流
衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化：
减少请求数
① 合并样式、脚本文件
② 合并背景图片
③ CSS3图标、Icon Font
降低请求量
① 开启GZip
② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码
③ 图片无损压缩
④ 图片延迟加载
⑤ 减少Cookie携带
很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如：
① 缓存为王，对更新较缓慢的资源&接口做缓存（浏览器缓存、localsorage、application cache这个坑多）
② 按需加载，先加载主要资源，其余资源延迟加载，对非首屏资源滚动加载
③ fake页技术，将页面最初需要显示Html&Css内联，在页面所需资源加载结束前至少可看，理想情况是index.html下载结束即展示（2G 5S内）
④ CDN
从工程的角度来看，上述优化点半数以上是重复的，一般在发布时候就直接使用项目构建工具做掉了，还有一些只是简单的服务器配置，开发时不需要关注。
可以看到，我们所做的优化都是在减少请求数，降低请求量，减小传输时的耗时，或者通过一个策略，优先加载首屏渲染所需资源，而后再加载交互所需资源（比如点击时候再加载UI组件），Hybrid APP这方面应该尽可能多的将公共静态资源放在native中，比如第三方库，框架，UI甚至城市列表这种常用业务数据。
拦路虎
有一些网站初期比较快，但是随着量的积累，BUG越来越多，速度也越来越慢，一些前端会使用上述优化手段做优化，但是收效甚微，一个比较典型的例子就是代码冗余：
① 之前的CSS全部放在了一个文件中，新一轮的UI样式优化，新老CSS难以拆分，CSS体量会增加，如果有业务团队使用了公共样式，情况更不容乐观；
② UI组件更新，但是如果有业务团队脱离接口操作了组件DOM，将导致新组件DOM更新受限，最差的情况下，用户会加载两个组件的代码；
③ 胡乱使用第三方库、组件，导致页面加载大量无用代码；
......
以上问题会不同程度的增加资源下载体量，如果听之任之会产生一系列工程问题：
① 页面关系错综复杂，需求迭代容易出BUG；
② 框架每次升级都会导致额外的请求量，常加载一些业务不需要的代码；
③ 第三方库泛滥，且难以维护，有BUG也改不了；
④ 业务代码加载大量异步模块资源，页面请求数增多；
......
为求快速占领市场，业务开发时间往往紧迫，使用框架级的HTML&CSS、绕过CSS Sprite使用背景图片、引入第三方工具库或者UI，会经常发生。当遇到性能瓶颈时，如果不从根源解决问题，用传统的优化手段做页面级别的优化，会出现很快页面又被玩坏的情况，几次优化结束后我也在思考一个问题：
前端每次性能优化的手段皆大同小异；代码的可维护性也基本是在细分职责； 既然每次优化的目的是相同的，每次实现的过程是相似的，而每次重新开发项目又基本是要重蹈覆辙的，那么工程化、自动化可能是这一切问题的最终答案
工程问题在项目积累到一定量后可能会发生，一般来说会有几个现象预示着工程问题出现了：
① 代码编写&调试困难
② 业务代码不好维护
③ 网站性能普遍不好
④ 性能问题重复出现，并且有不可修复之势
像上面所描述情况，就是一个典型的工程问题；定位问题、发现问题、解决问题是我们处理问题的手段；而如何防止同一类型的问题重复发生，便是工程化需要做的事情，简单说来，优化是解决问题，工程化是避免问题，今天我们就站在工程化的角度来解决一些前端优化问题，防止其死灰复燃。
资源加载
解决冗余便抛开了历史的包袱，是前端优化的第一步也是比较难的一步，但模块拆分也将全站分成了很多小的模块，载入的资源分散会增加请求数；如果全部合并，会导致首屏加载不需要的资源，也会导致下一个页面不能使用缓存，如何做出合理的入口资源加载规则，如何合理的善用缓存，是前端优化的第二步。
经过几次性能优化对比，得出了一个较优的首屏资源加载方案：
① 核心框架层：mvc骨架、异步模块加载器（require&seajs）、工具库（zepto、underscore、延迟加载）、数据请求模块、核心依赖UI（header组件消息类组件）
② 业务公共模块：入口文件（require配置，初始化工作、业务公共模块）
③ 独立的page.js资源（包含template、css），会按需加载独立UI资源
④ 全局css资源
这里如果追求极致，libs.js、main.css与main.js可以选择合并，划分结束后便可以决定静态资源缓存策略了。
资源缓存
资源缓存是为二次请求加速，比较常用的缓存技术有：
① 浏览器缓存
② localstorage缓存
③ application缓存
application缓存更新一块不好把握容易出问题，所以更多的是依赖浏览器以及localstorage，首先说下浏览器级别的缓存。
时间戳更新
只要服务器配置，浏览器本身便具有缓存机制，如果要使用浏览器机制作缓存，势必关心一个何时更新资源问题，我们一般是这样做的：
<script type="text/javascript" src="libs.js?t=20151025"></script>
这样做要求必须先发布js文件，才能发布html文件，否则读不到最新静态文件的。
一个比较尴尬的场景是libs.js是框架团队甚至第三方公司维护的，和业务团队的index.html是两个团队，互相的发布是没有关联的，所以这两者的发布顺序是不能保证的，于是转向开始使用了MD5的方式。
MD5时代
为了解决以上问题我们开始使用md5码的方式为静态资源命名：
<script type="text/javascript" src="libs_md5_1234.js"></script>
每次框架更新便不做文件覆盖，直接生成一个唯一的文件名做增量发布，这个时候如果框架先发布，待业务发布时便已经存在了最新的代码；当业务先发布框架没有新的时，便继续沿用老的文件，一切都很美好，虽然业务开发偶尔会抱怨每次都要向框架拿MD5映射，直到框架一次BUG发生。
seed.js时代
突然一天框架发现一个全局性BUG，并且马上做出了修复，业务团队也马上发布上线，但这种事情出现第二次、第三次框架这边便压力大了，这个时候框架层面希望业务只需要引用一个不带缓存的seed.js，seed.js要怎么加载是他自己的事情：
<script type="text/javascript" src="seed.js"></script>
//seed.js需要按需加载的资源 <script src="libs_md5.js"></script> <script src="main_md5.js"></script>
当然，由于js加载是顺序是不可控的，我们需要为seed.js实现一个最简单的顺序加载模块，映射什么的由构建工具完成，每次做覆盖发布即可，这样做的缺点是额外增加一个seed.js的文件，并且要承担模块加载代码的下载量。
localstorage缓存
也会有团队将静态资源缓存至localstorage中，以期做离线应用，但是我一般用它存json数据，没有做过静态资源的存储，想要尝试的朋友一定要做好资源更新的策略，然后localstorage的读写也有一定损耗，不支持的情况还需要做降级处理，这里便不多介绍。
Hybrid载入
如果是Hybrid的话，情况有所不同，需要将公共资源打包至native中，业务类就不要打包了，否则native会越来越大。
工程化&前端优化
所谓工程化，可以简单认为是将框架的职责拓宽再拓宽，主旨是帮业务团队更好的完成需求，工程化会预测一些常碰到的问题，将之扼杀在摇篮，而这种路径是可重用的，是具有可持续性的，比如第一个优化去除冗余，是在多次去除冗余代码，思考冗余出现的原因而最终思考得出的一个避免冗余的方案，前端工程化需要考虑以下问题：
重复工作；如通用的流程控制机制，可扩展的UI组件、灵活的工具方法 重复优化；如降低框架层面升级带给业务团队的耗损、帮助业务在无感知情况下做掉大部分优化（比如打包压缩什么的） 开发效率；如帮助业务团队写可维护的代码、让业务团队方便的调试代码（比如Hybrid调试）
构建工具
要完成前端工程化，少不了工程化工具，requireJS与grunt的出现，改变了业界前端代码的编写习惯，同时他们也是推动前端工程化的一个基础。
requireJS是一伟大的模块加载器，他的出现让javascript制作多人维护的大型项目变成了事实；grunt是一款javascript构建工具，主要完成压缩、合并、图片压缩合并等一系列工作，后续又出了yeoman、Gulp、webpack等构建工具。
这里这里要记住一件事情，我们的目的是完成前端工程化，无论什么模块加载器或者构建工具，都是为了帮助我们完成目的，工具不重要，目的与思想才重要，所以在完成工程化前讨论哪个加载器好，哪种构建工具好是舍本逐末的。