http://www.wtoutiao.com/p/1deiv1x.html

開發者應該瞭解的 web 效能

併發程式設計網(ifeve) · 2016-01-04 22:16

網站的快和慢有什麼區別呢？

存在一種正確答案嗎？

沒有，很不幸，還沒有。原因在於網站具備很多因素，每種因素都有可能減慢網站。因此，本文不會給你提供一份需要完成的清單，而是打算解釋清楚，某些因素是怎樣減慢網站的，以及相應地你能做些什麼。

正如諺語所說的：

授人以魚，不如授之以漁；授人以魚只救一時之及，授人以漁則可解一生之需。

除了讓你給指令碼增加 “async” 標籤，或按照特定順序佈局頁面之外，我還打算解釋這些修改所帶來的差異。這樣，你就能折騰你的應用程式，並確認哪些修改是有用的。

1每個人都應該做的一件事就是加速頁面載入

正如我剛才提過的，不存在這樣的事情。web 有些出乎意料地複雜。使頁面載入速度降低的現象，對你而言，或許不能成為專注的正確標準！

然而，有些相當重要的因素，通常會帶來顯而易見的不同。你之前或許碰到過，但是或許不理解它們為什麼重要。

用 gzip 壓縮傳輸 HTML、CSS 和 JavaScript，減少了需要流經線纜的位元組數。這可以顯著減少下載資源的時間。瀏覽器渲染頁面，離不開 HTML 和 CSS，因此我們想盡快下載這些資源。

我有個朋友，他給客戶搭建 WordPress 網站，有很多網站常常上傳大量圖片，我最近和他聊了一次。他遇到了一個問題，客戶直接把相機裡的圖片上傳到他們的網站。

手機拍攝的照片超過 1MB。就算你用 CSS 調整大小，仍然需要通過線纜下載這副非常大的圖片。網速慢的使用者需要等待很長時間才能開啟。

幸虧有應付的方法。我有段節目和優化圖片相關。如果你還沒有看過，我強烈推薦給你。

檢視不同頁面裡的指令碼和 CSS 檔案，自問一下，這些檔案對於頁面是不是真的需要。你很可能找到一些檔案，它們被新增上去之後就再沒去掉。

外掛在這方面的表現，真的很糟糕。我接觸的相當一部分 ebordPress 網站，載入了一大堆 CSS 檔案，其中有一半檔案在某些頁面根本用不到！很多非 WordPress 網站也有類似現象。我早些時候檢查 scaleyourcode.com 上的某些頁面時，也發現它們正載入一個不必要的指令碼。

清除指令碼或樣式表，會讓人害怕。如果它對於那個頁面真的是必需的、只是你不記得了，該怎麼怎麼辦？有一些工具可以幫我們確認，推薦 DevTools（在 Audits 下）。

你能看出這些優化措施之間的共同點嗎？它們都減少了我們需要傳輸的位元組數。

2漸進式渲染

你需要儘早將 HTML 位元組給到瀏覽器。

比如：一個請求進來了，（理想狀態下）你的資料被快取起來，因此伺服器能夠快速獲取。然後，瀏覽器開始解析資料，並在螢幕上呈現出來。

我剛才提到了，頁面載入時間可能不是你需要專注的效能標準，這得感謝漸進式渲染。

漸進式渲染

頁面可以龐大，不過，只要你在短時間內（最好少於 1 秒）呈現給使用者一些內容，他們仍然覺得載入很快。

Amazon 在這方面就做得不錯：

Amazon 的漸進式渲染

對於此次 WebPageTest，在 1.5 秒就得到了第一屏，但是你能看到，它沒有包含所有內容。它包含的內容足以讓你開始瀏覽頁面、或檢視假日交易。

然後，到 3.5 秒，另一部分載入了更多交易。到 6.5 秒，一些東西仍然在載入！事實上，整個頁面載入的完成一直持續到 18 秒。你能等那麼長時間嗎？我表示懷疑！

如果 Amazon 專注於最慢的頁面載入，那麼一定有人被激怒。他們卻專注於在最早的 packet 裡傳送最重要的位元組。再進一步，他們可能在第一個 packet 裡塞滿最重要的位元組。我敢打賭，他們還專注於盡快地為你傳送那些位元組。

這就是 TTFB (Time To First Byte) 的由來。

當瀏覽器發起一個頁面請求時，它就處於等待響應的狀態。TTFB 代表了它需要多長時間才能收到第一個響應的位元組。這個時間不但代表了你的伺服器產生響應所需要的時間，而且意味著經過線纜傳輸所需要的時間。

