Velocity New York 2015 - 前端篇
這是一篇遲到的總結。2015 年 10 月有幸代表淘寶前端參加了 Velocity New York 性能大會，回來后馬不停蹄的忙完雙十一、雙十二兩個大促，終于有時間完成這篇總結。阿里每年都會參加將近 30 場國外會議，和前端相關的主要就是 Velocity（紐約）和 QCon（舊金山）了。這次紐約之行我們一共五人，分別來自 5 個不同的部門和崗位：前端、運維、中間件、測試、云計算。為期三天的會議每天都有至少 5 個會場同時開講，大家根據自己的方向分別選擇參加。先來幾張張會場照片。
分享介紹
一、 There is a client-side proxy (ServiceWorker) in your browser!
serviceWorker 是瀏覽器提供的一層 proxy，介于 renderer 和 network 之間擁有獨立的進程。所有的 request 和 response 都要經過這一層，但沒有操作 DOM 的權限。它可以通過 script 腳本來進行操作，可以加載、修改、緩存、管理所有的 request 和 response，看到這里是不是覺得想象空間非常巨大。直接上原 PPT 的大圖。
瀏覽器支持情況
目前支持最好的當然是 Chrome，下面是更詳細的瀏覽器支持情況：
- 需要瀏覽器原生支持 Promise：Chrome 36+、Firefox 29+、Opera 23+、Safari 7.1+、Edge
- ServiceWorker 支持：Chrome 、Firefox 、Opera 、Edge
- 調試支持：Chrome 40+、Opera </ul>
- 注冊 ServiceWorker，是一個異步過程，頁面不會被阻塞
- 幾個事件：
- oninstall：表示注冊成功，之后可以管理自己的 Cache 了，比如對一些 HTML，JS，CSS 資源文件進行預加載和緩存
- onactivate：在 ServiceWorker 創建成功后，并且所有之前的版本都不活躍時觸發，主要用來更新邏輯、凈化 Cache 。
- onfetch：render 發出的每一個請求都可以在這里被攔截，進行處理
- 完全控制 request 路由、cacheing、response 內容
- 按照需要修改 response 的內容
- 請求返回異常時，可降級到之前 cache 的較舊的數據
- 網絡處于離線狀態時頁面可用，直接調取 cache 的數據
- local template + remote data
- 在 ServiceWorkder 完成 HTML 片段的生成，減少數據傳輸量
- 可以是后臺生成、Node.js 生成、JS 生成的一個替代選擇
- 本地繪制圖片，減少服務器繪制圖片的資源消耗，只傳輸數據，由 ServiceWorker 完成。
- 類似的工作也可以由 SVG，Canvas 來實現
- 但 ServiceWorker 另一個特點是可以在瀏覽器啟動后在 background 運行，與瀏覽器插件的運行機制有些類似，既有當前頁面的運行時，又有瀏覽器啟動后的 background 運行時。
- 資源部分更新
- 比如 CSS 文件，30 天后的版本和之前版本可能 97% 是相似的，完全下載有較大的資源消耗
- 可以根據緩存中之前的版本，再獲取新舊版本間的 diff 數據，在 ServiceWorkder 更新后推給 render
- 預先加載下一個頁面的資源
- 知道下一個頁面的相關資源，在空閑時提前下載。當用戶點擊到下一個頁面時，網絡請求帶來的時間消耗可以極大的減少。
- 一些優化點方向：減少 cookie 大小、域名收斂、空閑時預加載、CSS 選擇器優化、web font 等
- 衡量標準：Chrome Dev Tools，Google PageSpeed 等可衡量的標準
- 工具自動化：將標準自動化執行，解放自己的雙手， http://www.webpagetest.org/ ， https://www.sitespeed.io/
- 首先制定標準，我們對所有影響性能的關鍵指標都進行了梳理，包含但不限于以下幾條，根據重要性都有不同的分數設定，檢查類目和評分標準必要時可以隨時調整
- 禁止發出 woff 字體請求
- 禁止發出 ttf 字體請求
- 接口請求數量檢查
- 圖片尺寸檢查
- CSS 數量檢查
- 圖片懶加載檢查
- 404 頁面檢查
- 首屏請求數量檢查
- 首屏請求大小檢查
- 圖片域名收斂檢查
- 圖片大小檢查
- 禁止使用 gif 圖片
- 禁止發出 woff 字體請求
- 一個頁面發布之前，強制自動跑分，滿足一定的分數才能發布上線。滿分 100，低于 93 分的頁面不允許發布。每不滿足一項扣減相應的分數，比如一個圖片鏈接沒有域名收斂扣 5 分，并且單項會重復累加積分，基本有 2 項不合格就無法發布。
- 真機測評，每次跑分都會隨機連接到一個真實的手機上跑分
- 所有的無線頁面在同一平臺發布，保證有統一的入口。這點很重要，這樣就可以在這個入口統一處理，保證所有頁面都通過測試驗證。另外一個好處是如果標準有調整也可以及時傳遞個開發人員，解決宣導不及時的問題。
-
首先是一些關鍵數據信息的展示，包含 Load Time、First Byte、Start Render、DOM Elements 等，最大特點就是會分 首次加載和再次加載的對比 。
-
和 Chrome 瀏覽器提供的瀑布流類似，每個請求的有詳細的不同階段占用時間對比，以及每個請求的 detail、request、response、object 信息。
-
必要的性能檢查，包含 Keep-Alive、Gzip、Compress Img、Progressive、Cache Static、CDN Detected。
-
Content Breakdown，不同類型資源的請求數、大小分析。
-
Domains，域名分析，域名越多消耗的 DNS 查詢時間就越長。
-
關鍵幀的分解圖，并可以錄制視頻
- 有首次加載和再次加載的全數據對比，性能優化更有針對性
- 所有的數據可保留，作為優化前后的對比依據，可以節約很多時間和資源
- 已有的最佳實踐檢測，比如請求是否全部 Gzip 壓縮、靜態資源是否全部 Cache、JPG 圖片優化等
- 非 Chrome 瀏覽器也可以跟蹤到，并按照 Chrome 的形式展現
- TCP Dump，可以下載相應的文件，進行分析。
- Processing breakdown。
- 包含主要 Thread 的消耗占比，消耗時間，如 Scripting、Layout、Painting、Loading 等；
- Processing Events 包含更細致的分類占比，消耗時間，如 FunctionCall、EvaluateScript、Layout、Program、CompositeLayer、ParseHTML、 RecalculateStyle、TimerFire 等、
- Trace，對應 Chrome://tracing 的功能。
- https://www.chromium.org/developers/how-tos/trace-event-profiling-tool
- It records C++ or JavaScript method signatures in a hierarchical view for each thread in each process.
- Net Log，對應 Chrome 的 network logging system。
如何使用
能做什么
二、 Modern performance best practices
性能的最佳實踐，主要分三個部分：
做為對照，簡單介紹一下淘系無線頁面的性能監控體系。
PS：關于監控，除了性能監控，還有 UI 監控（JS 錯誤檢測、靜態資源可訪問檢測、空鏈檢測等），前端單元測試（前端框架、核心邏輯、Node.js 測試等），感興趣的同學可以查看 淘寶前端團隊（FED）前兩天的文章。
三、 WebPageTest
這次 Velocity 分享中，基本上每個演講者提到性能分析工具的時候都會提到 WebPageTest。下面做一個簡單的介紹。
實例
下面以淘寶 PC 首頁為例，介紹一下 WebPageTest 的主要內容。PS：國外地址訪問淘寶和國內相比還是有相當差距的。
優點
個人認為最大的好處有下面幾點：
進階
WebPageTest 有很多更細致的配置選項，可以根據各自情況選擇。另外還有一些高端功能，需要注冊或者收費后才能使用，涉及的就是更專業、更深入的分析了。
四、基礎研究
歪果仁對于標準和基礎技術的研究熱情很高，相較于國內更加務實一些，這類分享大約占 1/4 的比例。
預處理： Resource hints
各種 W3C 標準的預處理，但不是所有瀏覽器都支持
<link rel=dns-prefetch > <link rel=preconnect crossorigin> <link rel=preload as=script> <link rel=prerender pr=0.8>
-
web font： The performance and usability of web fonts
- web fonts 加載完成后會導致已加載的 DOM 回流，解決方式有 2 個維度：
- 減少文件大小：no use no download；使用 woff 2 比 woff 小 30%
- 盡早的觸發 fonts 下載
- 但仍然無法根本解決延遲下載導致的回流問題，只是盡可能的將時間縮短。尤其是使用 iconfont 時，性能較低的機型會先展示一個方框，加載完后才顯示正確的圖形
- web fonts 加載完成后會導致已加載的 DOM 回流，解決方式有 2 個維度：
- flexbox： Better front-end performance with Flexbox
- flexbox 的性能，pageload 時間對比 float 快大約 40%，resize，scroll 時的性能消耗都有較大提升
- SVG： Tips for avoiding common SVG pitfalls
五、參會感受
- 阿里在前端性能方面的積累還是不錯的，很多大會中分享的方法、工具、理念都已經應用在我廠的日常工作中了。
- 性能提升的參與者越來越多，設計師也參與其中，從頁面的設計源頭屏蔽掉性能的潛在瓶頸，包括圖片的選擇、font 的處理，復雜設計對性能的影響，如何針對性能做設計決策，用戶主流程/視覺焦點的流暢性跟蹤、梳理等。
- 云服務大熱，很多圍繞云進行的生態系統建設，包括性能監控、分析、壓力測試、文件存儲、CDN 服務、發布&框架服務等。云服務 AWS 一家獨大，怪不得亞馬遜的股票蹭蹭的漲
- Docker 也很熱，雖然不了解，但還是在會場感受到了強烈的氣息。
Velocity北京 VS Velocity 紐約
淘寶前端團隊在北京也有一個 team（歡迎帝都的小伙伴們加入）。借助地利也參加了今年 8 月的 Velocity 北京會議。北京和紐約這兩場聽下來還是有很大的不同。
業務 VS 基礎
-
北京場注重業務結合，從業務瓶頸找到解決辦法。
-
紐約場注重基礎、標準。深入技術細節尋找最佳實踐。
大公司 VS 小團隊
-
北京場的演講者基本來自國內各大互聯網公司，包括 BAT、360、京東、58 等，其中阿里占到了 1/4。基本國內頂尖的互聯網公司都有參與。
-
紐約場的演講者則基本不是來自知名互聯網公司，只有一個來自 Google，還有就是 IBM、HP 這兩家。一方面可能是地處紐約，與硅谷和西雅圖相距太遠；另一方面可能是美國的創業環境優異，一批高成長的企業還不為國人所知，比如 Akamai 實際是 CDN 技術的發明者，并且是全球最大的 CDN 供應商。
封閉 VS 開放
-
北京場各大互聯網公司各自搭建的解決方案，相對來說還是比較封閉，目前只能供內部使用，定制化比較強。對外只能提供思路，無法提供服務。
-
紐約場的演講接近一半來自云服務商，每一項技術都能通過云服務，npm 等方式讓更多開發者使用并不斷改進（雖然很多是收費的）。
后記
- 地點：肯尼迪機場。一行五人，分批到達紐約，其中一組人出航站樓沒有看到 Taxi，打了一輛美帝的黑車，送達后收費 200 刀，實際應該 50 刀左右。
- 地點：時代廣場。一個小伙伴在時代廣場閑逛，一會近 10 個穿著各種造型的服飾的歪果仁要和他合影，美國人民好熱情啊，自我感覺相當棒。照相完畢每人要收費 10 刀，經過砍價最終花費 20 刀逃脫。
- 地點：時代廣場。拜訪了 MongoDB，MongoDB 是極罕見的把核心工程師團隊放在紐約曼哈頓中心的技術公司，辦公室就在時代廣場，樓上還有雅虎在紐約的辦公室！都是任性的主。MangoDB 目前一共就 500 人規模，在紐約有 150 來號人，其中大半是工程師。選擇時代廣場的很大原因是很多客戶都在這里（例如花旗銀行），相關的各種人才也非常多（這里應該不包含程序員）。