1. 對於首屏的靜態文件css/js,在上線前所有編譯直出到HTML文件中;整個首頁的渲染只須要一次請求;css
2.使用緩存;把不變的js/css/html所有存儲到localstorage中去,而後根據cookie中添加版本號的MD5值判斷是從服務器中更新仍是本地獲取;html
3.對於更多業務需求的js/css等靜態文件,經過一個接口所有返回;前端
4.DOM也緩存,咱們的模板和數據,也會被緩存至localstorage中;node
5.使用iconfontweb
6.卡片的異步加載與緩存segmentfault
7.不在首屏的就要異步化,採用按需加載,而不是伴隨首頁一塊兒加載緩存
8.少許靜態文件的域名,節省了DNS的解析性能優化
9.極小的圖片base64化,對於小於1k的圖片,咱們將其變爲base64編碼,並融入到css中,一塊兒換存到localstorage中去服務器
2、美團WebView性能優化cookie
1. 定義全局webView,減小webView初始化時間同時併發在Native本地去請求HTML頁面內容;
2.DNS解析優化,DNS採用和客戶端API相同的域名,DNS會在系統級別進行緩存;
3.同步渲染採用chunk編碼;
4.頁面框架渲染;
5.其它
3、蘇寧易購Hybrid架構設計方案
1.針對圖片的處理
樣式背景圖片處理和iconfont,以及base64圖片轉化的支持的
商品圖片處理,使用webp格式圖片
2.首屏
通用的處理方案:
域名收斂
html 文檔壓縮
靜態資源合併
首屏之外業務延遲加載,資源按需加載,圖片懶加載
雅虎軍規常規優化
3.開發方式對優化的影響
3.1 服務端輸出數據方式 :所謂的服務端輸出數據方式就是頁面的html 源碼包含了頁面全部的數據
3.2 接口數據渲染方式 :咱們把 html 看作一個模板,只有靜態的數據容器,全部的動態數據調用第三方接口利用 js 渲染成頁面;同時採用使用客戶端提供的原生方式請求接口,同時由於頁面是一個靜態模板容器,能夠把頁面引用的靜態資源打成 zip 包動態更新至客戶端,並支持增量更新的能力,當頁面模板或者模板內引用的靜態資源改變時,客戶端會提早下載增量包,html 模板和內嵌的靜態資源會提早經過客戶端下載到本地,用戶訪問頁面時就會從本地獲取加載資源,極大的減小了白屏的機率。
4. 兜底防災
5. 性能監控
4、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的總體架構
4、手機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.前端部署流程
5、手機淘寶架構設計
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 域名最終形態(建議)
2.4 動態數據複用狀態
2.5 預加載和離線化方案
2.6 統計方案優化
3.渲染優化
3.1禁止使用iframe (阻塞父文檔onload事件)
3.2禁止使用GIF圖片實現Loading 效果 (下降CPU消耗,提高渲染性能)視頻。
6、移動端架構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的架構如何優化演進?