這張圖有著非常快速的 TTFB。如果你去網上逛逛，就能看到不同的 TTFB，你看到的情況類似於下圖：

為什麼會是這種情況，我們該如何最小化該時間呢？你應該專注對其優化了嗎？不錯的問題，我就此準備了更多資料。

如果你有興趣瞭解更多資訊，那麼，請參考 Steve Souders 的精彩演講，談到了用來測量的效能標準。頁面載入時間不總是最好的標準。

3能讓內容更快呈現的其它因素？

既然我們有了更快的 TTFB，那麼每個地方都會極速呈現嗎？不一定，我們看看關鍵呈現路徑。

關鍵呈現路徑是瀏覽器為了得到 HTML、構建 DOM、得到樣式資訊、執行關鍵的 JavaScript 以及繪製內容、而不得不執行的步驟順序。

天哪，要做的工作真不少呀。

這就是我們需要慎重對待它的原因。HTML、CSS 和 JavaScript 越多，需要的時間就越長。當載入 JavaScript 檔案時，新增 async 標籤，原因就在於此。

當瀏覽器遇到 JavaScript 時，它可能不知道這裡的 JS 是否要改變 DOM。因此，它不得不假定它會改變，然後它阻止渲染，直到 JavaScript 完成了執行過程。如果增加了 async 標籤，相當於向瀏覽器保證，該 JS 對於頁面不是關鍵的，因此瀏覽器可以繼續渲染，而不必等待 JS 執行完成。

如果碰到修改頁面的指令碼，那麼是否意味著不應該非同步呀？可能。儘管如此，即使你非同步化了修改頁面的指令碼，那麼從使用者視角看，這種做法也是實用的。使用者能夠看到內容，並開始產生互動。的確，某些地方或許無法呈現，也可能需要多等一會兒。當然，這都取決於你的應用程式，因此嘗試一下，看看是否滿足你的需求。

關鍵路徑對於儘可能快地接收位元組如此重要，原因在於你能夠越早地開始處理整個過程，就能越快地完成。關於優化關鍵渲染路徑，請參考這裡。

4你該怎樣測量非同步（或其它優化方式）對應用程式的好與壞？

有個不錯的測量工具，WebPageTest。你能夠得到各種有用資訊，包括幻燈片檢視。幻燈片檢視就是我剛才用以展示 Amazon 頁面的視覺化過程。你可以用在你的網站上，並列比較有無非同步的差異。

直到最近，DevTools 實現了自己的幻燈片檢視。

開啟 Chrome DevTools，點選 TimeLine -> 開啟 Screenshots -> 重新載入頁面。

你就能看到頁面載入過程的截圖了。不錯吧？

現在，你可以：

1. 切換你的網路速度（記住，不是每個人都有超快的網際網路）

2. 檢視幻燈片檢視

3. 把指令碼改成非同步（或做出其它調整）

4. 對比幻燈片

你可以在 DevTools 裡調整網速

另一個工具是 SpeedCurve，這是我最近無意間發現的。它由兩個聰明的傢伙開發：Mark Zeman 和 Steve Souders，看起來很有幫助。

5DevTools 非常優秀了，我們怎樣才能更好地理解其用法呢？

難點在於增加了太多功能所不幸引起的副作用。

除了看上面的例子，我們開始學習並實踐的更好方式是什麼呢？對於怎樣在實際網站中使用 DevTools，Paul Lewis 和其他人已經體驗了。這裡是關於修復滾動效能問題的極好例子

http://www.5icool.org/a/201412/a9501.html

Web效能優化教程：如何對網站圖片優化？

HTTP Archieve有個統計，圖片內容已經佔到了網際網路內容總量的62%，也就是說超過一半的流量和時間都用來下載圖片。從效能優化的角度看，圖片也絕對是優化的熱點和重點之一，Google PageSpeed或者Yahoo的14條效能優化規則無不把圖片優化作為重要的優化手段，本文覆蓋了Web圖片優化的方方面面，從基本的圖片格式選擇、到尚未被廣泛支援的響應式圖片均有所提及。

Google Web Fundamentals的說法我很喜歡：

圖片優化既是一門藝術，也是一門科學，圖片優化是一門藝術，是因為單個圖片的壓縮不存在最好的特定性方案，而圖片優化之所以是一門科學，是因為許多開發得很出色的方法和演算法可以明顯減小圖片的大小。要找到圖片的最優設定，需要按照許多維度進行認真分析：格式能力、編碼資料內容、畫素尺寸等。

