性能的重要性不言而喻，需要申明的是，美團(tuán)今天不講業(yè)界最佳性能實(shí)踐，這些實(shí)踐已經(jīng)有很多沉淀，具體可以參考《高性能網(wǎng)站》和《高性能瀏覽器網(wǎng)絡(luò)》等書(shū)，另外，美團(tuán)不打算講性能優(yōu)化的結(jié)果指標(biāo)，比如頁(yè)面完全加載時(shí)間，首屏?xí)r間，結(jié)果指標(biāo)固然重要，是美團(tuán)工作成果的量化衡量，但是對(duì)于做性能優(yōu)化工作的工程師來(lái)說(shuō)，過(guò)程指標(biāo)對(duì)其起到的幫助作用更大。

既然不講最佳實(shí)踐，那講什么呢？美團(tuán)按最佳實(shí)踐提供的方法去實(shí)踐，但是后來(lái)遇到了瓶頸，到底遇到了什么瓶頸？美團(tuán)是如何突破這個(gè)瓶頸的？成效如何？這些對(duì)在座的各位又有什么借鑒意義呢？

遇到什么瓶頸？
在遇到瓶頸之前，美團(tuán)做了很多工作，主要包括：

簡(jiǎn)單的數(shù)據(jù)采集，包括完全加載時(shí)間，DomReady 時(shí)間，需要注意的是這些都是結(jié)果指標(biāo)；
依照“業(yè)界最佳實(shí)踐”快糙猛的做了很多事情：比如異步化，靜態(tài)化，LazyLoading，BigRender，這些實(shí)踐效果都還不錯(cuò)；
因?yàn)橹挥薪Y(jié)果指標(biāo)數(shù)據(jù)，這個(gè)階段美團(tuán)絕大部分決策都是基于別人的經(jīng)驗(yàn)，甚至拍腦袋，而不是基于應(yīng)用的實(shí)際性能細(xì)節(jié)數(shù)據(jù)；
快糙猛的方式注定不是可持續(xù)的，很快，美團(tuán)遇到了瓶頸，具體是什么瓶頸呢？

首先，如果把業(yè)界最佳實(shí)踐當(dāng)成燃料，而性能優(yōu)化當(dāng)成駕車(chē)遠(yuǎn)行的話，美團(tuán)的燃料很快就燒完了，因?yàn)榇蠹铱偨Y(jié)出來(lái)的通用的優(yōu)化手段總是有限的，而美團(tuán)的目標(biāo)還沒(méi)有達(dá)到；
其次，因?yàn)槊缊F(tuán)只采集了結(jié)果指標(biāo)，只知道整體表現(xiàn)如何，面對(duì)異常波動(dòng)美團(tuán)顯得特別無(wú)力，因?yàn)轱@示世界影響性能的因素太多了，對(duì)于到底發(fā)生什么事情了，美團(tuán)無(wú)從得知；
再次，由于對(duì)性能缺少內(nèi)窺，美團(tuán)無(wú)法找到更多的優(yōu)化點(diǎn)，實(shí)際上，美團(tuán)需要一個(gè)類似于顯微鏡的東西，來(lái)看看應(yīng)用內(nèi)部還有哪些可優(yōu)化的地方；

如何突破瓶頸？
面對(duì)這些瓶頸，美團(tuán)需要想辦法去突破它。在坐下來(lái)想辦法之前，美團(tuán)往后退一步，仔細(xì)考慮這樣一個(gè)問(wèn)題：美團(tuán)到底在優(yōu)化什么東西？是文檔的生成速度？頁(yè)面資源的加載速度？頁(yè)面的渲染速度？或者說(shuō)更高大上的用戶體驗(yàn)？這些問(wèn)題想清楚了，才能分析的更徹底。

其實(shí)，大多數(shù)的性能優(yōu)化工作都開(kāi)始于瀑布流圖的分析，下面美團(tuán)就來(lái)看看美團(tuán)項(xiàng)目詳情頁(yè)的瀑布流圖：

美團(tuán)把項(xiàng)目詳情頁(yè)的資源分為以下幾部分：

