建站
咨詢
售后
建站咨詢
新聞中心
正在閱讀這篇文章的你，或多或者接觸過前端性能優(yōu)化，這樣的接觸可能是來自你的閱讀體驗(yàn)也可能是來自工作經(jīng)驗(yàn)。那我們不妨從一個(gè)非常簡單的思想實(shí)驗(yàn)開始，請你借助你對這個(gè)領(lǐng)域的理解，來回答下面的幾個(gè)問題：
- 假設(shè)現(xiàn)在由你來主導(dǎo)一項(xiàng)優(yōu)化公司站點(diǎn)性能的工作，你會選取哪些指標(biāo)用于衡量性能？
- 假設(shè)你選取了某個(gè)或者某幾個(gè)指標(biāo)納入到監(jiān)控的范疇內(nèi)，當(dāng)頁面性能出現(xiàn)問題時(shí)，你是否能通過它們及時(shí)發(fā)現(xiàn)問題？
- 假設(shè)你發(fā)現(xiàn)某個(gè)頁面的性能出現(xiàn)了問題需要立刻修復(fù)，這幾個(gè)指標(biāo)能否幫助你快速定位問題？
不要有壓力，你可以慢慢思考并回答這幾個(gè)問題，你關(guān)于第一個(gè)問題的答案可能會隨著二三問題的出現(xiàn)而不斷的調(diào)整。
這篇文章的目的就是對上面三個(gè)問題的探索和嘗試性的解答，希望我的答案能帶給你一些啟發(fā)。
一次復(fù)盤
目前我所在的項(xiàng)目上長時(shí)間都依賴都 GA (Google Analytic) 作為衡量頁面性能的唯一工具，在 GA 的生態(tài)圈中，我們最為重視的是 Avg Page Load Time (以下簡稱為 APLT)，通過它來斷定我們站點(diǎn)當(dāng)前的性能狀態(tài)如何。
但是在定期收集該指標(biāo)數(shù)據(jù)的過程中，我們發(fā)現(xiàn)用戶的感受和數(shù)據(jù)的展示可能并不一致，具體來說數(shù)據(jù)看上去波瀾不驚，但用戶體驗(yàn)卻直線下降。
所以我們不得不要回答一個(gè)至關(guān)重要的問題，APLT 衡量的究竟是什么？
什么這個(gè)問題之所以至關(guān)重要，是因?yàn)樗拇鸢笡Q定我們接下來要解決的問題和需要采取的行動：
- 為什么 APLT 衡量的結(jié)果與客戶感受到的不一致？差距在哪里？差距有多少？
- 每當(dāng)數(shù)值出現(xiàn)波動時(shí)，我們會下意識的懷疑是前端腳本拖慢了性能，但腳本對這個(gè)指標(biāo)影響有多少？我們的懷疑是否有道理？以及是否存在其他的可能性？
- 如果 APLT 變慢了？有哪些可能導(dǎo)致 APLT 變慢？這決定著我們排查問題的方向。
- 如果 APLT 不夠準(zhǔn)確，我們需要自定義指標(biāo)重新衡量性能結(jié)果，我們能從中吸取什么經(jīng)驗(yàn)？我們的指標(biāo)可否與 APLT 產(chǎn)生聯(lián)動產(chǎn)生一加一大于二的效應(yīng)？
然而官方文檔對于這個(gè)指標(biāo)的解釋是很曖昧的：
Avg Page Load Time : The average amount of time (in seconds) it takes that page to load, from initiation of the pageview (e.g., click on a page link) to load completion in the browser.
Avg. Page Load Time consists of two components: 1) network and server time, and 2) browser time. The Technical section of the Explorer tab provides details about the network and remaining time is the browser overhead for parsing and executing the JavaScript and rendering the page.
對于它的解釋，我們產(chǎn)生了幾點(diǎn)疑問：
- “l(fā)oad completion”是如何被定義的？之所以要回答這個(gè)問題是因?yàn)樗亲鳛橹笜?biāo)衡量的終點(diǎn)而存在。
- server time 僅僅包含一切靜態(tài)資源嗎？異步請求會被計(jì)算在內(nèi)嗎？
GA 的實(shí)現(xiàn)
GA 底層是通過 Navigation Timing API 在采集性能數(shù)據(jù)：
GA 不會統(tǒng)計(jì)每一個(gè)階段的數(shù)據(jù)，它將某些合并后重新命名成新的指標(biāo)，而其中的某些指標(biāo)比如 Document Interactive Loaded 其實(shí)是某些階段的統(tǒng)計(jì)之和：
GA 統(tǒng)計(jì)的僅僅是與 DOM 文檔有關(guān)的數(shù)據(jù)。APLT 定義里所說的 load completion 時(shí)刻指的就是 loadEventEnd 事件的發(fā)生時(shí)機(jī)，即 onLoad 事件觸發(fā)完畢(load 事件觸發(fā)時(shí)意味著所有的外部資源，包括 iframe、圖片、腳本、樣式都已經(jīng)加載完畢)。所以 APLT 值是 GA 里所有指標(biāo)里橫跨時(shí)間范圍最廣的。
腳本對 Avg Page Load Time 的影響是什么
如上圖所示，當(dāng)瀏覽器自上而下解析 DOM 樹時(shí)，它會遇見很多外聯(lián)資源，比如圖片、樣式和腳本。于是它需要從緩存或者網(wǎng)絡(luò)中請求這些資源。
頁面的解析是同步的，所以腳本的加載會導(dǎo)致頁面解析的暫停。瀏覽器需要在腳本加載、編譯、執(zhí)行完畢之后才會繼續(xù)之后的解析工作，這么做是有道理的，因?yàn)?JavaScript 可能會使用諸如 document.write() 方法來改變 DOM 的結(jié)構(gòu)。你可能聽說過在 script 標(biāo)簽上添加 async 或者 defer 屬性來異步的加載和執(zhí)行腳本。但是它在我們的產(chǎn)品中是不適用的，因?yàn)?async 無法保證腳本執(zhí)行的順序。但這則方案不一定適用于所有頁面，因?yàn)?async 無法保證腳本的執(zhí)行順序，如果你的應(yīng)用對腳本的執(zhí)行順序有嚴(yán)格要求，那么它對你愛莫能助。
目前瀏覽器都配備preloader機(jī)制來提前掃面頁面中的外聯(lián)元素提前加載，但這個(gè)機(jī)制并無統(tǒng)一的標(biāo)準(zhǔn)也無法衡量效果，所以暫時(shí)不考慮它對我們的影響。
腳本下載之后需要經(jīng)過解析(parse / compile)和執(zhí)行(run / execute)。解析階段首先將 javascript 代碼編譯為機(jī)器語言，執(zhí)行階段才會真正的運(yùn)行我們編寫的代碼。腳本的解析和執(zhí)行也會阻塞頁面的解析
所以綜上，我們可以得出腳本確實(shí)能夠影響 APLT 。
但拋棄計(jì)量談危害都是刷流氓，它的影響范圍究竟有多大?也就是說如果 APLT 是 2 秒的話，其中多少時(shí)間耗費(fèi)在了腳本上？
這里沒有一個(gè)具體的數(shù)字，但它不容小覷，以及足夠影響到性能。Addy Osmani 在 2017 年的一篇文章中指出 Chrome 的腳本引擎花費(fèi)在編譯時(shí)間上：
雖然此后 Chrome 對編譯過程進(jìn)行了優(yōu)化，但執(zhí)行腳本過長的困惱依然存在。同時(shí)這只是 Chrome 下的情況，我們無法確認(rèn)其他瀏覽器在編譯腳本時(shí)也可以保證同樣的效率
如果說 APLT 是由不同的階段組成，那么我們有沒有可能計(jì)算出每一個(gè)階段的具體時(shí)間？
回顧上面關(guān)于 GA 指標(biāo)的定義，至少我們現(xiàn)在能分離出 server time 和 browser time. 但是在 browser time 之下呢?比如說腳本的下載時(shí)間和執(zhí)行時(shí)間，這些我們就無從得知了。這些是需要額外計(jì)算和采集的。
綜上，我們完全依賴 APLT 來對站點(diǎn)的性能問題進(jìn)行診斷是不靠譜，我們單純的認(rèn)為腳本負(fù)擔(dān)拖慢了性能也是不完整的。
一場關(guān)于指標(biāo)的信仰危機(jī)
我想你大概明白了為什么我在上一節(jié)中花了這么大段的篇幅來解釋僅僅一個(gè)指標(biāo)的含義。因?yàn)橐粋€(gè)指標(biāo)能透露的信息可能會比你想象的要復(fù)雜，引導(dǎo)和誤導(dǎo)并存。
首先要聲明我并不反對使用常見指標(biāo)，這篇文章也不是對它們的批評，它們在幫助我們排查性能問題方面給了非常大的幫助。在這里我想探討的是，如果常規(guī)指標(biāo)是性能監(jiān)控的底線的話，它的上限在哪？
從上面的描述中我們不難看出 APLT 的涉獵的維度過于寬泛，它更偏向于一個(gè)技術(shù)向的綜合性指標(biāo)，它展示給我們是趨勢而非細(xì)節(jié)。這樣帶來的問題有兩個(gè)：
- 指標(biāo)指數(shù)與實(shí)際的產(chǎn)品體驗(yàn)不符
- 它無助于我們排查具體的性能問題
接下來我們深入的聊聊這兩個(gè)問題。
以用戶為中心
你或許有留意到，目前前端性能監(jiān)測的趨勢逐漸在向以用戶為中心的指標(biāo) (User-Centric Performance Metrics) 靠攏。為什么會出現(xiàn)這樣的情況?因?yàn)殡S著單頁面應(yīng)用的普及以及前端功能變“重”，經(jīng)典的以資源為中心的性能指標(biāo)(例如 Onload, DOMContentLoaded)越來越不能準(zhǔn)確地反饋真實(shí)用戶的體驗(yàn)與產(chǎn)品性能。在傳統(tǒng)后端渲染的多頁面應(yīng)用模式下，資源加載完畢即意味著頁面對用戶可用;而在單頁面模式下，資源加載完畢距離產(chǎn)品可用存在一定的差距，因?yàn)榇藭r(shí)應(yīng)用才能真正地請求用戶個(gè)性化的數(shù)據(jù)，渲染定制化的頁面。
總的來說，越來越多重要且耗時(shí)的工作都發(fā)生在資源加載之后，我們需要把這部分工作的性能也監(jiān)控起來。
好消息是瀏覽器原生的在提供給予我們這方面的支持，例如 Chrome 就在 Performace API 中提供了 Paint Timing API 諸如 first paint (FP) 、 first contentful paint (FCP)、time to interact(tti) 等指標(biāo)數(shù)據(jù)。顧名思義的這些指標(biāo)嘗試站在用戶體驗(yàn)的視角展現(xiàn)應(yīng)用在瀏覽器中被呈現(xiàn)時(shí)的性能;壞消息是，這些指標(biāo)依然在測量真實(shí)的用戶體驗(yàn)方面依然存在誤差。
就以上面提到的 FP、FCP、TTI 這三個(gè)指標(biāo)為例，我用一個(gè)簡單的例子說明這三個(gè)指標(biāo)是如何不夠準(zhǔn)確的：在單頁面的初始化過程中，我們通常會提供類似于「加載中」視圖，通常是一個(gè) placeholder 或者 skeleton 樣式，在數(shù)據(jù)請求完畢之后才會將實(shí)際的視圖渲染出來：
如果加載時(shí)間過長，瀏覽器會以為「加載中」視圖就是對用戶可用的最終產(chǎn)品形態(tài)，并以它為基準(zhǔn)計(jì)算那上述的三個(gè)指標(biāo)。
下面這段代碼模擬的就是包含上面所說情況的日常情況：在組件加載時(shí)模擬發(fā)出兩個(gè)請求，其中一個(gè)需要5秒較長的等待時(shí)間，只有當(dāng)兩個(gè)請求都返回時(shí)才能開始渲染數(shù)據(jù)，否則一直提示用戶加載中。
function App() {
const [data, setState] = useState([]);
useEffect(() => {
const longRequest = new Promise((resolve, reject) => {
setTimeout(() => {
resolve([]);
}, 1000 * 5)
});
const shortRequest = Promise.resolve([]);
Promise.all([longRequest, shortRequest]).then(([longRequestResponse, shortRequestResponse]) => {
setState([
['', 'Tesla', 'Mercedes', 'Toyota', 'Volvo'],
['2019', 10, 11, 12, 13],
['2020', 20, 11, 14, 13],
['2021', 30, 15, 12, 13]
])
})
}, []);
return (
{data && data.length
?
: }
)
}
如果你嘗試在瀏覽器中運(yùn)行上述 App, 通過 Devtools 觀測到的各個(gè)指標(biāo)如下：
你能通過開發(fā)者工具夠觀測到各種指標(biāo)比如 DCL (DOMContentLoaded Event), FP, FCP, FMP (first meaningful paint), L(Onload Event) 都發(fā)生在頁面加載后一秒左右以內(nèi)。然而從代碼里我們非?？隙ㄖ辽傥迕牒笥脩舨拍芸吹秸鎸?shí)內(nèi)容。所以上述指標(biāo)并不能真的反饋用戶感受到的性能問題
我已經(jīng)把這個(gè)應(yīng)用部署到了 https://cheat-web-page-test.com/ 站點(diǎn)上，可以在線訪問。并且可以使用 https://www.webpagetest.org/ 對它做更詳細(xì)的性能檢測，也會得出和 devtools 相同的結(jié)果。webpagetest 是一個(gè)開源免費(fèi)對網(wǎng)站性能進(jìn)行檢測的工具。早在 2012 年還沒有諸如 FP 一類的指標(biāo)時(shí)，它獨(dú)創(chuàng)的 Speed Index 指標(biāo)就能夠衡量用戶體驗(yàn)。
總的來說如上圖所示，目前瀏覽器提供的 API 能夠測量的只是 D 階段的性能，對 E 和 F 階段愛莫能助。
這只是其中一個(gè)說明原生指標(biāo)不夠準(zhǔn)確的例子，可以歸納為后端接口延遲過長。然而還有一種情況是前端渲染時(shí)間過長。例如我們在使用 Handsontable 組件渲染上千行數(shù)據(jù)表格的時(shí)候，甚至導(dǎo)致了瀏覽器的假死，這種場景對 Paint Timing API 也是免疫的。
那 tti 這個(gè)指標(biāo)怎么樣?它不是聽上去能夠檢測頁面是否可以交互嗎？它是不是能夠檢測頁面的假死？
很遺憾依然不行。
如果你有心去查看 tti 這個(gè)指標(biāo)的定義的話， 你會發(fā)現(xiàn) tti 本質(zhì)上是一種算法：
- 首先找到一個(gè)接近 tti 的零界點(diǎn)，比如 FirstContentfulPaint 或者 DomContentLoadedEnd 時(shí)機(jī)
- 從臨界點(diǎn)向后查找不包含長任務(wù) (long task) 的并且網(wǎng)絡(luò)請求相對平靜的 5 秒鐘窗口期
- 找到之后，再向前追溯到最后一個(gè)長任務(wù)的執(zhí)行結(jié)束點(diǎn)，那就是我們的要找的 tti
并且目前的原生 API 并不支持 tti 指標(biāo)，需要通過 polyfill 實(shí)現(xiàn)，按照官方的說明，目前并不能適配所有的 web app。
雙向指標(biāo)
這是知乎創(chuàng)作者中心頁面的一個(gè)截圖：
在這個(gè)頁面中，知乎每天都會為你更新過去七天內(nèi)文章閱讀數(shù)、贊同數(shù)、評論數(shù)等數(shù)據(jù)的匯總。上圖中的折線就是閱讀數(shù)。
我知道它的用意是想給予創(chuàng)作者數(shù)據(jù)上的反饋幫助他們更好的輸出內(nèi)容，但至少對我來說一點(diǎn)用也沒有。因?yàn)槲腋胫赖氖蔷烤乖鲩L來自于哪里，這樣我才能有針對性的輸出帶來點(diǎn)擊量的內(nèi)容。但它帶給我的總是匯總數(shù)據(jù)。
這個(gè)需求對于性能監(jiān)控也是同樣的成立的，監(jiān)控的目的主要是為了及時(shí)發(fā)現(xiàn)問題，解決問題。所以在審視數(shù)據(jù)的過程中，我們更關(guān)心的是異常波動值發(fā)生在何時(shí)何地，我們也希望數(shù)據(jù)能給予我這方面的幫助。
當(dāng)然我們不可能無中生有的將一組匯總數(shù)據(jù)還原成細(xì)節(jié)數(shù)據(jù)，但在這個(gè)問題上我們可以往兩個(gè)方向努力：
- 保留向細(xì)節(jié)追溯的能力：雖然我們最終看到的是匯總數(shù)據(jù)，但依然可以查詢到用于聚合計(jì)算使用的單次數(shù)據(jù)
- 更有針對性的收集數(shù)據(jù)：如果你已經(jīng)意識到高層次的指標(biāo)數(shù)據(jù)對你來價(jià)值有限，那么不妨有針對性的收集你需要的數(shù)據(jù)，這在下一節(jié)會談到。
在 Web Performance Calendar 2020 Edition 中 A wish list for web performance tools 一文中，作者提出了關(guān)于他理想性能工具應(yīng)該滿足的四則功能，分別是：
- Predict Web Performance as early as possible
- Don’t let me do the hard work
- Make data actionable
- Protect the environment
其中的第二三則對于我們選擇指標(biāo)來說也是成立的，與我在上面的強(qiáng)調(diào)的不謀而合。
最后再一次強(qiáng)調(diào)這里不是對傳統(tǒng)指標(biāo)的否定。數(shù)據(jù)帶來的效果一定是聊勝于無，指標(biāo)越多越是能精確的描繪出性能畫像。這里探討的是如何在這些基礎(chǔ)上繼續(xù)事半功倍提升我們洞察問題的效率。
在選擇衡量指標(biāo)上的一些建議
上下文驅(qū)動 (Context Driven)
之所以我無法在這里給你一個(gè)大而全的解決方案，是因?yàn)槲艺J(rèn)為這種東西并不存在，一切都要依賴你的上下文而定。
你也許更熟悉的是上下文驅(qū)動測試(Context Driven Testing)，但在我看來，上下文驅(qū)動在你選擇性能指標(biāo)或者工具時(shí)也是同樣成立的。我們不妨看一看上下文測試七條原則中的頭兩條：
- The value of any practice depends on its context. (任何實(shí)踐的價(jià)值都依附于它所處的上下文)
- There are good practices in context, but there are no best practices. (在同一塊上下文呢中會有各式各樣好的實(shí)踐，但永遠(yuǎn)不會有最佳實(shí)踐)
想象一下如果你把兩句話中的 practice 理解為指標(biāo)(metric)，甚至直接替換為指標(biāo)，是不是也沒有任何違和感呢?
“上下文驅(qū)動”初看上去不過是正反話，但實(shí)際上它是我們提升監(jiān)測效率的有效出路。指標(biāo)本身不會有對錯(cuò)之分，但不同人群對于指標(biāo)的視角是割裂的：業(yè)務(wù)分析師希望得到的是能直接彰顯業(yè)務(wù)價(jià)值的數(shù)據(jù)，例如點(diǎn)擊率，彈出率，用戶轉(zhuǎn)化;DevOps 同學(xué)他們可能關(guān)心的是網(wǎng)站的“心跳”，資源的消耗，后端接口的快慢;所以不同指標(biāo)在不同人群中是一種此消彼長的狀態(tài)。這種割裂還可以從技術(shù)角度上劃分，有的指標(biāo)更側(cè)重于資源，有的指標(biāo)更側(cè)重于用戶感受。
指標(biāo)只是發(fā)現(xiàn)問題的一種手段，現(xiàn)在我們有無數(shù)種手段任君挑選：APM (Application Performance Management)、日志分析、RUM (Real-User Monitoring)、TTFB (Time to First Byte)……最終它迫使你回到了問題的起點(diǎn)：我究竟想衡量什么?我想衡量的物體是否可以通過已有的指標(biāo)表達(dá)出來?我只是想 monitor 嗎?如果我想 debug 或者是 analyze 的話是否還有其他的選擇?
“Good software testing is a challenging intellectual process.” (請把 testing 替換為 performance tuning)上下文驅(qū)動測試中的第六條原則如是說。
追蹤元素
如果說“資源加載完畢”這件事不靠譜，“瀏覽器開始繪制”也不靠譜的話，我想唯一靠譜的事情就是用戶的所見所得了。不需要用各種數(shù)據(jù)來展示你的頁面加載有多快，如果用戶每次都要等待十秒才能看到他想看到的信息，那么這些數(shù)字無非是自欺欺人而已。所以我們不妨可以追蹤用戶關(guān)注信息所對應(yīng)元素的出現(xiàn)的時(shí)機(jī)。
這不是創(chuàng)新，從早些年的 Speed Index，“above the fold” 到如今的 web vitals 都是這種思想的延續(xù)，指標(biāo)的進(jìn)化過程像一個(gè)不斷收縮過程中圓圈，在不斷的像用戶本身靠攏。只不過出于技術(shù)手段的限制，它們只能走到那么遠(yuǎn)，而如今我們有了 MutationObserver 和 Perforamce API, 則可以精確的定位到元素，甚至元素上屬性的改變，自然也就不會被上面例子中的 placeholder 所欺騙。
抱歉我要在這里再次強(qiáng)調(diào)一下上下文：我們不能只關(guān)注“元素出現(xiàn)的時(shí)機(jī)”，更要從時(shí)間的范疇和從代碼延展上看關(guān)注形成它的原因，這依然需要我們結(jié)合問題所處的環(huán)境和它的運(yùn)轉(zhuǎn)機(jī)制而定。舉兩個(gè)例子：
在上圖中，如果 Component D 是向客戶展示關(guān)鍵信息的關(guān)鍵元素，那么 request 到達(dá) router 的時(shí)間，由 router 渲染出 Component C 的時(shí)間，都會對 D 元素產(chǎn)生影響;從另一個(gè)維度上看：
腳本以及請求加載的快慢和執(zhí)行的效率，同樣也會對元素的出現(xiàn)產(chǎn)生影響。如果你需要對問題進(jìn)行診斷，對這些背后工作機(jī)制的了解必不可少。
但追蹤元素也存在另一個(gè)問題就是它難以大規(guī)模的應(yīng)用。因?yàn)樗乔秩胧降?，因?yàn)樗枰阕R別不同頁面上的不同關(guān)鍵元素，用近似于 hard code 的方式對它們一一追蹤。這類工作產(chǎn)生的維護(hù)成本接近于維護(hù)前端的 E2E 測試。誠然我們可以通過分配統(tǒng)一的 id 或者 class name 的方式來減少我們的維護(hù)成本，但是相比統(tǒng)一的 GA 代碼這樣的維護(hù)成本依然偏高。所以我建議使用最簡單的方法去監(jiān)控最直接的元素，不要 case by case 的去編寫你的監(jiān)控代碼，不要讓你的實(shí)現(xiàn)代碼被監(jiān)控代碼束縛住。
讓工具為你所用
你可以在市面上找到各類數(shù)不勝數(shù)號稱能夠協(xié)助你改善性能的工具。但首先你要小心，它們所宣揚(yáng)的，并非是你真正需要的。
例如 site24x7 是一家專業(yè)提供用戶行為監(jiān)控解決方案的公司。在它們有關(guān) APM 的幫助頁面上，開宗明義的指出了監(jiān)控捕獲 SAP(Single Page Application) 性能數(shù)據(jù)以目前的技術(shù)來說其實(shí)是一項(xiàng)頗具挑戰(zhàn)的工作：
In case of Single Page Applications, the time taken for page load completion cannot be obtained by page onload event since the data are dynamically obtained from the server using
Hence, for each SPA framework, the page load metrics are calculated by listening to particular events specific to the framework.
所以對于此種類型的頁面，它們捕獲指標(biāo)也只有：
For every dynamic page load, the corresponding URL, it's respective AJAX calls, response time of each AJAX call, response codes and errors (if any) are captured.
但要知道在如今 SPA 大行其道的今天，如此的收集功能略顯的蒼白無力了。
同理如果你去看 Azure Application Insights 旗下 JavaScript SDK 默認(rèn)收集的頁面信息：
(1) Uncaught exceptions in your app, including information on
- Stack trace
- Exception details and message accompanying the error
- Line & column number of error
- URL where error was raised
(2) Network Dependency Requests made by your app XHR and Fetch (fetch collection is disabled by default) requests, include information on
- Url of dependency source
- Command & Method used to request the dependency
- Duration of the request
- Result code and success status of the request
- ID (if any) of user making the request
- Correlation context (if any) where request is made
(3) User information (for example, Location, network, IP)
(4) Device information (for example, Browser, OS, version, language, model)
(5) Session information
我不認(rèn)為這些指標(biāo)和其他平臺提供的相比能帶來額外的價(jià)值，它能真的給我?guī)矶嗌僬嬲?“insights”。
另一方面，不要讓你的思維被工具限制?。翰灰耙?yàn)?xx 工具只能做到這些，所以我只能收集這些指標(biāo)”;而要“我想收集這些指標(biāo)，所以我需要 xx 工具”。在這里我列舉一個(gè)我們在探索中的例子：用 OpenTracing 工具 Jaeger 去可視化前端性能圖表。
在這里我首先必須贊頌 Chrome 內(nèi)置 Performance 工具給我們調(diào)教性能帶來了極大的便利。但我們始終有一些額外的需求無法滿足。例如我希望能夠在結(jié)果呈現(xiàn)中做一些自定義的標(biāo)記，又或者在 Performance Tab 下展示每一個(gè)請求從 connect 到 resposne 每個(gè)階段的狀態(tài)。
如下圖所示，于是我們跨界的使用了 Jaeger 開源工具來用于自定義指標(biāo)的收集和展示，可以說是將不同緯度的指標(biāo)以時(shí)間為線索將它們聯(lián)系起來，這樣一來頁面加載階段的狀態(tài)并能一覽無余的盡收眼底。便于定位問題的所在。
結(jié)束語
我觀察到對于大部分前端工程師而言，又或者曾經(jīng)的自己而言，在做性能監(jiān)控時(shí)是一個(gè)被“喂”的過程，即會慣性的不假思索的收集已有指標(biāo)和利用已有工具。又因?yàn)樾阅軆?yōu)化工作過程前置結(jié)果后置的關(guān)系，等到我們有需求發(fā)生時(shí)才會發(fā)現(xiàn)當(dāng)下的結(jié)果并非是我們想要的。多一些思考才會讓我們的工作少一分浪費(fèi)。
文章名稱：性能指標(biāo)的信仰危機(jī)
標(biāo)題路徑：http://m.fisionsoft.com.cn/article/dpdpppi.html
