前端性能
1.模块化
严格来说，代码模块化并不能带来性能上的提升，但还是将模块化提出来，因为它真的很重要，重要到几乎所有的优化都与它息息相关.
常见的模块化方案有：AMD、CMD、UMD、ES6
如何选择？
团队习惯
个人偏好
业务需要
怎么把业务需要放在后一个考虑？
因为没有哪一块业务会因为使用了不同的模块化方案而产生不同的结果.
而且软件开发中的以人为本，用在这里刚好合适，毕竟业务高于一切.
2.缓存
缓存一定要加！
因为CDN真的很贵.
没有CDN？那就更得加缓存了！
缓存有很多方式，为常见的就是下面这两种了
浏览器304缓存
localstorage本地存储
业界，一直有关于304缓存与localstorage性能的争议，这里我们不讨论两者的差异，或性能问题.
以业务导向选择方案，瑞轩选择的是localstorage.
你可以这么干：
通过localstorage存储js、css资源；
资源版本控制；
只要你愿意，localstorage也可以控制缓存时间！通过写一小段js代码来实现；
在活动期间可以提前将活动相关资源缓存至localstorage，减轻活动当日的CDN消耗，同时在提升用户访问速度的同时，降低服务器端压力.
PS：localstorage针对开发环境确实有点不够接地气，不过你可以在框架底层写一小段代码来支持不同环境下的缓存控制，例如：针对开发环境域名，禁止缓存，针对某个URL参数禁止缓存等.当然，你也可以写一个chrome插件来控制缓存，高兴就好！
所以，瑞轩的建议是能使用localstorage就是尽量使用localstorage.如果你司没事也会搞一搞大促什么的，你就知道CDN有多贵了.
3.懒加载
图片懒加载
如果你是做Hybrid开发，这真的有必要！
JS懒加载
模块化带来的其中一个好处就是我们可以针对js资源进行懒加载控制，RequireJS、SeaJS？
这里我们采用的是RequireJS，要问我为什么，也许是因为我们使用的是AMD方案吧！
4.前端模板渲染
相比拼接字符串，jQuery.append，我们有了另一种选择，前端模板.
前端模板方案有很多.这里我推荐腾讯的tmodjs.他的优势在于可以将前端模板预编译成js文件，同时支持模块加载.
5.DOM怎么写很重要
浏览器有个机制叫做重绘，任何改变dom元素位置的操作都会引发浏览器重绘操作，这是无法避免的.重绘是浏览器性能优化的一个重点，特别是针对webview的优化.
既然我们不能避免，那么我们能够做什么呢？
虽然我们不能避免浏览器重绘的发生，但是我们可以通过精确的控制dom元素，来达到使浏览器的重绘范围小化的目的，这里我们可以借助浏览器的开发者工具针对页面进行调优.
客户端性能
代理webview发送ajax请求，据说这可以省去三次握手的时间？
iOS中使用WKWebView代替UIWebview，UIWebview是iOS8.0以前的产物，针对iOS8.0以后的系统建议使用WKWebView，经过实际测试，性能大概能够提升40%，同时稳定性有很大程度的提升，几乎是质的提升.
webview支持加载webp格式图片.
静态资源预加载，除了localstorage的缓存机制，我们也可以利用客户端针对前端静态资源进行缓存，在WIFI环境下，我们可以预先将静态资源下载至本地.
服务端性能
1.服务端渲染
在一个把前后端分离奉为宝典的时代，提一句服务端渲染显然是不合适的.
可是如果考虑到客户端弱爆了的Webview，也许这是一个不错的选择，毕竟服务端的性能要好很多.针对已经前后端分离的项目，我们建议可以尝试使用Node.js针对页面进行直出，也是一个不错的选择，Node.js的性能这里就不需要我累述了吧！
Bytheway，屏数据服务端输出，配上懒加载一起，不要太爽哦.
2.一个快速响应的接口
一个快速响应的接口真的很重要！
你可以通过优化代码，优化sql，优化缓存（redisOrmemcached？），优化Nginx配置？double服务器？
ComeOn总有点能做的！
总之，不要局限了自己.
3.图片转webp
由于webp格式的图片并不是所有环境都支持，这时候需要配合不同的客户端动态返回相应格式的图片.