主文檔，即頁(yè)面的內(nèi)容，在拿到主文檔之前，瀏覽器啥都干不了；
核心 CSS，和首屏圖片，在拿到這些之后，瀏覽器可以開(kāi)始渲染了；
核心 JS，拿到這些內(nèi)容之后，頁(yè)面的交互被豐富，但是也會(huì)阻塞；
其他內(nèi)容，比如雪碧圖，統(tǒng)計(jì)腳本等；
從技術(shù)上來(lái)講，美團(tuán)優(yōu)化的就是這個(gè)瀑布流圖的每個(gè)環(huán)節(jié)，那么瀑布流圖的背后是什么？

其實(shí)就是頁(yè)面加載過(guò)程中各個(gè)資源的加載時(shí)間分解：從上到下的箭頭表示時(shí)間軸，從瀏覽器跳轉(zhuǎn)，緩存檢查，再到 DNS、TCP 建連，然后發(fā)起主文檔請(qǐng)求，再到接收完最后一個(gè)字節(jié)，再到瀏覽器開(kāi)始CSS、JS、圖片的下載，最后是頁(yè)面渲染和交互響應(yīng)。

根據(jù)《高性能網(wǎng)站建設(shè)指南》上的數(shù)據(jù)以及美團(tuán)的觀察，整個(gè)頁(yè)面的加載可以劃分為 3 大塊：網(wǎng)絡(luò)時(shí)間、后端時(shí)間、前端時(shí)間，發(fā)生在網(wǎng)絡(luò)和后端的時(shí)間占到整體加載時(shí)間的 10% 和 20%，而前端資源加載時(shí)間占到整體加載時(shí)間的 70% ~ 80%。

前端資源加載是否快速對(duì)性能影響是最大的，這里面資源的加載順序，并發(fā)數(shù)量，都有很多的工作可做：比如，如果你發(fā)現(xiàn) CSS 加載之前的阻塞時(shí)間很長(zhǎng)，那很可能是資源加載順序不合理，這必然會(huì)導(dǎo)致瀏覽器渲染延后。

頁(yè)面的加載時(shí)間還能分解的更細(xì)么？到目前為止，美團(tuán)都是站在瀏覽器的視角，劃清了各個(gè)環(huán)節(jié)。瀏覽器拿到文檔之前，是不會(huì)做任何事情的，后端響應(yīng)速度的變動(dòng)多數(shù)時(shí)候能引發(fā)性能上的蝴蝶效應(yīng)，美團(tuán)的突破口就在后端處理時(shí)間上：服務(wù)器收到請(qǐng)求之后，會(huì)經(jīng)歷請(qǐng)求分發(fā)、業(yè)務(wù)邏輯處理、文檔生成這三個(gè)階段，在業(yè)務(wù)邏輯處理階段，會(huì)涉及到和數(shù)據(jù)庫(kù)、緩存以及內(nèi)部服務(wù)的通信，拿到所有的數(shù)據(jù)之后，渲染模板，最后發(fā)送給瀏覽器。

對(duì)頁(yè)面加載過(guò)程中涉及到的所有環(huán)節(jié)進(jìn)行分解和細(xì)化，就形成了美團(tuán)的分析框架。

如何把控性能？
有了分析框架，那么如何全面的把控網(wǎng)站的性能呢？

基于這個(gè)框架，美團(tuán)通過(guò)統(tǒng)計(jì)腳本加上必要的數(shù)據(jù)統(tǒng)計(jì)（這里的統(tǒng)計(jì)都是過(guò)程指標(biāo)，只反映頁(yè)面加載過(guò)程中某個(gè)環(huán)節(jié)的健康狀況），就能獲得對(duì)整個(gè)網(wǎng)站的很多內(nèi)窺。

具體來(lái)說(shuō)，美團(tuán)對(duì)數(shù)據(jù)的要求是這樣的：整個(gè)流程各環(huán)節(jié)的，多維度（比如分頁(yè)面、分地理區(qū)域、分瀏覽器）的，實(shí)時(shí)的（方便美團(tuán)快速實(shí)驗(yàn)）。所有的數(shù)據(jù)都必須是能夠反映整體的統(tǒng)計(jì)量。

