各大互聯網公司采取的策略
一、百度移動前端首頁
1. 對於首屏的靜態文件css/js,在上線前全部編譯直出到HTML文件中；整個首頁的渲染只需要一次請求；
2.使用緩存；把不變的js/css/html全部存儲到localstorage中去，然后根據cookie中添加版本號的MD5值判斷是從服務器中更新還是本地獲取；
3.對於更多業務需求的js/css等靜態文件，通過一個接口全部返回；
4.DOM也緩存，我們的模板和數據，也會被緩存至localstorage中；
5.使用iconfont
6.卡片的異步加載與緩存
7.不在首屏的就要異步化,采用按需加載，而不是伴隨首頁一起加載
8.少量靜態文件的域名，節省了DNS的解析
9.極小的圖片base64化，對於小於1k的圖片，我們將其變為base64編碼，並融入到css中，一起換存到localstorage中去
二、美團WebView性能優化
1. 定義全局webView，減少webView初始化時間同時並發在Native本地去請求HTML頁面內容；
2.DNS解析優化，DNS采用和客戶端API相同的域名,DNS會在系統級別進行緩存;
3.同步渲染采用chunk編碼；
4.頁面框架渲染；
5.其它
三、蘇寧易購Hybrid架構設計方案
1.針對圖片的處理
-
樣式背景圖片處理和iconfont，以及base64圖片轉化的支持的
-
商品圖片處理,使用webp格式圖片
2.首屏
通用的處理方案：
-
域名收斂
-
html 文檔壓縮
-
靜態資源合並
-
首屏以外業務延遲加載，資源按需加載，圖片懶加載
-
雅虎軍規常規優化
3.開發方式對優化的影響
3.1 服務端輸出數據方式 ：所謂的服務端輸出數據方式就是頁面的html 源碼包含了頁面所有的數據
3.2 接口數據渲染方式 ：我們把 html 看做一個模板，只有靜態的數據容器，所有的動態數據調用第三方接口利用 js 渲染成頁面；同時采用使用客戶端提供的原生方式請求接口，同時因為頁面是一個靜態模板容器，可以把頁面引用的靜態資源打成 zip 包動態更新至客戶端，並支持增量更新的能力，當頁面模板或者模板內引用的靜態資源改變時，客戶端會提前下載增量包，html 模板和內嵌的靜態資源會提前通過客戶端下載到本地，用戶訪問頁面時就會從本地獲取加載資源，極大的減少了白屏的概率。
4. 兜底防災
5. 性能監控
四、QQ空間移動時代Hybrid架構設計
1. 從加載速度來看Native比H5好在兩個地方 ：
1.1 首次加載速度可能相對比較快
1.2 二次加載體驗機制可以完爆H5，這里主要原因其實我們也看到就是緩存的邏輯
2. H5要趕超Native速度主要有兩個點：
1.1 首次進入的時候如何去提速；
1.2 有緩存的情況（例如你以前進入過了），怎么實現秒開的體驗，馬上能夠出來內容。
3. 傳統H5加載方案
3.1 把WebView啟動和發送請求改成並行
3.2 Socket通道
3.3 二次進入速度優化
3.4 E-Tag和Cache-Offline判斷頁面內容是否需要更新和離線緩存
3.5 優化后的雛形
-
並行加載；
-
HTML改成Socket通道去傳輸；
-
WebView的HTML頁面緩存管理；
3.6 增量更新和動靜分離方案
3.7 QQ空間最終版
H5的整體架構
四、手機QQHybrid架構設計
1.傳統方式
問題:
2.靜態直出+離線預推
問題表現：
產品經理肯定是在dataServer上配置最新數據信息，但CDN上的頁面內置的數據有可能仍處於上一版本，更差的情況是離線包服務器和offlineServer生成的HTML又是另外一個版本。當用戶本地的緩存和server同步不及時即常見的緩存刷新問題，很有可能存儲的數據又是另外一份
統一數據靜態文件直出：
關於offlineServer:
我們offlineServer內部分為流控和offline計算兩部分。當一個頁面的所有資源需要進行離線包計算打包的時候，offline計算這部分除了把所有的資源打包，內部也會存儲之前所有的歷史版本，同時根據歷史版本和最新版本生成所有的diff，即每個離線包的差樣部分。
3.動態配置
3.1 動態緩存
我們在這中間加上之前提到地類似offlineCache的中間層sonicBridge，這個中間層首先會從Node.js服務器下載完整的HTML給WebView，同時會把下載回來的內容在本地完整地做緩存。
3.2 減少傳輸數據 Node.js服務器並不會返回整個HTML給sonicBridge，而是返回給我們稱為data數據的部分。
3.3 減少提交頁面數據
4.QQHybrid架構
我們在WebScope的前端開發同學做了一部分工作；2. 我們的native層終端開發同學做了bridge橋接，3.我們后台的同學做了很多的自動集成和offlineServer推送等工作。
5.圖片優化
1.大家都比較熟悉WebP，而且Android對其支持也比較好，而QQ團隊內部自己研發了叫SharpP的圖片格式，在文件大小上能比WebP節省10%左右的體積。下面是抽取我們CDN服務器上已有圖片進行的數據比對。
2.針對不同的機型返回不同的圖片的大小
6.前端部署流程
五、手機淘寶架構設計
1.傳統優化
1.1 請求數優化
1.2 首屏多個動態接口合並請求
1.3 禁止重定向
1.4 圖片優化
1.4.1 使用webp圖片格式
1.4.2 根據q值 圖片銳化值 DPI返回對應的圖片大小和圖片優化處理
1.4.3 Sprite圖片
2.Native端的性能優化
2.1 HTTPDNS
2.2 SSL+SPDY協議
2.3 域名收斂
2.3.1 域名最終形態（建議）
- 頁面請求 域名一個
- 靜態資源（css，js） 一個
- 圖片資源 一個
- 動態數據一個
- 數據統計一個
2.4 動態數據復用狀態
2.5 預加載和離線化方案
2.6 統計方案優化
3.渲染優化
3.1禁止使用iframe （阻塞父文檔onload事件）
3.2禁止使用GIF圖片實現Loading 效果 （降低CPU消耗，提升渲染性能）視頻。
六、移動端架構H5優化總結
1.web端優化總結
1.1 請求數優化，首屏多個動態接口合並請求 ,禁止重定向,禁止使用iframe，禁止使用GIF圖片實現Loading 效果 （手淘）
1.2 通用優化方案 （蘇寧）
-
域名收斂
-
html 文檔壓縮
-
靜態資源合並
-
首屏以外業務延遲加載，資源按需加載，圖片懶加載
-
雅虎軍規常規優化
1.3 使用webp格式和iconfont等圖片優化方案 （手淘）
1.4 拆分頁面結構（動態數據和靜態存儲數據）充分使用localStorage存儲相關的數據；根據相關的版本MD5更新對應需要的動態模塊數據; （百度和手Q)
1.5 兜底容災
1.6 性能監控 + 測速監控
1.7 數據監控
2.Native端優化
2.1 添加本地Cache緩存策略，存儲對應的本地HTML/CSS/JS資源/圖片資源等；
2.2 全局WebView同時並發請求對應的H5首屏數據；
2.3 httpDNS,域名收斂 降低DNS解析的時間；
2.4 動態數據增量更新合並（手Q）
3.服務器端優化
3.1 添加nodeJS自動化構建服務,JS/CSS直出到HTML內容，同時服務器端渲染
3.2 采用socket通道以數據包的方式+離線預推的方式，將增量更新的數據提前下發到APP.然后app組裝好對應數據，供webView使用 (QQ空間)
文獻參考：
2. 70%以上業務由H5開發,手機QQ Hybrid的架構如何優化演進？
4.QQ空間面向移動時代Hybrid架構設計[視頻+演講稿]