互聯(lián)網(wǎng)發(fā)展非常迅速，所以我們創(chuàng)造了Web平臺(tái)。通常 我們會(huì)忽視連通性等問題，但用戶們卻不會(huì)視而不見 。一瞥萬(wàn)維網(wǎng)的現(xiàn)狀，可以發(fā)現(xiàn)我們并沒有用同情心、變通意識(shí)去構(gòu)建它，更不要說性能了。

所以，今天的Web是什么狀態(tài)呢?

在這個(gè)星球上的74億人中，只有46%可以上網(wǎng)。平均網(wǎng)絡(luò)速度上限為7Mb/s。更重要的是，有93%的互聯(lián)網(wǎng)用戶正在通過移動(dòng)設(shè)備進(jìn)行訪問——若不適配移動(dòng)設(shè)備將引起用戶反感。通常情況下，數(shù)據(jù)比我們假設(shè)的更昂貴——可能需要1到13小時(shí)才能購(gòu)買500MB的數(shù)據(jù)包(德國(guó) vs. 巴西;更有趣的統(tǒng)計(jì)數(shù)據(jù)參見 Ben Schwarz 的 Beyond the Bubble: The Real World Performance )。

我們的網(wǎng)站也不是完美的——平均網(wǎng)站是 原始Doom游戲的大小 (約3 MB)(請(qǐng)注意，為了統(tǒng)計(jì)準(zhǔn)確，應(yīng)使用中位數(shù)，閱讀 Ilya Grigorik 的 優(yōu)秀“平均頁(yè)面”是一個(gè)神話 ，中檔網(wǎng)站大小目前為1.4MB)。圖像可以輕松占用1.7 MB的帶寬，而JavaScript平均值也有400KB的體積。這不僅是Web平臺(tái)的問題，原生應(yīng)用程序可能更糟，還記得為了獲取錯(cuò)誤修復(fù)版本，而下載200MB安裝包的情景嗎?

技術(shù)人員經(jīng)常會(huì)發(fā)現(xiàn)自己處于特權(quán)狀態(tài)。隨著最新的高端筆記本電腦、手機(jī)和快速有線互聯(lián)網(wǎng)連接，很容易讓我們忘記，這些并不是每個(gè)人都有的條件(實(shí)際上，真的很少)。

如果我們從特權(quán)和缺乏同情的角度來構(gòu)建網(wǎng)絡(luò)平臺(tái)，那么將導(dǎo)致排他性的糟糕體驗(yàn)。

考慮到設(shè)計(jì)和開發(fā)的性能，我們?cè)鯓硬拍茏龅酶?

優(yōu)化所有資源

理解瀏覽器如何分析和處理資源，是顯著提高性能的最強(qiáng)大但未充分利用的方式之一。事實(shí)證明，瀏覽器在嗅探資源方面非常出色，同時(shí)解析并確定其優(yōu)先級(jí)。這里是 關(guān)鍵請(qǐng)求 的來源。

如果請(qǐng)求中包含用戶視口中呈現(xiàn)內(nèi)容所必需的資源，則該請(qǐng)求至關(guān)重要。

對(duì)于大多數(shù)網(wǎng)站，它將是HTML、必要的CSS、logo、網(wǎng)絡(luò)字體，也可能是圖片。在許多情況下，幾十個(gè)其他不相關(guān)的資源(JavaScript、跟蹤代碼、廣告等)影響了關(guān)鍵請(qǐng)求。幸運(yùn)的是，我們能夠通過仔細(xì)挑選重要資源并調(diào)整優(yōu)先級(jí)來控制這種行為。

通過 我們 可以手動(dòng)強(qiáng)制調(diào)高資源的優(yōu)先級(jí)，確保所需的內(nèi)容按時(shí)呈現(xiàn) 。這種技術(shù)可以顯著改善“交互時(shí)間”指標(biāo)，從而使最佳的用戶體驗(yàn)成為可能。

關(guān)鍵請(qǐng)求對(duì)許多人來說，似乎仍然是一個(gè)黑匣子，可共享資料的缺乏并不能改變現(xiàn)狀。幸運(yùn)的是， Ben Schwarz

