[譯] 對產品經理而言的 Web 性能

• 原文地址：Web Performance for Product Managers
• 原文做者：Cliff Crocker
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：flying-yogurt
• 校對者：PassionPenguin、Chorer、greycodee

對產品經理而言的 Web 性能

我喜歡與他人談論關於 Web 性能的內容，同時很幸運地，我有過很多相關的聊天經歷。聽衆身份各異，大多數時候都是前端開發者或工程主管，但我愈加以爲本身能夠和產品負責人展開有趣的討論。如此精彩的討論使我經常以爲本身有一種更好的方法來簡化對話，並表達出我對將產品經理們引入網絡性能世界的熱情。我但願這篇文章能夠達到這個目的，並涵蓋一些我認爲在磨練產品管理技巧時最有用的網絡性能基礎領域。

因此，無論你是否是產品經理，若是你對網絡性能不太熟悉，我這裏會彙總一些概念與指南供你參考並快速掌握。這些內容包括：

• 什麼致使了頁面變慢？
• 如何衡量性能？
• 不一樣的指標分別是什麼意思？
• 理解與使用百分位數
• 該怎樣與不一樣身份的相關人員討論性能問題？

讓咱們開始吧。

什麼致使了頁面變慢？

太多東西可能致使頁面變緩慢了。在這兒只列舉了一些你應當知曉的，影響較大的因素。但請務必留意其餘緣由，性能比如一隻多頭野獸通常難以捉摸，沒法控制。

請求

你的頁面由不少靜態資源文件組成。圖片、字體、JavaScript、CSS、跟蹤像素…… 這些都在提供豐富瀏覽體驗方面發揮了做用。但總的來講，這些資源文件可能會讓你陷入一個有如千刀萬剮般痛苦的境地。

Steve 的黃金法則 至今仍然適用：80％ 至 90％ 的渲染時間都花在了前端，其中大部分的時間耗費在了網絡請求上。若是要優化你的站點，能夠先從儘量地減小請求次數開始。

代碼

前端開發者有不少能夠聽從的最佳實踐，這一般是你在性能優化的衝刺階段才投入進行的工做。代碼的優化建議能夠來自專業人士的審覈，也能夠來自像 Lighthouse 這樣的自動工具（固然還有 SpeedCurve）。爲用戶分析網站性能的時候，我喜歡使用 PageSpeed Insights以得到一些更高級的建議。咱們在產品中加入了 Lighthouse 評分和審覈，這是一個很好的起點。

問題可能出自（但確定不侷限於）：

• JavaScript
• 改進「關鍵路徑」或渲染阻塞
• 以及，使用指令來預加載頁面元素或異步加載腳本

儘管大多數狀況下，產品經理的注意力都都集中在前端開發者上，可是，若是你察覺到了過長的開始渲染時間，或更多不正常的基本指標（例如到第一個字節的時間）增長，也要關注後端開發工做。這一點很是重要。

圖像

圖像優化仍然是能夠以最小代價換取巨大性能提高的領域之一。隨着圖像壓縮技術的不斷髮展，新的圖像格式被引入實際運用當中。這些格式提供了豐富的功能集，同時將所需的帶寬最小化。在某些狀況下，這些格式是特定於瀏覽器的，有可能致使工做流程的複雜性增長。

不管你是否有機會實際參與這一領域的工做，理解圖像管道（無論是在內部仍是做爲服務進行管理）都是大有裨益的。對於維護大型產品目錄或包含大量用戶生成內容的網站，尤爲如此。

還須要注意的是，雖然並不是全部性能提高都會顯示在你的指標中，可是這些工做對於帶寬不足或數據流量受限的用戶將是十分使人感激的。考慮基於請求的大小和數量去設置與圖像相關的 性能預算，而不是基於請求的時長。

網絡

正是如此。互聯網一直以來都是反常的。經過線纜，從A點到B點傳輸一又一個比特————當我想到這件事自己所涉及的複雜性時，我仍然感到驚訝與激動。

對你來說，你可能會對技術合做夥伴如何增進服務的性能感到好奇，畢竟你爲此付出了一大筆錢。諸如 Akamai、Fastly、Cloudflare 和 Cloudfront 之類的內容分發網絡（CDN）有時會對性能產生重大影響。傳統上，這些影響在服務後端時間表現得更多，可是當考慮到從服務端到 Web 的一些資源分發（圖像或其餘靜態內容）以及邊緣可用的一些高級優化時，也會對前端產生巨大影響。若是你很少加留意，這些平臺只能使狀況變得更糟，而不是變得更好。

