前端效能
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 格式的圖片並不是所有環境都支援，這時候需要配合不同的客戶端動態返回相應格式的圖片.