發(fā)表了關(guān)于這個(gè)問題的非常全面并平易近人的文章—— 關(guān)鍵請(qǐng)求 。另外，請(qǐng)參閱Addy的文章， 在Chrome中的預(yù)加載、預(yù)取和優(yōu)先級(jí)(Preload, Prefetch and Priorities in Chrome )。

[在Chrome開發(fā)人員工具中啟用優(yōu)先級(jí)]

要跟蹤在請(qǐng)求優(yōu)先級(jí)處理方面的情況，請(qǐng)使用Lighthouse性能工具和 關(guān)鍵請(qǐng)求鏈審核工具 ，或查看Chrome開發(fā)人員工具中“網(wǎng)絡(luò)”選項(xiàng)卡下的請(qǐng)求優(yōu)先級(jí)。

• 通用性能清單
• 積極地緩存
• 啟用壓縮
• 優(yōu)化關(guān)鍵資源的優(yōu)先級(jí)
• 使用CDN(Content Delivery Networks)
• 圖片優(yōu)化

圖片通常占網(wǎng)頁(yè)傳輸?shù)拇蟛糠钟行лd荷，因此圖片優(yōu)化可以帶來最大的性能提升。有許多現(xiàn)有的策略和工具可以幫助我們刪除額外的字節(jié)，但是首先應(yīng)考慮的問題是：“圖片對(duì)于我想傳達(dá)的信息和效果至關(guān)重要嗎?”。如果可以消除它，不僅可以節(jié)省帶寬，而且還節(jié)省了請(qǐng)求。

在某些情況下，可以通過不同的技術(shù)實(shí)現(xiàn)類似的結(jié)果。比如CSS就具有藝術(shù)方向的一系列屬性，例如陰影、漸變、動(dòng)畫及形狀，允許我們構(gòu)造適當(dāng)風(fēng)格的DOM元素。

選擇正確的格式

如果不能舍棄圖片，確定哪種格式更合適就很重要了。首先要在矢量和光柵圖形之間做出選擇：

• 矢量圖形 ：分辨率獨(dú)立，通常體積更小。非常適合logo、icon和簡(jiǎn)單的圖形，包括基本形狀(線，多邊形，圓和點(diǎn))。
• 光柵圖形 ：呈現(xiàn)更詳細(xì)的信息，比較適合相片。

做出首個(gè)決定后，可以選擇以下幾種格式：JPEG、GIF、PNG–8、PNG–24，或最新的 WEBP 與 JPEG-XR 格式。有了這么多的選項(xiàng)，如何確保我們做出正確的選擇?以下是找出最佳格式的基本方法：

• JPEG ：顏色非常豐富的圖片(例如照片)
• PNG–8 ：色彩相對(duì)單一的圖片
• PNG–24 ：局部透明的圖片
• GIF ：動(dòng)圖

Photoshop可以通過各種設(shè)置，例如降低質(zhì)量、降低噪音或色彩數(shù)量來優(yōu)化以上每一種格式。確保設(shè)計(jì)師了解上述性能實(shí)踐，并能夠使用正確的方式優(yōu)化相應(yīng)格式的圖片。如果您想了解更多如何處理圖片，請(qǐng)閱讀 Lara Hogan 的好文 Designing for Performance 。

試用新格式

圖像格式有幾個(gè)較新的玩家，即WebP、JPEG 2000 和 JPEG-XR。它們都是由瀏覽器廠商開發(fā)的：Google 的 WebP，Apple 的 JPEG 2000 和 Microsoft 的 JPEG-XR。

WebP是最受歡迎的競(jìng)爭(zhēng)者，支持無(wú)損和有損壓縮，這使得它非常靈活。 無(wú)損的 WebP 比 PNG 小26%，比 JPG 小25-34% 。WebP 有著74%的瀏覽器支持，它可以安全地進(jìn)行降級(jí)，最多可節(jié)省1/3的傳輸字節(jié)。JPG 和 PNG 可以在 Photoshop 和其他圖像處理應(yīng)用程序以及命令行界面( brew install webp )中轉(zhuǎn)換為WebP。