而對(duì)于統(tǒng)計(jì)腳本，需要滿足兩個(gè)條件：

避免對(duì)業(yè)務(wù)代碼的入侵；
不影響被測(cè)量的頁(yè)面的性能；
針對(duì)第 1 個(gè)要求，需要開(kāi)發(fā)獨(dú)立的統(tǒng)計(jì)腳本，避免其與現(xiàn)有的框架耦合，方便移植到其他項(xiàng)目；而針對(duì)第 2 個(gè)要求，需要在主文檔加載完畢之后，再注入統(tǒng)計(jì)腳本收集數(shù)據(jù)，并且盡可能的合并數(shù)據(jù)請(qǐng)求，減少帶寬消耗。

確定了數(shù)據(jù)統(tǒng)計(jì)腳本的約束條件之后，美團(tuán)從哪里得到這些數(shù)據(jù)呢？目前使用的主要途徑有：

主文檔加載速度，利用 Navigation Timing API 取得；
靜態(tài)資源加載速度，利用 Resource Timing API 取得；
首次渲染速度，IE 下用 msFirstPaint 取得，Chrome 下利用 loadTimes 取得，美團(tuán)的 Chrome 瀏覽器用戶占比超過(guò) 70%；
文檔生成速度，則是在后端應(yīng)用內(nèi)打點(diǎn)來(lái)獲得；
對(duì)于主文檔加載速度，美團(tuán)從宏觀到微觀的做了這樣的分解，從上到下的時(shí)間流，右邊的時(shí)刻標(biāo)記了每個(gè)指標(biāo)從哪里開(kāi)始計(jì)算到哪里截止，比如，跳轉(zhuǎn)時(shí)間 redirect 由 redirectEnd - redirectStart 計(jì)算得到，其他的類推：

采集主文檔加載速度的具體做法是：

在主文檔 load 之前提供可緩存數(shù)據(jù)的接口，方便在統(tǒng)計(jì)腳本載入前就可以準(zhǔn)備數(shù)據(jù)；
在主文檔 load 之后注入數(shù)據(jù)收集腳本，該腳本加載完成之后會(huì)處理所有的數(shù)據(jù)；
利用 Navigation Timing API 收集計(jì)算得到上圖中的指標(biāo)；
給所有數(shù)據(jù)打上頁(yè)面、地理位置、瀏覽器等標(biāo)簽，方便更細(xì)維度的分析；
對(duì)于靜態(tài)資源的加載速度，美團(tuán)也做了類似的分解和采集：

需要特別提示的是，如果你使用 CDN 的話，需要讓 CDN 服務(wù)商加上 Timing-Allow-Origin 的響應(yīng)頭，才能拿到靜態(tài)資源的數(shù)據(jù)。

而對(duì)于主文檔生成速度，美團(tuán)則開(kāi)發(fā)了性能統(tǒng)計(jì)的 Library，在框架級(jí)別集成后端性能的時(shí)間指標(biāo)。

實(shí)際效果如何？
通過(guò)上面的各種數(shù)據(jù)采集，美團(tuán)拿到了頁(yè)面加載全流程、全方位、多角度的真實(shí)用戶數(shù)據(jù)，有這些數(shù)據(jù)之后，美團(tuán)能做什么呢？之前遇到的瓶頸不再是瓶頸，因?yàn)槊缊F(tuán)可以利用這些數(shù)據(jù)做很多事情，下面舉幾個(gè)實(shí)際的例子：

Flush Early 是否有效？
《高性能網(wǎng)站進(jìn)階指南》上提到要盡快輸出文檔的第首字節(jié)提高性能，美團(tuán)很早的時(shí)候做了這個(gè)事情，但是從數(shù)據(jù)上看，在頁(yè)面完全加載時(shí)間上的收益不大，做了更細(xì)的數(shù)據(jù)采集之后，美團(tuán)快速的在線上做了這樣的實(shí)驗(yàn)：在特定頁(yè)面把 Flush Early 關(guān)掉，結(jié)果發(fā)現(xiàn)，瀏覽器接收到第 1 個(gè)字節(jié)的時(shí)間增加了 100+ms，如下圖（紅色箭頭表示變更上線時(shí)間點(diǎn)）：

