web業務的效能優化是乙個系統工程，既有深度，又有廣度。以下所簡稱效能均特指web業務效能。
技術的廣度上，主要從大背景下考慮到其各個相關方，基於共同的資料指標發掘和評估方案。
技術的深度上是乙個漸進和迭代的過程。可以從效能的本質展到目前各端的主要優化方向。
效能的本質是快速傳播, 要素是內容(資料)和流程，效果是：完備、快速。完備不是完整，而是接受的資訊要一致，沒有歧義。流程是內容處理的過程和方法。
流程從廣義上看**於後台伺服器，以網路和客戶端為媒介，以頁面形式到達使用者。落到各端，又可以再次細分為不同的內容和流程，層層拆解。
效能優化就是保障快速傳播內容，可以概括為四個流程和三類方法。其中四個流程是指:
各端實施前先理解全業務視角下的內容和流程，以及各自內部的內容和流程。以下為目前識別出的各端內容(資料)及流程:
各端內容(資料)
流程整體
頁面資源
後台服務 (服務) -> 瀏覽器(客戶端)
後台頁面資源
列表內容
頁端介面
1.架構 (接入/docker/爬蟲/cdn)
2.發布上線流程
3.內容請求及響應流程(可繼續細分, 涉及部署)
……服務
1.請求介面
2.上傳發布
……頁端
主文件靜態資源
動態資源
1.前端渲染流程
2.模組載入
3.懶載入
4.統計打點
……客戶端
統計資料
業務邏輯
web engine
頁面資源
後台響應資料
網路效能資料
統計資料
1.網路連線
2.載入、解析、排版、渲染
3.js執行
4.業務功能 (廣告過濾、後台省流省電、統計……)
…… 定義出各層各端的內容及流程後，就可以著手進行優化。
當我們發現乙個問題點，如果確定是不是當時下手解決？ 這個還需要在經驗中總結提煉．目前總結的原則有兩條:
綜合從各端和多維度考慮解決方案．
效能的優化方法上可以概括為:簡(化,減法)、分(離)、預(處理)三類。每一種方法都可以分別從內容和流程上展開典型的方法:
方法目標
內容側流程側
簡化盡量少(小)，直至沒有!!!
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的部署等。
頁端瀏覽器
在網路的層面，和伺服器不同的是，chrome提出了http2(spdy)和quic (udp)，解決網路上問題。
從整體看瀏覽器和頁端的技術演進，我們可以看到兩個清晰的分段:
這兩個分段基本也對應到目前效能優化的迭代階段 (也可能各有若干迭代週期)：
應用體系化的技術改造，突破技術瓶頸。
雖然facebook和google chrome在技術方向有不同的選擇，這是他們作為技術領導者的責任。但是從web業務上看，技術整合才是必然的，包括facebook和google。乙個代表前端有控制更多的需求，乙個代表web平台，支援更多的控制，兩者的目標並不衝突。
從技術整合的角度來看，需要結合業務特點進行全域性的技術方案評估和平衡。比如直出和前端渲染的選擇，就還需要考慮到業務單位間的協作和運營的需求。
下面以spa作為乙個技術整合評估的示例。在實際業務場景，我們遇到了以下幾種提法:
本地模板頁
主文件快取和#版本
後者基本一致，spa與他們的差別就在於可能不需要快取來實現。所以後兩者可以理解為spa的一種收益較大的實現。
它們也有缺點:
另外，復用執行環境的收益可以再放大。比如以類似預熱的思路，提前載入到空的webview中，當實際需要請求時，通過#版本的方式就可以完成了。
所以收益最大的方案是四端技術整合:
前面提到了目前可以確定的兩個迭代階段。我們現在還處於第一階段。借助u4可以將效能優化推進到第二階段，將各領域中體系化的技術加以評估、運用， 包括各端技術的深挖。
再往前一步，未來的頁面型態會不斷細分，相關的技術也會各有差異。我們可以先從業務型別區分開始，針對性的演進跨端的體系化方案。
對頁面分類，從效能優化角度看，最終以頁面在web platform（瀏覽器核心）上效果來體現．所以採用對內容(資料)和流程(行為)細化最為合理：
定出型別後，就可能對應運用簡分預挖掘優化策略。
iOS 效能優化之業務效能監控
第一種 nsdate 精確度可能是微秒 s nsdate tmpstartdata nsdate date you code here.double deltatime nsdate date timeintervalsincedate tmpstartdata nslog cost time f ...
關於web前端效能優化總結
1 從dom結構和標籤上來優化 使用語義化的標籤，清晰簡潔 減少dom節點，增加渲染速度 使用w3c標準書寫閉合小寫的標籤 給和table指定寬高，避免縮放 css在頭部位置，js在body底部位置 2 從css樣式上來優化 使用link載入樣式而不是 import 是css2提供的一種方式，不相容...
Web效能優化
我們先來看乙個瀑布圖來確定乙個頁面效能問題是由哪些項造成的。chorome 自帶開發人員工具 圖中每一行表示乙個 請求，每乙個請求都有一條時間線，用於標識這個請求所花費的時間。如果將滑鼠放到某一條時間線上，可以看到以下資訊 1 首先看一下哪個請求花費的時間比較長，看看這個請求的時間線資訊，確定是伺服...