第三方服務

（一聲長嘆）咱們對它真是又愛又恨。不過，咱們對使用這些內容並不排斥，甚至還常常用到它們。

對咱們來說，第三方服務指的是在自身領域外的那些爲豐富內容或提供服務而存在的貢獻者。對其不滿的主要緣由是，它一般超出你的控制範圍；當它影響服務的性能時，你幾乎沒辦法作什麼來加快服務進程，你既不能移除標籤，也不能殺掉進程。

但身爲一個產品經理，你得學會承受這些。你但是影響本身控制範圍以外的事物的大師。你可讓他們對其負責，並維持着使他們保持一致的策略。例如：

• 和你的供應商經理（若是你有的話）或負責此事的利益相關者直接合做，以設置第三方服務的 性能預算。也許你建立了能夠和該責任方一塊兒執行的標籤預算。預算可能與規模有關。
• 若是您的市場營銷部門須要添加一個新元素，必須有另外一箇舊的被替換。
• 審覈你的第三方服務並刪除全部的沒有用到的 script 腳本。
• 在引入新的第三方服務以前，請執行審覈過程，以確保他們經過了一些有關性能的基本準則。我最喜歡的工具是由 Nic Jansma 參與開發的 3rdParty.io。

不管形成性能問題的緣由是什麼，解決問題時都必須保持團隊合做的態度與精神。性能過差一般不只僅是某一我的的過失，單靠一我的或者一個小組就能擁有獨立於其餘成員而修復問題的能力 ——— 這也是極其罕見的。性能是團隊的活兒。

如何衡量性能？

這兒有兩種主要方法，它們都集中衡量了用戶訪問你的網站時瀏覽器的響應方式。

綜合監測

它並不是真實存在的。從本質上來說，綜合監測更像一種機器人，它能夠執行你所指示的操做（例如從 X 瀏覽器上的 X 位置訪問個人主頁）並主動收集性能數據。

綜合監測很是棒，它能夠提供不少有用的東西，讓咱們得以瞭解執行該動做時發生的事情的大量細節。包括：

• 瀑布圖，其中包含有關每一個請求的詳細信息，
• 幻燈片和視頻，可幫助你可視化渲染體驗，以及
• 當查看應用程序的組成時，一條合理且一致的基線。

綜合監測很是適用於那些有隨時間變化趨勢的內容，尤爲是在查看請求（圖像、JavaScript、CSS）的數量和大小時。這些內容對速度有較大影響。

不過，儘管綜合監測擁有上述全部優勢，它仍缺乏一個極其關鍵的組成部分：終端用戶。

真實用戶監測（RUM）

想必你已經猜到了：衡量真實的用戶。RUM 能夠被視爲從終端用戶的實際瀏覽器中所獲得的、基於性能表現的分析。

做爲出色的產品經理，你已經將精力集中在由外而內地構建你的產品上。你與數不勝數的客戶交流，獲取他們的反饋，並將其轉化爲對下一個產品的需求。每當制定激動人心的路線圖併爲你的產品或產品線建立嶄新的願景時，共情的力量能夠在你的整個團隊中普遍傳播。

這就是爲何你須要 RUM。真實的用戶，真實的經驗。RUM 是瞭解 Web 性能的基礎，在與相關人員交流性能時，它也已經成爲事實的首選來源。若是沒有 RUM，你要怎樣才能將性能做爲產品的需求之一呢？我知道這很是困難。不過，在現在的時代，不綜合考慮 RUM 將會給性能評估帶來弊端。

不一樣的指標分別是什麼意思？

不管你使用綜合監測仍是 RUM，每一個工具均可以捕獲數十個性能指標。這些年來，弄清楚咱們應該關注哪些性能指標已經成爲了一個「危險」的過程。如同鐘擺同樣，趨勢已經從「衡量全部指標」轉變爲「這是我獨有的指標」。而今天咱們在二者之間尋求一種平衡，對「我到底應該關注哪一個指標」這個問題的回答仍略顯無奈：

"因地制宜。"

不要過度苛求細枝末節，你並不須要百分之百理解這許許多多的指標。對於絕大多數像你同樣的產品經理而言（尤爲是那些剛開始接觸性能的新手），請將目光放在那些與用戶體驗關係最爲密切的指標上。這篇 出自 Tammy 的指南或許對解決這個問題有幫助。

