如何除錯前端：優化網路資源

stormluke發表於2019-02-28
除錯前端優化
如何除錯前端：優化網路資源

網路效能可以決定 web app 的成敗。最初 app 很新很小時，很少有開發者會持續關注 app 到底用了多長時間傳送了多少兆位元組給使用者。

如果你從未測量過自己 app 的效能，那很可能會有一些改進餘地。問題是，你需要改善多少才能讓使用者注意到。

在下面的研究中，你可以找到有關多長的載入時間差異可以被人們明顯地感受到的資訊。如果你想讓使用者注意到你的努力，那就要超過 20% 這個門檻。閱讀更多

這篇文章中，我會介紹（TL;DR）：

  • 通過 Chrome Devtool Audit 來測量效能
  • 影像優化
  • Web 字型優化
  • JavaScript 優化
  • 渲染阻塞資源時的優化
  • 其他效能測量應用/擴充套件

如果你正在努力解決這之外的一些問題，請在評論告訴所我們 —— 我們的團隊和讀者們很樂意提供幫助。

這篇文章是《如何除錯前端》系列的一部分：

衡量 app 的效能

Chrome Devtools Audits

由於整篇文章都是關於 Chrome Devtools 的，我們就先從 Audit 標籤頁開始（其本身使用了 Lighthouse）

開啟 Chrome Devtools > Audits > Perform an audit… > Run audit

我決定檢查效能（Performance）和最佳實踐（Best practices），但我們這次暫不涉及漸進式 Web 應用（Progressive Web App）或無障礙性（Accessibility）主題。

如何除錯前端：優化網路資源

不錯。一段時間後，我們完成了效能評估，並知道了一些改進這些效能指標的可行方法。如果 Audit 把螢幕解析度調成了「移動裝置」，請不必擔心，因為對於 Chrome 來說這是正常的。我強烈建議你用 Chrome 金絲雀版（Canary）來執行評估。金絲雀版有個可以評估桌面版網頁的選項，並且增加了網路限速功能 —— 看看下面的圖片。

如何除錯前端：優化網路資源

指標

如何除錯前端：優化網路資源

指標（Metrics）選項卡收集了基本的測量結果，並且提供了頁面載入時間的總體概況。

首次有意義繪圖（First meaningful paint） —— audit 確定使用者首次看到主要內容所需的時間。請儘可能保持在 1 秒以下。閱讀更多

首次可互動（First interactive） —— 指首次使用者看到可互動 UI 元素並且頁面可以響應所需的時間。

感知速度指數（Perceptual Speed Index） —— 指顯示頁面可見部分的平均時間。它以毫秒錶示並取決於視口的大小。請儘量保持在 1250 毫秒以下。閱讀更多

預估輸入延遲（Estimated Input Latency） —— 應用響應使用者輸入的時間，以毫秒為單位。

改進點

改進點（Opportunities） —— 是一個更詳細的部分，收集了有關圖片、CSS 和響應時間的資訊。我會介紹每個專案，並加上一些如何加速的小提示。

減少阻塞渲染（render-blocking）的樣式表

CSS 檔案被視為渲染阻塞資源。意味著瀏覽器會等待它們完全載入完畢，之後才開始渲染。最簡單的方法就是不載入不必要的 CSS 檔案。如果你使用 bootstrap，也許你不需要整個庫來樣式化你的頁面 —— 尤其是在專案剛開始時。

其次，你可以考慮針對不同螢幕尺寸進行優化。要降低載入 CSS 的數量級，可以使用條件載入，它只載入特定螢幕解析度所需的 CSS 檔案。下面有個例子。

<link href="other.css" rel="stylesheet" media="(min-width: 40em)">
<link href="print.css" rel="stylesheet" media="print">
複製程式碼

如果對你來說還不夠，Keith Clark 提出了一個不阻塞頁面渲染的載入 CSS 的好主意。訣竅是對媒體查詢（media query）使用帶有無效值的連結元素。當媒體查詢結果為 false 時，瀏覽器仍然會下載樣式表，但不會延遲渲染頁面。您可以將剩餘的不必要的 CSS 分離出來並稍後下載。閱讀更多

