前端效能
1. 模组化
严格来说，代码模组化并不能带来效能上的提升，但还是将模组化提出来，因为它真的很重要，重要到几乎所有的优化都与它息息相关.
常见的模组化方案有：AMD 、 CMD 、 UMD 、 ES6
如何选择？
团队习惯
个人偏好
业务需要
怎么把业务需要放在后一个考虑？
因为没有哪一块业务会因为使用了不同的模组化方案而产生不同的结果.
而且软件开发中的以人为本，用在这里刚好合适，毕竟业务高于一切.
2. 快取
快取一定要加！
因为 CDN 真的很贵.
没有 CDN？那就更得加快取了！
快取有很多方式，为常见的就是下面这两种了
浏览器 304 快取
localstorage 本地储存
业界，一直有关于 304 快取与 localstorage 效能的争议，这里我们不讨论两者的差异，或效能问题.
以业务导向选择方案，SEO 站群选择的是 localstorage.
您可以这么干：
通过 localstorage 储存 js 、 css 资源；
资源版本控制；
只要您愿意，localstorage 也可以控制快取时间！通过写一小段 js 代码来实现；
在活动期间可以提前将活动相关资源快取至 localstorage，减轻活动当日的 CDN 消耗，同时在提升多用户访问速度的同时，降低服务器端压力.
PS：localstorage 针对开发环境确实有点不够接地气，不过您可以在框架底层写一小段代码来支持不同环境下的快取控制，例如：针对开发环境域名，禁止快取，针对某个 URL 引数禁止快取等. 当然，您也可以写一个 chrome 外挂来控制快取，高兴就好！
所以，SEO 站群的建议是能使用 localstorage 就是尽量使用 localstorage. 如果您司没事也会搞一搞大促什么的，您就知道 CDN 有多贵了.
3. 懒载入
图片懒载入
如果您是做 Hybrid 开发，这真的有必要！
JS 懒载入
模组化带来的其中一个好处就是我们可以针对 js 资源进行懒载入控制，RequireJS 、 SeaJS？
这里我们采用的是 RequireJS，要问我为什么，也许是因为我们使用的是 AMD 方案吧！
4. 前端模板渲染
相比拼接字串，jQuery.WordPress 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 格式的图片并不是所有环境都支持，这时候需要配合不同的客户端动态返回相应格式的图片.