而完成文檔傳輸?shù)臅r(shí)間減少了 150+ms，如下圖：

表面上看，似乎禁用 Flush Early 效果好些，但是再看看瀏覽器的首次渲染時(shí)間，增加了 300+ms，如下圖：

也就是說(shuō)，有些優(yōu)化措施，總結(jié)果指標(biāo)上看貌似沒(méi)啥效果，但是換個(gè)角度看效果非常明顯。有了全方位的數(shù)據(jù)，美團(tuán)能更高效的試錯(cuò)。

發(fā)現(xiàn)新的優(yōu)化點(diǎn)
為了優(yōu)化文檔生成速度，美團(tuán)一度想到優(yōu)化函數(shù)級(jí)別的調(diào)用，利用 FaceBook 的 HipHop 為 PHP 加速，通過(guò)數(shù)據(jù)發(fā)現(xiàn)，在美團(tuán)生成文檔的時(shí)間構(gòu)成中 30 %是在和緩存交互，這個(gè)比例太高了，當(dāng)優(yōu)化緩存服務(wù)器之后，后端時(shí)間大幅下降，緩存占比降到 10% 以下。

另外，美團(tuán)主站的迭代速度非?？?，每天大概 50 次左右的上線，通過(guò)數(shù)據(jù)發(fā)現(xiàn)，每次上線都會(huì)導(dǎo)致性能的輕微惡化，如果某天上線次數(shù)越多，那么性能就好不到哪里去？原因美團(tuán)合并了大量的 JS 請(qǐng)求，當(dāng)其中的某個(gè)模塊在某次迭代中被修改，整個(gè)合并的文件需要被重新下載，這就對(duì)模塊拆分和加載提出了更高的要求。

有了更細(xì)節(jié)的數(shù)據(jù)美團(tuán)能有效發(fā)現(xiàn)新的優(yōu)化點(diǎn)。

性能監(jiān)控平臺(tái)
美團(tuán)不光突破了之前遇到的瓶頸，實(shí)際上，美團(tuán)走的更遠(yuǎn)，因?yàn)槊缊F(tuán)覺(jué)得解決一個(gè)問(wèn)題不如解決一類問(wèn)題，美團(tuán)解決問(wèn)題的思路和工具同樣能適用于公司的其他產(chǎn)品線：于是美團(tuán)在做性能優(yōu)化的過(guò)程中逐步建設(shè)起來(lái)性能監(jiān)控平臺(tái)，目的是為公司的其他產(chǎn)品線和內(nèi)部系統(tǒng)提供一站式的性能數(shù)據(jù)收集、計(jì)算、存儲(chǔ)和展示服務(wù)。

目前性能監(jiān)控平臺(tái)已經(jīng)接入 20 余個(gè)公司內(nèi)部系統(tǒng)，能夠支持任意指標(biāo)、任意維度的實(shí)時(shí)數(shù)據(jù)查詢。該平臺(tái)為不同的項(xiàng)目提供了性能儀表盤(pán)功能，方便快速了解整體的性能狀況：

同時(shí)還為做性能優(yōu)化的工程師提供了簡(jiǎn)單的數(shù)據(jù)分析功能，方便其以數(shù)據(jù)驅(qū)動(dòng)的方式的開(kāi)展性能優(yōu)化工作：

總結(jié)
以上，就是美團(tuán)做性能優(yōu)化時(shí)遇到的問(wèn)題，以及解決的辦法，下面大概說(shuō)下，我對(duì)這些事情的總結(jié)：

首先，需要深入的剖析問(wèn)題，性能分析問(wèn)題的框架，讓很多死角暴露無(wú)疑；
其次，在性能優(yōu)化這件事情上，只關(guān)注結(jié)果指標(biāo)是不會(huì)給你多大幫助的，如果想真的優(yōu)化，你需要測(cè)量過(guò)程指標(biāo)，從過(guò)程指標(biāo)發(fā)現(xiàn)更多；
再次，解決一個(gè)問(wèn)題比如解決一類問(wèn)題，解決問(wèn)題的思路和工具可以沉淀下來(lái)，服務(wù)更多的團(tuán)隊(duì)和同事；