前言

Web業務的性能優化是一個系統工程，既有深度，又有廣度。以下所簡稱性能均特指Web業務性能。
技術的廣度上，主要從大背景下考慮到其各個相關方，基于共同的數據指標發掘和評估方案。
技術的深度上是一個漸進和迭代的過程。可以從性能的本質展到目前各端的主要優化方向。

性能的本質

性能的本質是快速傳播, 要素是內容(數據)和流程，效果是：完備、快速。完備不是完整，而是接受的信息要一致，沒有歧義。流程是內容處理的過程和方法。

流程從廣義上看來源于后臺服務器，以網絡和客戶端為媒介，以頁面形式到達用戶。落到各端，又可以再次細分為不同的內容和流程，層層拆解。
性能優化就是保障快速傳播內容，可以概括為四個流程和三類方法。其中四個流程是指:

• 衡量: 設定指標，建立監控。
• 識別: 識別和梳理出整體到局部對各個層級的內容(數據)及流程。
• 實施: 針對性的進行優化。
• 評估和監控: 通過數據評估是否達成預期，并做定期監控。

各端實施前先理解全業務視角下的內容和流程，以及各自內部的內容和流程。以下為目前識別出的各端內容(數據)及流程:

各端內容(數據)流程

整體	頁面資源	后臺服務 (圖片服務) -> 瀏覽器(客戶端)
后臺	頁面資源 列表內容 頁端接口	1.架構 (接入/Docker/爬蟲/CDN) 2.發布上線流程 3.內容請求及響應流程(可繼續細分, 涉及部署) ……
圖片服務	圖片	1.圖片請求接口 2.圖片上傳發布 ……
頁端	主文檔 靜態資源 動態資源	1.前端渲染流程 2.模塊加載 3.懶加載 4.統計打點 ……
客戶端	統計數據	業務邏輯
Web Engine	頁面資源 后臺響應數據 網絡性能數據 統計數據	1.網絡連接 2.加載、解析、排版、渲染 3.JS執行 4.業務功能 (廣告過濾、后臺省流省電、統計……) ……

定義出各層各端的內容及流程后，就可以著手進行優化。

選擇優化時機

當我們發現一個問題點，如果確定是不是當時下手解決？　這個還需要在經驗中總結提煉．目前總結的原則有兩條:

• 優先解決關鍵路徑上的問題．
  
  • 如果解決的問題，不在關鍵路徑上，收益的評估可能不準，如果上線了，其實際效果也往往會被低估．如CSSOM優化．
  • 對于不確定的問題，可以使用小步快走的方式，進行快速驗證．如中轉直連策略．
  • 避免微優化。微優化往往會掩蓋一些更核心的問題。
• 綜合從各端和多維度考慮解決方案．
  
  • 如果單從一端或一點考慮優化，容易出現邊優化邊引入問題的情況．這時可以通過開放討論和實驗室驗證的方式減少影響．如頁面之前一次主檔精簡．

性能優化方法

性能的優化方法上可以概括為: 簡(化,減法)、分(離)、預(處理)三類。每一種方法都可以分別從內容和流程上展開典型的方法:

方法目標內容側流程側

簡化	盡量少(小)，直至沒有!!!	1.去除冗余信息 (請求頭，內容…) 2.去除無用的CSS/JS等資源 3.壓縮或裁剪 4.緩存及Combo可以減少請求 5.圖片優化圖片出口流量	1.去除不必要的處理和計算 2. 使用更好的處理算法 (查表) 3. 動態策略減少中轉或直連請求 4. 不必要的業務邏輯 5. 后臺優化存儲及服務器布署 6. SPA或模板的應用 7.PRPL原則的應用
分離	區分不同屬性，更加有針對性。	動態內容與靜態內容的分離 2. 首屏內容(資源)的分離 3. 主文檔與正文內容的分離 4. 概要內容（包括低質量圖片）與精細內容的分離	首屏渲染與懶加載 2. 同步請求改為異步請求 3. 前期不阻塞加載，中期不阻塞渲染 4.區分不同網絡的優化
預處理	重要的內容和事，提前準備。	1.預加載(主文檔及子資源) 2.預下發	1.預熱 2.預DNS解析 3.預連接 4.連接復用(包括HTTP2)

技術演進和整合

演進與迭代

從性能優化上，雖然概括了四個過程和三類的手法，但整體卻是一個由各端所在技術領域共同推動的迭代過程。
首先各端的技術領域有很大的交集，大致可以體現為:

但是各端所在的技術領域都有不同的技術演進，各自又都有相應的解決方案，其中以前端和瀏覽器內核的發展最為活躍,且有各有明顯的分段:

端技術要點