在最近幾個月，我和產品經理們的對話的主要圍繞在網站核心指標上。若是你也在這個領域中，而且在改善 SEO 或應對有關 Google 控制檯中顯示的數字的入站問題方面承受壓力，你可能須要熟悉這些指標。幸運的是，你能夠閱讀很多有關於這個主題的優秀資料。從這些資源開始：

• 跟蹤網站核心指標
• 瞭解累積版式移位
• 第一次輸入延遲，它有多重要？
• 關於網站核心指標我所知道的一切 by Simon Hearne

理解與使用百分位數

如今，你已經對不一樣的指標有了初步的瞭解，那更進一步地，學習如何將百分位數應用在每個指標上就很重要 —— 這樣，你就更能理解不一樣的真實用戶羣組對你的網站的體驗。

這是一個直方圖:

直方圖表示在訪問您的網站時具備多種體驗的用戶分佈。記住這一點。

性能是一種分佈，而不僅是一個數字。這是說並不是測量一次事後就萬事大吉了。直方圖所表示的是體驗的連續性，你能夠藉此思考性能分佈的形狀，以及你但願如何影響性能。左移使其加速，右移使其減速。

我仍須要一個數字。我該怎麼辦？

別擔憂，你仍然會接着和數字打交道。百分位數表明着你的受衆羣體中，從 0 至 100 的一個個小部分。並不是統計學家才能作到這一點，你只須要像這樣思考：

**第 50 個百分位數（中位數）：**我發現使用第 50 個百分位數，即中位數，更易於理解和溝通。若是你想的話，你甚至能夠將其看成平均值。

**第 75 個百分位數：**對於某些流行的指標，例如 網站核心指標，第 75 個百分位數在報告中常被使用。

**第 95 個百分位數：**若是你的網站對於大多數用戶來講已經至關快了，那麼你能夠將精力放在剩下的極少部分的使用者，使他們的訪問體驗變得更快。5％ 的用戶聽起來可能並很少，可是若是您的網站每個月有 1000 萬訪問者，則意味着其中有 500,000 人的體驗確實不好。

除非你使用算術平均值（也就是傳統意義上的平均值）來描述人口，不然要關注哪一個百分位數（每種都有其優勢）並無一個確切的答案。 對於這種類型的分佈而言，其效果並不理想。

該怎樣與不一樣身份的相關人員交流討論性能？

我發現這是產品經理在衡量性能方面所面臨的最大挑戰之一。多年來，咱們一直在努力應對這一挑戰，但仍未獲得最佳的答案。如下是你可能想要牢記的一些有關交流的想法。

瞭解你的聽衆

這並非一個嶄新的概念。當涉及跨職能工做時，您可能會擔當不一樣的職責，使用多元的語言。在提出新的術語和概念，或向 CEO 提出過多冗雜的細節信息時，請三思然後行。

保持簡單化

不要過分交流或使他人迷惑。若是你將重點放在性能 KPI 報表上，很棒。若是你設法圍繞這個獨角獸指標進行調整，那就太好了。只是不要拔苗助長。我常常看到產品經理在嘗試傳達其 RUM 指標及其綜合指標時犯丟失諸如百分位數這樣的術語，或避免顯示兩組數字這樣的錯誤。別這麼幹。一樣，只要有可能，請使用 RUM。你可使用綜合監測突出顯示一部分數據，例如頁面權重或元素計數，也能夠藉此陳述網站上第三方的數量。這是綜合監測數據很好地補充 RUM 數據的地方。

將性能具象化

在這部分，綜合監測工具搶佔了先機。使用幻燈片或視頻與不在內部的其餘參與者討論關於性能的話題。在促進出色的團隊工做時，沒有比播放先後視頻更棒的了。

標杆測試

基準化分析法（又稱標杆測試、標杆管理）是你所擁有的另外一個絕佳工具。相較於輸，團隊更想贏。使用標杆測試來比較本身和競爭對手是很是有效的。在管理網站核心指標時尤爲如此。若是有一半左右的競爭對手 LCP 時間比你快，那會對你的搜索結果產生什麼影響呢？

別怕丟人。不管是你亦或是你的競爭對手處於最底層，這種狀況隨時可能被改變。使用標杆測試來使本身變得更好，或是向他人學習理解。查看咱們的 行業網頁速度標杆測試 來了解如何使用工具包中的基準化分析法。

總結

這些是基礎知識，我但願你能以爲閱讀這篇文章的時間花得物有所值。就像你做爲產品經理接觸到的任何主題同樣，你也能夠隨時在這個領域更進一步。

還有其餘問題或者想法嗎？我相信其餘讀者也但願聽到這些聲音，請盡情評論吧。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。