如果你想探索其他格式之間的視覺差異，推薦 Github 上這個(gè)很贊的 Demo 。

用工具和算法進(jìn)行優(yōu)化

即使 使用了高效的圖像格式，也不應(yīng)跳過后處理優(yōu)化 。這一步很重要。

如果您選擇了尺寸相對(duì)較小的 SVG，它們也是可以再次壓縮的。 SVGO 是一個(gè)命令行工具，可以通過剝離不必要的元數(shù)據(jù)來快速優(yōu)化 SVG。另外，如果您喜歡Web界面或受操作系統(tǒng)的限制，請(qǐng)使用 Jake Archibald 的 SVGOMG 。因?yàn)?SVG 是基于 XML 的格式，它也可以在服務(wù)器端進(jìn)行 GZIP 壓縮。

ImageOptim 是大多其他圖像類型的最好選擇。包括 pngcrush、pngquant、MozJPEG、Google Zopfli等，它在一個(gè)全面的開源包中捆綁了一大堆優(yōu)秀的工具。ImageOptim 可以以 Mac OS 應(yīng)用程序、命令行界面和 Sketch 插件形式，輕松地實(shí)現(xiàn)到現(xiàn)有的工作流程中。對(duì)于那些在 Linux 或 Windows 上的場(chǎng)景，大多數(shù) ImageOptim 的 CLI 都可以在您的平臺(tái)上使用。

如果您傾向于嘗試新興的編碼器，Google 今年早些時(shí)候發(fā)布了 Guetzli ——源自 WebP 和 Zopfli 的開源算法。 Guetzli 可以比任何其他可用的壓縮方法生成35%更小體積的 JPEG 。唯一的缺點(diǎn)是：處理時(shí)間慢(CPU 每處理百萬(wàn)像素需要1分鐘)。

選擇工具時(shí)，請(qǐng)確保它們生成所需的結(jié)果并適應(yīng)團(tuán)隊(duì)的工作流程。理想情況是，將優(yōu)化過程自動(dòng)化，這樣就不會(huì)產(chǎn)生漏掉的情況。

響應(yīng)式圖片

十年前，我們使用一種分辨率，就可以為所有人服務(wù)，但時(shí)代變化太快，現(xiàn)今的響應(yīng)式 Web 已非往日可比。這也是為什么我們必須要特別留心，去精心優(yōu)化視覺資源，確保它們適應(yīng)各種視口設(shè)備。幸運(yùn)的是，感謝 Responsive Images 社區(qū)小組 ，我們可以完美使用 picture 元素和 srcset 屬性(二者都有85%+支持率)。

srcset 屬性

srcset 在分辨率切換方案中效果最佳——即當(dāng)我們需要根據(jù)用戶的屏幕密度和大小顯示圖像時(shí)?；?srcset 和 size 屬性中的一組預(yù)定義規(guī)則，瀏覽器將選擇最佳圖片，相應(yīng)地提供給視口。這項(xiàng)技術(shù)可以帶來很大的帶寬和請(qǐng)求節(jié)省，特別是對(duì)于移動(dòng)用戶。

[srcset 使用示例]

picture 元素

picture 元素和 media 屬性旨在使藝術(shù)設(shè)計(jì)變得容易。通過為不同情形提供不同圖片(通過媒體查詢進(jìn)行測(cè)試)，無(wú)論什么分辨率，我們都能始終將圖像中最重要的元素保持在焦點(diǎn)。

[picture 元素使用示例]

請(qǐng)務(wù)必閱讀 Jason Grigsby 的 Responsive Images 101 指南，以便對(duì)這兩種方法進(jìn)行徹底的闡述。

使用圖片 CDN 進(jìn)行分發(fā)

