性能的重要性不言而喻，需要申明的是，美團今天不講業界最佳性能實踐，這些實踐已經有很多沉淀，具體可以參考《高性能網站》和《高性能瀏覽器網絡》等書，另外，美團不打算講性能優化的結果指標，比如頁面完全加載時間，首屏時間，結果指標固然重要，是美團工作成果的量化衡量，但是對于做性能優化工作的工程師來說，過程指標對其起到的幫助作用更大。
既然不講最佳實踐，那講什么呢？美團按最佳實踐提供的方法去實踐，但是后來遇到了瓶頸，到底遇到了什么瓶頸？美團是如何突破這個瓶頸的？成效如何？這些對在座的各位又有什么借鑒意義呢？
遇到什么瓶頸？
在遇到瓶頸之前，美團做了很多工作，主要包括：
簡單的數據采集，包括完全加載時間，DomReady 時間，需要注意的是這些都是結果指標；
依照“業界最佳實踐”快糙猛的做了很多事情：比如異步化，靜態化，LazyLoading，BigRender，這些實踐效果都還不錯；
因為只有結果指標數據，這個階段美團絕大部分決策都是基于別人的經驗，甚至拍腦袋，而不是基于應用的實際性能細節數據；
快糙猛的方式注定不是可持續的，很快，美團遇到了瓶頸，具體是什么瓶頸呢？
首先，如果把業界最佳實踐當成燃料，而性能優化當成駕車遠行的話，美團的燃料很快就燒完了，因為大家總結出來的通用的優化手段總是有限的，而美團的目標還沒有達到；
其次，因為美團只采集了結果指標，只知道整體表現如何，面對異常波動美團顯得特別無力，因為顯示世界影響性能的因素太多了，對于到底發生什么事情了，美團無從得知；
再次，由于對性能缺少內窺，美團無法找到更多的優化點，實際上，美團需要一個類似于顯微鏡的東西，來看看應用內部還有哪些可優化的地方；
如何突破瓶頸？
面對這些瓶頸，美團需要想辦法去突破它。在坐下來想辦法之前，美團往后退一步，仔細考慮這樣一個問題：美團到底在優化什么東西？是文檔的生成速度？頁面資源的加載速度？頁面的渲染速度？或者說更高大上的用戶體驗？這些問題想清楚了，才能分析的更徹底。
其實，大多數的性能優化工作都開始于瀑布流圖的分析，下面美團就來看看美團項目詳情頁的瀑布流圖：
美團把項目詳情頁的資源分為以下幾部分：
主文檔，即頁面的內容，在拿到主文檔之前，瀏覽器啥都干不了；
核心 CSS，和首屏圖片，在拿到這些之后，瀏覽器可以開始渲染了；
核心 JS，拿到這些內容之后，頁面的交互被豐富，但是也會阻塞；
其他內容，比如雪碧圖，統計腳本等；
從技術上來講，美團優化的就是這個瀑布流圖的每個環節，那么瀑布流圖的背后是什么？
其實就是頁面加載過程中各個資源的加載時間分解：從上到下的箭頭表示時間軸，從瀏覽器跳轉，緩存檢查，再到 DNS、TCP 建連，然后發起主文檔請求，再到接收完最后一個字節，再到瀏覽器開始CSS、JS、圖片的下載，最后是頁面渲染和交互響應。
根據《高性能網站建設指南》上的數據以及美團的觀察，整個頁面的加載可以劃分為 3 大塊：網絡時間、后端時間、前端時間，發生在網絡和后端的時間占到整體加載時間的 10% 和 20%，而前端資源加載時間占到整體加載時間的 70% ~ 80%。
前端資源加載是否快速對性能影響是最大的，這里面資源的加載順序，并發數量，都有很多的工作可做：比如，如果你發現 CSS 加載之前的阻塞時間很長，那很可能是資源加載順序不合理，這必然會導致瀏覽器渲染延后。
頁面的加載時間還能分解的更細么？到目前為止，美團都是站在瀏覽器的視角，劃清了各個環節。瀏覽器拿到文檔之前，是不會做任何事情的，后端響應速度的變動多數時候能引發性能上的蝴蝶效應，美團的突破口就在后端處理時間上：服務器收到請求之后，會經歷請求分發、業務邏輯處理、文檔生成這三個階段，在業務邏輯處理階段，會涉及到和數據庫、緩存以及內部服務的通信，拿到所有的數據之后，渲染模板，最后發送給瀏覽器。
對頁面加載過程中涉及到的所有環節進行分解和細化，就形成了美團的分析框架。
如何把控性能？
有了分析框架，那么如何全面的把控網站的性能呢？
基于這個框架，美團通過統計腳本加上必要的數據統計（這里的統計都是過程指標，只反映頁面加載過程中某個環節的健康狀況），就能獲得對整個網站的很多內窺。
具體來說，美團對數據的要求是這樣的：整個流程各環節的，多維度（比如分頁面、分地理區域、分瀏覽器）的，實時的（方便美團快速實驗）。所有的數據都必須是能夠反映整體的統計量。
而對于統計腳本，需要滿足兩個條件：
避免對業務代碼的入侵；
不影響被測量的頁面的性能；
針對第 1 個要求，需要開發獨立的統計腳本，避免其與現有的框架耦合，方便移植到其他項目；而針對第 2 個要求，需要在主文檔加載完畢之后，再注入統計腳本收集數據，并且盡可能的合并數據請求，減少帶寬消耗。
確定了數據統計腳本的約束條件之后，美團從哪里得到這些數據呢？目前使用的主要途徑有：
主文檔加載速度，利用 Navigation Timing API 取得；
靜態資源加載速度，利用 Resource Timing API 取得；
首次渲染速度，IE 下用 msFirstPaint 取得，Chrome 下利用 loadTimes 取得，美團的 Chrome 瀏覽器用戶占比超過 70%；
文檔生成速度，則是在后端應用內打點來獲得；
對于主文檔加載速度，美團從宏觀到微觀的做了這樣的分解，從上到下的時間流，右邊的時刻標記了每個指標從哪里開始計算到哪里截止，比如，跳轉時間 redirect 由 redirectEnd - redirectStart 計算得到，其他的類推：
采集主文檔加載速度的具體做法是：
在主文檔 load 之前提供可緩存數據的接口，方便在統計腳本載入前就可以準備數據；
在主文檔 load 之后注入數據收集腳本，該腳本加載完成之后會處理所有的數據；
利用 Navigation Timing API 收集計算得到上圖中的指標；
給所有數據打上頁面、地理位置、瀏覽器等標簽，方便更細維度的分析；
對于靜態資源的加載速度，美團也做了類似的分解和采集：
需要特別提示的是，如果你使用 CDN 的話，需要讓 CDN 服務商加上 Timing-Allow-Origin 的響應頭，才能拿到靜態資源的數據。
而對于主文檔生成速度，美團則開發了性能統計的 Library，在框架級別集成后端性能的時間指標。
實際效果如何？
通過上面的各種數據采集，美團拿到了頁面加載全流程、全方位、多角度的真實用戶數據，有這些數據之后，美團能做什么呢？之前遇到的瓶頸不再是瓶頸，因為美團可以利用這些數據做很多事情，下面舉幾個實際的例子：
Flush Early 是否有效？
《高性能網站進階指南》上提到要盡快輸出文檔的第首字節提高性能，美團很早的時候做了這個事情，但是從數據上看，在頁面完全加載時間上的收益不大，做了更細的數據采集之后，美團快速的在線上做了這樣的實驗：在特定頁面把 Flush Early 關掉，結果發現，瀏覽器接收到第 1 個字節的時間增加了 100+ms，如下圖（紅色箭頭表示變更上線時間點）：
而完成文檔傳輸的時間減少了 150+ms，如下圖：
表面上看，似乎禁用 Flush Early 效果好些，但是再看看瀏覽器的首次渲染時間，增加了 300+ms，如下圖：
也就是說，有些優化措施，總結果指標上看貌似沒啥效果，但是換個角度看效果非常明顯。有了全方位的數據，美團能更高效的試錯。
發現新的優化點
為了優化文檔生成速度，美團一度想到優化函數級別的調用，利用 FaceBook 的 HipHop 為 PHP 加速，通過數據發現，在美團生成文檔的時間構成中 30 %是在和緩存交互，這個比例太高了，當優化緩存服務器之后，后端時間大幅下降，緩存占比降到 10% 以下。
另外，美團主站的迭代速度非常快，每天大概 50 次左右的上線，通過數據發現，每次上線都會導致性能的輕微惡化，如果某天上線次數越多，那么性能就好不到哪里去？原因美團合并了大量的 JS 請求，當其中的某個模塊在某次迭代中被修改，整個合并的文件需要被重新下載，這就對模塊拆分和加載提出了更高的要求。
有了更細節的數據美團能有效發現新的優化點。
性能監控平臺
美團不光突破了之前遇到的瓶頸，實際上，美團走的更遠，因為美團覺得解決一個問題不如解決一類問題，美團解決問題的思路和工具同樣能適用于公司的其他產品線：于是美團在做性能優化的過程中逐步建設起來性能監控平臺，目的是為公司的其他產品線和內部系統提供一站式的性能數據收集、計算、存儲和展示服務。
目前性能監控平臺已經接入 20 余個公司內部系統，能夠支持任意指標、任意維度的實時數據查詢。該平臺為不同的項目提供了性能儀表盤功能，方便快速了解整體的性能狀況：
同時還為做性能優化的工程師提供了簡單的數據分析功能，方便其以數據驅動的方式的開展性能優化工作：
總結
以上，就是美團做性能優化時遇到的問題，以及解決的辦法，下面大概說下，我對這些事情的總結：
首先，需要深入的剖析問題，性能分析問題的框架，讓很多死角暴露無疑；
其次，在性能優化這件事情上，只關注結果指標是不會給你多大幫助的，如果想真的優化，你需要測量過程指標，從過程指標發現更多；
再次，解決一個問題比如解決一類問題，解決問題的思路和工具可以沉淀下來，服務更多的團隊和同事；