真的要用圖片嗎？

要實現需要的效果，真的需要圖片嗎？這是首先要問自己的問題。瀏覽器和Web標準的發展速度極快，記得數年前我在用微軟Silverlight 1.0寫視訊播放器的時候，中文還不能使用自定義字型顯示，所以那時候寫了很多糟糕的程式碼把需要的文字在伺服器上生成圖片並快取起來。使用者下載起來很慢，搜尋引擎也完全無法檢索這些文字。

但是現在不一樣了，很多特效（漸變、陰影、圓角等等）都可以用純粹的HTML、CSS、SVG等加以實現，實現這些效果少則寥寥數行程式碼，多則載入額外的庫（一張普通的照片比非常強大的效果庫也大了許多）。這些效果不但需要的空間很小，而且在多裝置、多解析度下都能很好的工作，在低階瀏覽器上也可以實現較好的功能降級。因此在存在備選技術的情況下，應該首先選擇這些技術，只有在不得不使用圖片的時候才加入真正的圖片。

備選技術

• CSS效果、CSS動畫。提供與解析度無關的效果，在任何解析度和縮放級別都可以顯示得非常清晰，佔用的空間也很小。
• 網路字型。現在連很多圖示庫都是用字型方式提供，保持文字的可搜尋性同時擴充套件顯示的樣式。

前端工程師最好能和設計師、產品經理保持溝通，幫助他們瞭解到什麼樣的效果比較“簡潔、高效、可維護”，畢竟對於CSS來說改變圓角矩形的Radius可以實時看到效果，用圖片的話至少要重新生成圖片、切圖並替換資源。Retina、高解析度螢幕、多尺寸的裝置，這些都加快了非圖片特效的發展，想想在高解析度螢幕下Windows 7的慘不忍睹，就知道原生的圖片資源絕對不是多多益善。

圖片格式的選擇

如果效果真的需要圖片來表現，那麼選擇圖片格式是優化的第一步。我們經常聽到的詞語包括向量圖、標量圖、SVG、有失真壓縮、無失真壓縮等等，我們首先說明各種圖片格式的特點：

其中APNG和WebP格式出現的較晚，尚未被Web標準所採納，只有在特定平臺或瀏覽器環境可以預知的情況下加以採用，雖然均可以在不支援的環境中較好的功能降級，但本節暫不討論這兩種格式。圖片格式選擇過程如下：

顏色豐富的照片，JPG是通用的選擇

• 人眼的結構很適合檢視JPG壓縮後的照片，可以充分的忽略並在腦中補齊細節
• JPG在壓縮率不高時保留的細節還是不錯的
• WebP能夠比JPG減少30%的體積，但目前相容性較差

如果需要較通用的動畫，GIF是唯一可用的選擇

• GIF支援的顏色範圍為256色，而且僅支援完全透明/完全不透明
• GIF在顯示顏色豐富的動畫時可能出現顏色不全、邊緣鋸齒等問題

如果圖片由標準的幾何圖形組成，或需要使用程式動態控制其顯示特效，可以考慮SVG格式

• SVG是使用XML定義的向量圖形，生成的圖片在各種解析度下均可自由放縮
• SVG中可以通過JavaScript等介面自由變換圖片特效，可以完成其中部分元素的自由旋轉、移動、變換顏色等

如果需要清晰的顯示顏色豐富的圖片，PNG比較好

• PNG-8能夠顯示256種顏色，但能夠同時支援256階透明，因此顏色數較少但需要半透明的情景（如微信動畫大表情）可以考慮PNG-8
• PNG-24可以顯示真彩色，但不支援透明，顏色豐富的圖片推薦使用（如螢幕截圖、介面設計圖）
• PNG-32可以顯示真彩色，同時支援256階透明，效果最好但尺寸也最大

圖片尺寸的選擇

尺寸，曾經是最不需要討論的話題，但自從Retina出現之後世界就變得複雜多了。

這裡只說我們關心的部分和結論，我們需要分清不同型別的畫素：CSS畫素和裝置畫素。一個 CSS畫素可能包含多個裝置畫素。對於圖片來說，在高DPI的螢幕上需要使用解析度更高的圖片，如果我們討論的是Retina，那麼就需要2倍解析度（幾乎4倍尺寸）的圖片。這幾乎沒有取巧的空間，螢幕就是那麼大，需要的圖片也就是那麼大。（鴿子為什麼那麼大？^_^）