視覺優(yōu)化的最后一步是分發(fā)。所有資源都可以從使用 內(nèi)容分發(fā)網(wǎng)絡(luò) 中受益，但還有一些針對(duì)圖片優(yōu)化的特定工具，例如 Cloudinary 和 imgx 。使用這些服務(wù)的好處遠(yuǎn)遠(yuǎn)超過了減少服務(wù)器上的流量，并顯著降低了響應(yīng)延遲。

CDN可以很好的解決重圖片網(wǎng)站的復(fù)雜度，包括響應(yīng)式服務(wù)與圖片優(yōu)化。雖然產(chǎn)品不同(價(jià)格也是如此)，但是大多數(shù)方案都是根據(jù)設(shè)備和瀏覽器，調(diào)整大小、裁剪來確定哪種格式最適合用戶。甚至更多——它們可以壓縮、檢測(cè)像素密度、水印、識(shí)別面部，并允許后置處理能力。借助這些強(qiáng)大的功能，和將參數(shù)附加到URL的能力，以用戶為中心的圖片服務(wù)變得十分容易。

• 圖像性能清單
• 選擇正確的圖片格式
• 盡可能使用矢量圖形
• 如果變化不明顯，則降低圖片質(zhì)量
• 使用新格式圖片
• 使用工具與算法優(yōu)化
• 學(xué)習(xí) srcset 和 picture
• 使用圖片 CDN

Web 字體優(yōu)化

自定義字體是一項(xiàng)非常強(qiáng)大的設(shè)計(jì)工具。但是能力伴隨著很多責(zé)任 。現(xiàn)有68%的網(wǎng)站在使用 Web字體，這種類型的資源是性能殺手之一 (平均輕松可達(dá)100KB，取決于變體和字體的數(shù)量)。

即使體積不是最大的問題， 不可見文本閃動(dòng) (FOIT)也算是。當(dāng)Web字體加載中或加載失敗時(shí)，會(huì)發(fā)生FOIT，這會(huì)讓空白頁(yè)面，從而導(dǎo)致內(nèi)容無(wú)法訪問。 首先仔細(xì)檢查我們是否需要Web字體 可能是值得的。如果真是這樣，有一些策略可以幫助我們減輕對(duì)業(yè)務(wù)的負(fù)面影響。

選擇正確的格式

有4種網(wǎng)絡(luò)字體格式：EOT、TTF、WOFF 和最近的 WOFF2。TTF 和 WOFF 被廣泛使用，擁有超過90%的瀏覽器支持率。根據(jù)支持情況， 最有可能安全地使用WOFF2 ，并在舊版瀏覽器降級(jí)使用 WOFF。使用WOFF2的優(yōu)點(diǎn)是，一套定制的預(yù)處理和壓縮算法(如Brotli)，并有 大約30%的文件大小減少 和改進(jìn)的解析能力。

在 @font-face 中定義網(wǎng)頁(yè)字體的來源時(shí)，請(qǐng)使用 format() 提示來指定應(yīng)使用哪種格式。

如果您使用 Google Fonts 或 Typekit 來提供字體，這兩種工具都實(shí)施了一些策略來優(yōu)化其性能。Typekit 現(xiàn)在可以異步地為所有套件提供服務(wù)，防止 FOIT 以及允許其JavaScript套件代碼的10天延長(zhǎng)緩存期限(而不是默認(rèn)10分鐘)。Google Fonts 可以根據(jù)用戶設(shè)備自動(dòng)提供最小的文件。

審核字體范圍

無(wú)論是否自主托管，字體數(shù)量、字體體積和樣式，都將顯著影響您的性能預(yù)算。

理想情況下，我們只需要一種包括常規(guī)和粗體的字體。如果您不確定如何選擇字體范圍，請(qǐng)參考 Lara Hogan 的 Weighing Aesthetics and Performance 。

使用Unicode范圍子集

Unicode范圍子集允許將大字體分割成較小的集合。這是一個(gè)相對(duì)先進(jìn)的策略，特別是在處理亞洲語(yǔ)言的時(shí)候，可能會(huì)帶來顯著的節(jié)省(你知道中文字體有平均數(shù)為 20,000 個(gè)字形嗎?)。第一步是將字體限制為必要的語(yǔ)言集，例如拉丁語(yǔ)，希臘語(yǔ)或西里爾語(yǔ)。如果僅使用Web字體做Logo類使用，則應(yīng)使用Unicode范圍描述符，來選擇特定字符。