保持較低的服務響應時間

雖然這部分可能是不言自明的，但仍值得我們提醒自己它的作用。為了減少伺服器響應時間，你可以考慮為某些資源使用 CDN。也可以採用 HTTP2，或簡單地刪除不必要的請求，並在渲染頁面後延遲載入它們。

合適尺寸的圖片（Properly size Images）、離屏圖片（Offscreen images）和下一代格式（next-gen formats）

這三部分都與一個主題緊密相關 —— 圖片。要準確瞭解你正在載入哪些圖片以及它們所佔的時間比重，請進入 Chrome Devtools 的網路選項卡並通過 IMG 選項進行過濾。通過檢視大小和時間這兩行，看看你是否滿意這些結果。關於每個圖片的大小比重並沒有一般性的規則。這很大程度上取決於你的客戶端裝置、客戶端群以及更多隻有你自己才瞭解的情況。

如何除錯前端：優化網路資源

我想在這裡更多地談談圖片優化。在 Audit 結果中這個主題多次出現。

影像優化

圖片光柵圖和向量圖。光柵圖由畫素組成。我們通常將它們用於照片和複雜的動畫。副檔名：jpg、jpeg、gif。

向量圖由幾何影像組成。我們將它們用於徽標和圖示，因為它們可以隨意縮放不失真。副檔名：svg。

SVG

SVG 從一開始就相對較小，但用這些優化器可以使它更小。

光柵圖

這裡有點棘手，因為光柵影像可能非常大。有幾種技術可以使它們保持較大的解析度但仍有較小的檔案大小。

多張圖片

首先準備多個版本的影像。你並不想在手機上載入視網膜級大小的影像，對嗎？嘗試製作 3 到 4 個版本的圖片。手機版、平板版、桌面版和視網膜版。它們的大小取決於你的目標裝置。如果你有任何疑問，請檢視連結中的標準查詢。

Srcset 屬性

當你的影像準備好後，src 屬性有助於定義何時載入哪些影像。

<img src="ing.jpg" srcset="img.jpg, img2x.jpg 2x" alt="img">
複製程式碼

src 給不支援 srcset 的瀏覽器用
srcset 給支援的瀏覽器用
img2x.jpg 給畫素縮放比為 2.0 的裝置用（視網膜）

<img src="img.jpg" srcset="img1024.jpg 1024w, img2048.jpg 2048w" alt="img">
複製程式碼

src 給不支援 srcset 的瀏覽器用
srcset 給支援的瀏覽器用
img1024 給寬度為 1024 時使用，等等.

上面的例子來自於 Developer Mozilla

媒體查詢

你還可以建立上面提到過的媒體查詢和樣式，例如平板或手機。這種方法與 CSS 前處理器同時使用時特別有效。

srcset 屬性的替代品是媒體查詢，它的規則不在 HTML 中，而是在 CSS 檔案裡。對於純 CSS，這種方法非常耗時，不值得花時間去做。但在這裡，前處理器可以通過混入（mixins）和變數來解決問題。有了前處理器後，媒體查詢與 srcset 不相上下。決定權在你。

@desktop:   ~"only screen and (min-width: 960px) and (max-width: 1199px)";
@tablet:    ~"only screen and (min-width: 720px) and (max-width: 959px)";

@media @desktop {
  footer {
    width: 940px;
  }
}

@media @tablet {
  footer {
    width: 768px;
  }
}
複製程式碼

圖片 CDNs

當照片準備好並優化後，你還可以優化分發的過程。像 Cloudinary 這樣的工具可以顯著減少響應延遲。他們的伺服器遍佈全球，因此分發速度會更快。使用 HTTP 時，對於一個伺服器你只能開啟 6 個並行請求。使用 CDN 後，並行請求數量會隨著伺服器數量成倍增長。

延遲載入

有時候，圖片必須很花哨且很大。如果你為長時間的延遲而困擾，可以試試圖片模糊化或延遲載入。