我們能夠控制的地方是“恰好”顯示所需尺寸的圖片。例如在螢幕中通過CSS或者標籤的wihth/height屬性，將一副200x200的圖片調整為100x100大小，那麼這其中就有(200x200)-(100x100)=30000個畫素是浪費的，這佔到了圖片尺寸的75%！

之所以有這麼大的浪費，是因為圖片的尺寸與面積基本成正比，與寬高的平方成正比。因此良好的計算客戶端實際顯示的圖片尺寸，能夠大大減小圖片的大小。即使只有長和寬都只有10px被浪費，但是當圖片足夠大時，這部分也將產生很大影響。

響應式圖片

上面提到“恰好”顯示客戶端所需大小的圖片，聽上去很容易不是嗎？但當響應式佈局出現後，這就變得極其困難。我們要支援上至1920寬度，下至320寬度的無數種裝置，如果使用1920寬度的圖片，那麼在小型裝置（這類裝置往往對網速和流量更加敏感）上每個使用者都要付出額外的頻寬和等待時間，如果使用320寬度的圖片，那麼在1920的螢幕上就像是在高清屏上使用DOS那麼讓人難以接受。

很自然的，我們需要圖片也能“響應式”載入，根據所在裝置的不同，載入不同尺寸的圖片。響應式圖片尚沒有寫入Web標準，實現起來也有諸多不便和相容性限制。

響應式圖片雖然尚未成為標準，但這是Web圖片優化的一柄利器，一旦被廣泛支援，再沒有比縮小圖片尺寸更有效的優化方法了。

優化JPG和PNG

選擇了正確的圖片格式，按照正確的大小生成了圖片後，我們還需要對圖片進行進一步優化，這種優化一般分兩步進行：

• 有損優化，刪除沒有出現或極少出現過的顏色，合併相鄰的相近顏色。這一步並不必須，如PNG格式就直接進入下一步
• 無損優化，壓縮資料，刪除不必要的資訊

JPG和PNG格式的圖片生成後，一般還有進一步優化的空間，例如JPG格式的照片中，可能攜帶有相機的Exif資訊，PNG格式的圖片中可能帶有Fireworks等軟體的圖層資訊等。去除這些額外資訊後，還可以通過減小圖片的調色盤，去除沒有出現過的顏色，以及合併相鄰的相同顏色等手段來進行優化。原理性的內容這裡不再贅述，僅介紹工程中可用的優化工具。

不同格式的圖片有一系列工具，這些工具有有更多種引數調節方案，常見的幾種調節工具有：

如果你真的需要追求各種圖片的極限壓縮，可以參閱這些工具的文件，但是對於一般的Web應用，面對的圖片種類多樣，幾乎不可能在工程中實現對每種工具的獨立配置，因此推薦使用以下工具來進行優化。這些工具往往使用了上表中的一種或幾種優化工具。

ImageOptim (Mac)

主頁：https://imageoptim.com/

Mac平臺下非常讚的圖片優化工具，只需要把需要優化的圖片拖拽進ImageOptim，就能夠完成對圖片的優化。設定選擇的也很豐富，目前支援JPG和PNG的優化。這是我在寫文章時最常用到的工具，把網站用到的圖片拖進去，優化就完成了~

Kraken (Web)

主頁：https://kraken.io/

在免費模式下可以上傳圖片，優化後打包下載，很多國外企業也選擇了它的收費服務。親自測試Kraken的圖片優化結果比ImageOptim一般要小3%左右，效果不錯，當然價格也不錯。適合偶爾有圖片優化需求，或者不在開發機上沒有優化軟體可以使用的情況。

智圖 (Web)

主頁：http://zhitu.tencent.com/

騰訊ISUX團隊有篇文章介紹智圖：http://isux.tencent.com/zhitu.html

國貨當自強，騰訊的智圖工具推出不久，但實測效果很好，而且提供了Gulp的自動化支援，這部分會在後面自動優化章節介紹。只想建議一句，Kraken的首頁比智圖美好幾百倍…… 而且把壓縮前的PNG和壓縮後的JPG放在一起對比大小，真的沒關係麼~

優化SVG

所有較新的瀏覽器都支援可縮放向量圖(SVG)，SVG是基於XML的圖片格式，適用於二維圖片。可以將SVG標記直接嵌入網頁，也可以作為外部資源嵌入。可以通過大多數基於向量的繪圖軟體建立SVG檔案。這是一段簡單的SVG圖形：