Filament Group 發(fā)布了一個(gè)開源命令行工具，可以根據(jù)文件或URL生成必要字形列表的 glyph hanger 。或者，基于 Web 的 Font Squirrel Web Font Generator 提供高級(jí)子集和優(yōu)化選項(xiàng)。如果在字體選擇器界面中內(nèi)置了使用Google Fonts 或 Typekit 選擇語(yǔ)言子集，則使基本子集更容易。

建立字體加載策略

字體是阻塞渲染的——因?yàn)闉g覽器必須首先構(gòu)建 DOM 和 CSSOM;在使用與現(xiàn)有節(jié)點(diǎn)相匹配的CSS選擇器之前，瀏覽器并不會(huì)下載Web字體。這種行為會(huì)明顯延遲文本呈現(xiàn)，通常會(huì)導(dǎo)致前面提到的不可見文本閃動(dòng)(FOIT)。在較慢的網(wǎng)絡(luò)和移動(dòng)設(shè)備上，F(xiàn)OIT會(huì)更加顯著。

實(shí)施字體加載策略，可防止用戶無(wú)法訪問您的內(nèi)容。通常，選擇 無(wú)樣式文本閃動(dòng) (FOUT)是最簡(jiǎn)單和最有效的解決方案。

font-display 是提供非 JavaScript 依賴解決方案的新 CSS 屬性。不幸的是，它僅有部分支持(Chrome 和 Opera)，目前正在 Firefox 和 WebKit 中開發(fā)。盡管如此，它可以并且應(yīng)該與其他字體加載機(jī)制結(jié)合使用。

[font-display 屬性實(shí)踐]

幸運(yùn)的是，Typekit 的 Web Font Loader 和 Bram Stein 的 Font Face Observer 可以幫助管理字體加載行為。此外，網(wǎng)頁(yè)字體性能專家 Zach Leatherman 發(fā)布了 字體加載策略綜合指南 ，這將有助于為您的項(xiàng)目選擇正確的方法。

• 字體性能清單
• 選擇正確的格式
• 審核字體范圍
• 使用Unicode范圍子集
• 建立字體加載策略

JavaScript 優(yōu)化

目前， JavaScript 的平均大小為446 KB ，已經(jīng)使其成為第二大的資源類型(第一為圖片)。

我們可能沒有意識(shí)到，我們所愛的JavaScript隱藏著更加嚴(yán)峻的性能瓶頸。

監(jiān)控JavaScript的流量

優(yōu)化交付只是解決網(wǎng)頁(yè)膨脹的第一步。JavaScript 下載后，必須由瀏覽器進(jìn)行解析、編譯和運(yùn)行?？焖贋g覽一些流行的網(wǎng)站，顯而易見的是，gzip 壓縮的 JS 在 解壓之后至少變大三倍 。事實(shí)上，我們正在發(fā)送一大堆代碼。

1MB JavaScript 在不同設(shè)備上的解析時(shí)間。圖片由 Addy Osmani 和他的 JavaScript Start-up Performance 文章提供。

分析解析和編譯時(shí)間，對(duì)于理解應(yīng)用程序是否準(zhǔn)備好進(jìn)行交互至關(guān)重要。這些耗時(shí)根據(jù)用戶設(shè)備的硬件能力而異。 解析和編譯會(huì)很容易在低端手機(jī)上高出2-5倍 。 Addy 的研究證實(shí)，在常規(guī)手機(jī)上，一個(gè)應(yīng)用程序?qū)⑿枰?6秒才能達(dá)到交互式狀態(tài)，而在桌面電腦上為8秒。分析這些指標(biāo)至關(guān)重要，幸運(yùn)的是，我們可以通過 Chrome DevTools 來完成。

[在 Chrome 開發(fā)工具中查看解析和編譯過程]