后臺	1.由于操作系統可以定制，一是借助Linux系統協議棧上的優化，包括HTTP2/QUIC，以及在TCP棧上的優化，二是改進TCP棧的性能、HTTPS的性能、通過改進壓縮算法提高數據傳輸性能等。 2.使用更加精細化的架構和系統來承載服務，同樣存在通過細化識別出優化點的過程，包括CDN的部署等。
頁端	自Steve Souders以YUI為始，定制了一套相關的基礎規則，包括了Head中的JS, CSS的位置，Cache、Cookies等，并且固化到了YSlow這個工具內。參考<<高性能建站指南>>。 后面又基于Web App發展趨勢而有了SPA (Single Page Application,也有稱為模板頁)模式。同時Responsive Web Design的提出，也有了一套相對應的優化策略。因為前端技術的發散和快速演進的特點，對于將工程化的需求更高。 FaceBook目前可以算是前端技術的領導者, 提出不少問題的前端技術方案，如Instant Article, Network Quality Classifier。特別是RN代表的native化方向，為前端技術應用帶來了更大的空間。
瀏覽器	瀏覽器的發展前以Firefox和WebKit為馬首，現以Chrome為主導。Chrome之前，瀏覽器側重于H5/CSS3/JS等技術體系的支持。自Chrome始，除了繼續將技術體系演進到Web Platform外，也再進一步將前端開發者的需求考慮到開發方向上來(見BlinkOn5資料)，以開發頁面的真實需求驅動Web Platform發展，演進了PWA, AMP等技術，也提出RAIL模型，來統一頁端和瀏覽器內核的目標。 在相同問題，Chrome和Facebook往往有不同的方案，比如AMP對應Instant Article, NQE對應Network Quality Classifier。與Facebook的Native化方向相比，Google則是以PWA(Progressive Web App)推動H5達成Native體驗。 針對頁端的YSlow, Chrome也在DevTools中提供更為強大的Audit (可以理解PageSpeed Insights增強版)，以及評價工具Lighthouse。在網絡的層面，和服務器不同的是，Chrome提出了HTTP2(SPDY)和QUIC (UDP)，解決網絡上問題。

從整體看瀏覽器和頁端的技術演進，我們可以看到兩個清晰的分段:

• 關注于單項(維度)技術的優化。往往可以從一個Check List的方式入手。比如: 優化點挖掘, 性能優化Check List。
• 體系化、多維度的技術創新。PWA和RN都不能算是技術創新，因為他們背后的技術原型都存在很久了，但是他們經過體系化后，被賦予了一個大愿景，再被不斷完善充實，解決一個普遍性的問題。
  *后臺(服務器側)因為個人能力和經驗的限制，沒有看到這個分界線。如果有，歡迎補充。

這兩個分段基本也對應到目前性能優化的迭代階段 (也可能各有若干迭代周期)：

• 基于現有技術架構進行各點(面)的優化。
  
  • 這是最重要的基礎，往往容易因關注新技術，而被忽略。從業務開發的角度，最好是從一開始就能應用工具和Check List不斷糾偏。
  • 這一階段的細化，可以參考: 項目總結 - 過程。
• 應用體系化的技術改造，突破技術瓶頸。

技術整合

雖然Facebook和Google Chrome在技術方向有不同的選擇，這是他們作為技術領導者的責任。但是從Web業務上看，技術整合才是必然的，包括Facebook和Google。一個代表前端有控制更多的需求，一個代表Web平臺，支持更多的控制，兩者的目標并不沖突。
從技術整合的角度來看，需要結合業務特點進行全局的技術方案評估和平衡。比如直出和前端渲染的選擇，就還需要考慮到業務單位間的協作和運營的需求。

SPA與模板頁

下面以SPA作為一個技術整合評估的示例。在實際業務場景，我們遇到了以下幾種提法:

• Single Page Application (SPA)
• 本地模板頁
• 主文檔緩存和#版本
  后者基本一致，SPA與他們的差別就在于可能不需要緩存來實現。所以后兩者可以理解為SPA的一種收益較大的實現。

它們的收益來源于：

• 主文檔緩存或本地模板頁減少主文檔請求和響應數據。
• 第二次從頁面內跳轉到新的內容，可以復用當前運行環境，包括已經在運行的JIT Code, 已經解析完成的CSS Rule Set等。

它們也有缺點:

• 主文檔緩存：考慮到改版， 需要使用條件請求，也就是仍然需要發送請求，只是響應在大多數情況會小很多。這個內核和頁端配合可以解決，頁端保證資源的一致性，內核則允許特定主文檔后置驗證。
• 本地模板頁: 同樣是改版的問題，只能是由客戶端自己管理了。另一個影響是性能數據可能無法正確收集。
  兩者是不是有絕對的性能優勢還取決于頁面的邏輯設計：即使主文檔本地化了，正文內容還是需要的，它的發送時間和響應的性能就成了關鍵因素了。

另外，復用運行環境的收益可以再放大。比如以類似預熱的思路，提前加載到空的WebView中，當實際需要請求時，通過#版本的方式就可以完成了。

所以收益最大的方案是四端技術整合:

• 頁端&后臺: 完成動態數據和靜態數據分離，提取出模板化的主文檔，并設計啟用304條件請求。
• 頁端: 同時支持?版本和#版本，確保主文檔和資源的一致性。
• 內核: 允許特定域名下的主文檔走后置驗證，而不是前置驗證。
• 客戶端: 利用預熱的機制，建立一個空白WebView加載主文檔。當用戶需要打開頁面時，切到已加載的WebView，并使用注入JS或#版本加載正文內容，也可以通過JSSDK向外殼直接取數據。

性能優化的方向

前面提到了目前可以確定的兩個迭代階段。我們現在還處于第一階段。借助U4可以將性能優化推進到第二階段，將各領域中體系化的技術加以評估、運用，　包括各端技術的深挖。
再往前一步，未來的頁面型態會不斷細分，相關的技術也會各有差異。我們可以先從業務類型區分開始，針對性的演進跨端的體系化方案。

對頁面分類，從性能優化角度看，最終以頁面在Web Platform（瀏覽器內核）上效果來體現．所以采用對內容(數據)和流程(行為)細化最為合理：

• 資源數
• 資源大小
• 多媒體資源占比
• 用戶所處的網絡環境
• 后臺服務器部署
• 動態資源大小及占比
• JS執行時間占比
• 渲染開銷
• 依賴于特定的技術
• ……

定出類型后，就可能對應運用簡分預挖掘優化策略。

總結

以上是生活随笔為你收集整理的Web业务性能优化技术总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。