延遲載入是一種在需要時才開始載入圖片或其他任何內容的方法。當相簿中有 1000 個圖片時，並非所有圖片都需要載入。只需載入前 10 個，其餘的等使用者需要時再載入。

有大量的庫可以做到這點。閱讀更多

Facebook 目前正在使用圖片模糊化。當你在網路不好的情況下開啟某人的資料頁時，剛開始圖片是模糊的；後來它才變得清晰。閱讀更多

診斷

如何除錯前端：優化網路資源

診斷頁（Diagnostics）結束了這一系列測試。我不會詳細介紹列表裡的每一個標題，因為其中一些主題已經介紹過了。我只會提及其中的一些，並試圖在整體上涵蓋這些主題。

對靜態資源使用了低效的快取策略

Goole 很注重快取和無伺服器應用。快取完全取決於你，我不是快取的忠實擁護者。如果你想了解更多快取的東西，Google 準備了一些不錯的課程。閱讀更多

關鍵請求鏈 / 阻塞渲染的指令碼

關鍵請求鏈（Critical request chains）包含了需要在頁面渲染前就完成的請求。保持它儘可能小至關重要。

我們之前提到了 CSS 載入，現在我們來討論一下 Web 字型。

優化 Web 字型

在建立 web 應用/網站時，目前我們使用四種字型格式：EOT、TTF、WOFF、WOFF2。

沒有一種格式是最合適的，因此我們需要再次針對不同的瀏覽器使用不同的格式。這個主題的入門教程和更多解釋在這裡。閱讀更多
不過在剛開始時，最好問問自己是否真的需要使用一個 web 字型。這裡有一篇關於它的非常好的文章。

字型壓縮

字型是形狀和路徑描述的集合，用於建立字母。每個字母都是不同的，但幸運的是他們有很多共同點，所以我們可以稍微壓縮一下。

由於 EOT 和 TTF 格式預設未壓縮，請確保你的伺服器配置了使用 GZIP。

WOFF 內建了壓縮功能。請在你的伺服器上使用最佳壓縮設定。

WOFF2具有自定義預處理。閱讀更多

限制字元

你是否只使用英文？請記住：不需要在字型中新增阿拉伯文或希臘文字母。你也可以使用 unicode 程式碼點。這使得瀏覽器可以將較大的 Unicode 字型拆分成較小的子集。閱讀更多

字型載入策略

載入字型會阻塞頁面渲染，因為瀏覽器需要使用其中的所有字型來構建 DOM。字型載入策略可以防止載入延遲。字型顯示（fonts-display）是策略之一，在 CSS 屬性中。閱讀更多

優化 JavaScript

不必要的依賴

現在，隨著 ES6 越來越重要，我們廣泛使用 webpack 和 gulp。在使用庫，務必記住，你並不總是需要整個庫。如果你不需要引入整個 lodash，只需引入一個函式。

import _ from `lodash ` —— 會把整個 lodash 庫加到包中

import {map} from `lodash` —— 也會把整個 lodash 庫加到包中，你可以使用 lodash-webpack-plugin、babel-plugin-lodash 這些外掛

import map from `lodash/map` —— 只會把 map 模組加入包中

仔細檢視框架中的 ES6 函式和你自己的函式。你不需要為每個功能都引入一個新庫。要檢查你的包是如何構建的，請使用下面連結中的工具。

其他工具

當然有更多的工具來衡量你網站的效能。

其中一個是 tools.pingdom.com，它或多或少地為你提供與 Audits + Network 選項卡相似的資訊。

如何除錯前端：優化網路資源

我同時也推薦安裝 PageSpeed Insights 這個 Chrome 擴充套件。它直接向你顯示哪個圖片需要更小點。

總結

本文試圖向你展示如何通過減少資源的大小來使你的網站更輕盈。這只是提高網站效能的第一步。畢竟，這個領域十分廣泛，並隨著現代前端的發展而變化。請關注這個話題和你的競爭對手。儘量提前一步。

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

相關文章