請(qǐng)務(wù)必閱讀 Addy Osmani 對(duì) JavaScript 啟動(dòng)性能 的詳細(xì)說明。

擺脫不必要的依賴

現(xiàn)代軟件包管理器的工作方式，可以輕而易舉地掩蓋依賴關(guān)系的數(shù)量和大小。 webpack-bundle-analyzer 和 Bundle Buddy 是很好的可視化工具，幫助識(shí)別出代碼重復(fù)、最大性能問題和過時(shí)的、不必要的依賴。

圖 webpack bundle analyzer 實(shí)踐

通過 VS Code 和 Atom 中的 Import Cost 擴(kuò)展，我們可以使導(dǎo)入依賴成本更加明顯。

實(shí)現(xiàn)代碼分割

只要有可能， 我們就應(yīng)只提供用戶體驗(yàn)所必需的資源 。向用戶發(fā)送一個(gè)完整的

bundle.js 文件，包括他們可能永遠(yuǎn)看不到的交互效果處理代碼，并不太理想(假設(shè)在訪問著陸頁(yè)時(shí)，去下載處理整個(gè)應(yīng)用程序的 JavaScript)。同樣，我們不應(yīng)普遍提供針對(duì)特定瀏覽器或用戶代理的代碼。

Webpack，最受歡迎的模塊打包器之一，天生具備 代碼分割支持 。最簡(jiǎn)單的代碼分割可以按頁(yè)面實(shí)現(xiàn)(如用于著陸頁(yè)的 home.js ，聯(lián)系人頁(yè)面的 contact.js 等)，Webpack 還提供了一些高級(jí)策略，如動(dòng)態(tài)導(dǎo)入及 延遲加載 ，值得一看。

考慮框架選擇

JavaScript 前端框架日新月異。根據(jù) 2016年的 JavaScript 調(diào)查 ，React 是最受歡迎的選擇。仔細(xì)審視架構(gòu)選擇，可能會(huì)發(fā)現(xiàn)，您可以使用更為輕量級(jí)的替代方案，例如 Preact (請(qǐng)注意，Preact 并不是一個(gè)完整的 React 重新實(shí)現(xiàn)，只是一個(gè) 高性能 ，功能更輕的虛擬 DOM 庫(kù))。類似地，我們可以將較大的庫(kù)更換成更小的版本—— moment.js 換成 date-fns (或者在特定情況， 刪除 moment.js 中未使用的 locales )。

在開始一個(gè)新項(xiàng)目之前，有必要確定什么樣的功能是必需的，并為您的需求和目標(biāo)選擇最具性能的框架。有時(shí)這可能意味著選擇寫更多的原生 JavaScript。

• JavaScript 性能清單
• 監(jiān)控 JavaScript 流量
• 擺脫不必要的依賴
• 實(shí)現(xiàn)代碼分割
• 考慮框架選擇

性能追蹤，前進(jìn)之路

我們已經(jīng)討論了一些策略，在大多數(shù)情況下會(huì)對(duì)我們正在建立的產(chǎn)品用戶體驗(yàn)產(chǎn)生積極的變化。性能可能是一個(gè)棘手的問題，有必要長(zhǎng)期地跟蹤我們調(diào)整的結(jié)果。

以用戶為中心的性能指標(biāo)

卓越的性能指標(biāo)，旨在盡可能接近描繪用戶體驗(yàn)。以往的 onLoad ， onContentLoaded 或 SpeedIndex 對(duì)「用戶多快能與頁(yè)面交互」給出的信息非常少。當(dāng)聚焦到傳輸資源時(shí)，量化地 感知性能 十分困難。好在，有一些時(shí)間可以全面地描述內(nèi)容的可視性和互動(dòng)性。

這些指標(biāo)是首次渲染(First Paint)，首次有意義渲染(First Meaningful Paint)，視覺完整(Visually Complete)和可交互時(shí)間(Time to Interactive)。