這個圓形輪廓為黑色，背景為紅色，從Adobe Illustrator直接匯出。可以從中看到大量元資料，例如圖層資訊、註釋和XML名稱空間等等，在瀏覽器中呈現資源時，通常不需要這些資料。因此我們需要使用一些工具去除這些不必要的元資料，僅保留必須的標記。

SVGO工具可以縮減SVG檔案的體積，在這個的例子中，SVGO能夠將Illustrator生成的SVG檔案大小減小58%，從470位元組縮減到199位元組。

由於SVG是基於XML的格式，本質上是純文字，所以，還可以採用GZIP壓縮來減小傳輸大小，當然這需要一些伺服器配置，例如在apache伺服器中設定：

AddType image/svg+xml .svgAddOutputFilterByType DEFLATE image/svg+xml

來對SVG檔案啟用GZip壓縮（當然你還需要先載入deflate模組並進行適當配置，GZip的配置超出了本文的範疇，這部分內容請自行Google）

優化GIF和APNG

GIF有很多好處，在顏色數較低的時候能夠大幅減小圖片體積，而且他也是唯一能夠較為通用的展示動畫的圖片格式。關於GIF格式的優化原理我並不熟悉，只是在工程中直接使用成型的壓縮工具，在後文自動優化章節的Grunt中，會介紹通過Grunt Task進行自動優化的方法。

關於APNG，目前瀏覽器對他的支援還不夠好，不過在支援HTML5的場景中，有成熟的開源工具apng-canvas可以用於支援APNG。

騰訊ISUX團隊有篇文章介紹iSparta工具：http://isux.tencent.com/introduction-of-apng.html。這是目前幾乎唯一能夠批量處理APNG檔案的工具，感興趣的同學可以在那篇文章裡得到更多地瞭解。

自動優化

前面說了太多關於如何優化各種不同格式圖片的方法和工具，優化圖片需要大量重複性的勞動，作為工程師顯然不會忍受這一點，因此也產生出了很多工具對圖片進行自動優化，這裡主要介紹CDN、Grunt/Gulp、Google PageSpeed三種方式。

自動優化：CDN

使用CDN對圖片自動進行優化，我在國外的CDN提供商處很少見到這類服務，倒是國內的兩大新秀CDN七牛和又拍在這方面都做了大量工作。其工作方式為，向CDN請求圖片的URL引數中包含了圖片處理的引數（格式、寬高等），CDN伺服器根據請求生成所需的圖片，傳送到使用者瀏覽器。

七牛雲端儲存的圖片處理介面極其豐富，覆蓋了圖片的大部分基本操作，例如：

• 圖片裁剪，支援多種裁剪方式（如按長邊、短邊、填充、拉伸等）
• 圖片格式轉換，支援JPG, GIF, PNG, WebP等，支援不同的圖片壓縮率
• 圖片處理，支援圖片水印、高斯模糊、重心處理等

七牛雲端儲存的圖片處理介面使用並不複雜，例如下面這張原圖：

我們通過如下URL請求，裁剪正中部分，等比縮小生成200x200縮圖：

http://upload.chinaz.com/2014/1222/1419227799432.jpg?imageView2/1/w/200/h/200

自動優化：Grunt/Gulp

這裡介紹用於圖片優化的Grunt元件：grunt-image。前端工程師的重複性工作，例如合併靜態資源、壓縮JS和CSS檔案、編譯SASS等都可以使用Grunt等自動化工具批量完成，圖片優化也是如此。

grunt-image非常強大，按照作者的介紹，其內部載入的圖片優化工具包括了pngquant, optipng, advpng, zopflipng, pngcrush, pngout, mozjpeg, jpegRecompress, jpegoptim, gifsicle和svgo。支援批量自動優化PNG, JPG, SVG和GIF，速度也不錯，配置方式支援單圖片優化和全目錄優化：

自動優化：Google PageSpeed

Google做事風格比較徹底，看見哪個軟體不好用就拿來直接fork出新版本或者乾脆重寫，對於Web優化，Google釋出了了Google PageSpeed這個伺服器模組，可以在apache或ngnix中載入，通過在伺服器配置檔案中進行設定來進行自動化的優化。對於圖片格式轉換、圖片優化甚至圖片LazyLoad都有相關選項。這部分展開會非常長，請感興趣的同學參考Google的手冊