• 首次渲染 ：瀏覽器從白色屏幕到第一次視覺呈現(xiàn)的變化。
• 首次有意義渲染 ：文字，圖像和主要內(nèi)容都已可見。
• 視覺完整 ：視口中的所有內(nèi)容都可見。
• 可交互時(shí)間 ：視口中的所有內(nèi)容都是可見的，可以與之進(jìn)行交互(JavaScript 主線程停止活動(dòng))。

這些時(shí)間直接對(duì)應(yīng)于用戶的實(shí)際體驗(yàn)，因此可以作為重點(diǎn)進(jìn)行追蹤。如果可能，將它們記錄全部，否則選擇一兩個(gè)來更好地監(jiān)控性能。其他指標(biāo)也需要留意，特別是我們發(fā)送的字節(jié)數(shù)(優(yōu)化和解壓縮)。

設(shè)置性能預(yù)算

所有這些上報(bào)數(shù)字可能會(huì)很快變得混亂和不易理解。沒有可操作的目標(biāo)和對(duì)象，很容易迷失我們最初的目的。幾年前， Tim Kadlec 寫過關(guān)于 性能預(yù)算 的概念。

遺憾的是，并沒有一個(gè)萬(wàn)能的神奇公式。性能預(yù)算通常歸結(jié)為競(jìng)爭(zhēng)分析和產(chǎn)品目標(biāo)，而這是每個(gè)業(yè)務(wù)所各異的。

設(shè)定預(yù)算時(shí)，重要的是要達(dá)到明顯的差異，通常是至少改善20%。實(shí)踐和迭代您的預(yù)算，利用 Lara Hogan 的 方法新設(shè)計(jì)與性能預(yù)算 作為參考。

試用 性能預(yù)算計(jì)算器 或Chrome擴(kuò)展 瀏覽器卡路里 ，以幫助創(chuàng)建預(yù)算。

持續(xù)監(jiān)控

監(jiān)控性能不應(yīng)該是手動(dòng)的。市面上有很多強(qiáng)大的工具，還可以提供全面的報(bào)告。

Google Lighthouse 是一個(gè)可以審核性能、可訪問性、漸進(jìn)式網(wǎng)絡(luò)應(yīng)用程序等的開源項(xiàng)目。您可以在命令行中或直接在 Chrome Developer Tools 中使用Lighthouse。

[Lighthouse 運(yùn)行一次性能審查]

對(duì)于持續(xù)的追蹤，選擇選擇 Calibre ，它可以提供性能預(yù)算、設(shè)備仿真、分布式監(jiān)控和許多其他功能，無(wú)需我們仔細(xì)構(gòu)建自己的性能套件即可獲得。

[Calibre 報(bào)表]

無(wú)論您在追蹤什么，請(qǐng)確保使整個(gè)團(tuán)隊(duì)或組織能夠透明地訪問數(shù)據(jù)。

性能是一項(xiàng)分擔(dān)責(zé)任，遠(yuǎn)遠(yuǎn)超過開發(fā)人員團(tuán)隊(duì)——我們都應(yīng)對(duì)所創(chuàng)建的用戶體驗(yàn)負(fù)責(zé)，不管是什么角色或職級(jí)。

倡導(dǎo)速度和建立協(xié)作流程，以便在產(chǎn)品決策或設(shè)計(jì)早期階段，盡早暴露可能遇到的瓶頸，是非常重要的。

建立性能意識(shí)和同情心

關(guān)心性能不僅僅是一個(gè)業(yè)務(wù)目標(biāo)(但是如果您需要通過銷售統(tǒng)計(jì)數(shù)據(jù)來進(jìn)行銷售，那么可以通過PWA統(tǒng)計(jì))。這是關(guān)于基本的同情和用戶體驗(yàn)放在第一位。

作為技術(shù)專家，我們的責(zé)任是，不要讓用戶的注意力和時(shí)間放在等待頁(yè)面上，而已可以更開心地花費(fèi)在其他地方。我們的目標(biāo)是 建立意識(shí)到時(shí)間和人們關(guān)注的工具 。

提倡性能意識(shí)應(yīng)該是每個(gè)人的目標(biāo)。讓我們抱著性能和同情心，為大家建立一個(gè)更好、更有意義的未來吧。