如何運用最新的技術提升網頁速度和效能

阿新 • • 發佈：2019-01-17

最近更新了我們的網站，它是經過了設計上的全面驗收的。但實際上，作為軟體開發者，我們會注重很多技術相關的零碎的東西。我們的目標是控制性能，注重效能，未來可伸展，為網站增添內容是一種樂趣。接著就來告訴你，為什麼我們的網站速度比你們的快吧（抱歉，確實是這樣的）。

效能設計

在我們的專案中，我們每天都會和設計師和產品負責人討論關於平衡美觀和效能的問題。對於我們自己的網站，這樣做是很簡單的。簡言之，我們認為好的使用者體驗從快速的內容傳輸開始，也就意味著 效能 > 美觀。

好的內容、佈局、圖片和互動是吸引使用者的重要因素。這每個因素都會影響頁面的載入時間和終端使用者體驗。每一步我們都在探討如何在獲得好的使用者體驗和保證設計美感的同時，最小化對效能的影響。

內容優先

我們想要把核心內容儘快地呈現給使用者，意味著我們要處理好基本的 HTML 和 CSS。每個頁面都應該達到基本的目的：傳遞資訊。JS、CSS、網頁字型、圖片、網站分析等優化都是位居於核心內容之下的。

可控性

給理想網站定義了標準後，我們總結出：要想達到預期效果，就要能對網站各方面的控制都遊刃有餘。我們選擇構建自己的靜態站點生成器，包括資源傳輸，並且由我們自己操控。

靜態站點生成器

我們用 Node.js 實現了靜態站點生成器。它是採用帶有簡短 JSON 頁面描述標籤的Markdown 檔案來生成整個網站結構和它所有的資源。為了包括特殊的頁面指令碼，也可以附帶一個 HTML 檔案。以下是一個簡單化的描述標籤和 markdown

檔案，用於部落格的釋出，用它來生成真正的 HTML。

JSON 描述標籤:

JavaScript

{
  "keywords": ["performance", "critical rendering path", "static site", "..."],
  "publishDate": "2016-07-13",
  "authors": ["Declan"]
}

12345

{"keywords":["performance","critical rendering path"

,"static site","..."],"publishDate":"2016-07-13","authors":["Declan"]}

markdown 檔案:

# Why our website is faster than yours
We've recently updated our site. Yes, it has a complete...

## Design for performance
In our projects we have daily discussions...

12345

# Why our website is faster than yoursWe've recently updated our site.Yes,it hasacomplete...## Design for performanceInour projects we have daily discussions...

圖片傳輸

平均一個 2406kb 的網頁中 1535kb 是圖片。就因為圖片在網站中佔據了這麼大的一個比例，所以它也是效能優化的重點之一。

WebP格式

WebP是一種現代圖片格式，為網頁圖片提供了出色的低損耗、有失真壓縮。WebP格式的圖片實質上比其它格式的小，有時可以比同樣的 JPEG 圖片小 25%。 WebP被大多數人所忽略，也沒被經常使用。截止到寫這篇文章的時候，WebP 僅支援Chrome, Opera 和 Android (仍超過了我們50%的使用者)，但我們可以優雅降級為 JPG/PNG。

使用 <picture> 元素我們可以把圖片從 WebP 優雅地降級到其它被廣泛支援的圖片格式，如JPEG:

XHTML

<picture>
  <source type="image/webp" srcset="image-l.webp" media="(min-width: 640px)">
  <source type="image/webp" srcset="image-m.webp" media="(min-width: 320px)">
  <source type="image/webp" srcset="image-s.webp">
  <source srcset="image-l.jpg" media="(min-width: 640px)">
  <source srcset="image-m.jpg" media="(min-width: 320px)">
  <source srcset="image-s.jpg">
  <img alt="Description of the image" src="image-l.jpg">
</picture>

123456789

我們使用Scott Jehl 的 picturefill 來使那些不支援 <picture> 元素的瀏覽器獲得支援，在各個瀏覽器中達到一致的效果

我們使用 <img> 作為那些不支援 <picture> 或者 JS 的瀏覽器的後備元素。使用圖片的最大例項確保了它在後備方案中的可行性。

生成

儘管圖片傳輸方式已經確定了，我們仍需要思考該怎樣有效地執行。我喜歡 <picture>元素的功能，但不喜歡寫上面那些程式碼段，尤其是寫內容時必須把它加進去。我們不想做這麼費力的事情：每張圖片都要寫 6 個例項，所以優化這些圖片並且把它們寫在markdown檔案的 <picture> 裡面。所以：

生成圖片

在構建過程中，原圖片的多個例項，包括JPG, PNG和WebP格式，我們使用 gulp responsive 來生成。

最小化圖片

在markdown檔案中寫`[圖片描述](image.jpg)`.

在構建過程中使用自定義Markdown渲染器來為已經完全成熟的 <picture> 元素編譯傳統的markdown圖片宣告。

SVG動畫

我們為自己的網站選擇了特定的圖示型別，其中SVG插圖佔了主要地位。這樣做有以下幾個原因：

首先，SVG的圖片比點陣圖更小；
其二，SVG圖片本身就是響應式的，有很棒的伸縮性, 所以不需要圖片生成及<picture> 元素；
最後也是很重要的一點，就是我們可以通過CSS來不斷改變它，賦予它新的活力！我們所有的組合頁面都有一個自定義的動態SVG圖, 可以被概述頁面所複用。這張圖片作為我們所有組合頁面的一種迴圈風格，使得頁面設計一體化，同時又幾乎不會對效能造成影響。請看這張動畫，看看我們是如何用CSS來改變它的。

自定義網頁字型

在深入之前，這裡有一個關於在瀏覽器設定自定義字型的簡短介紹。當瀏覽器發現CSS裡面有@font-face 的定義，但是使用者的電腦並不支援該字型時，它會嘗試下載該字型檔案。在下載時，多數瀏覽器根本不會用這種字型來展示文字。這種現象稱為“不可見文字的閃現” 或者 FOIT。如果你有留意，你會發現網頁上都有這種情況存在。如果你問我，我會告訴你這會影響使用者體驗。它延遲了使用者讀取他們所需內容的時間。我們可以迫使瀏覽器改變這種行為，變成 “無樣式內容閃現” 或者稱為 FOUT。我們告訴瀏覽器先使用普通字型，像 Arial 或者 Georgia。當自定義的字型下載完成後，再代替標準字型並且重新渲染。這樣，即使自定義字型下載失敗，仍然不會影響內容的可讀性。然而，有人會認為這是一種妥協的做法，但我們認為自定義字型只是一種優化。儘管沒有自定義字型，網頁看起來也完好，也能百分百的正常執行。勾選/不勾選複選框來切換我們的網頁字型，來自己體驗一下：

切換下載的字型類使用自定義網頁字型可以改善我們的使用者體驗，只要你能夠優化他們，並且負責任地為之服務。

字型子集設定

到目前為止，子集設定是改善網頁字型效能最快的方式。我將會向每個使用自定義字型的網頁開發者推薦它。如果你能完全控制網頁內容，並且知道它將要展示哪些特性的話，你可以完全使用子集設定。但是，即使是僅僅把字型設為西方語言，也會對檔案大小造成很大的影響。例如，我們的 Noto Regular WOFF 字型，預設是246KB，將其設為西方語言後，大小下降到31KB。我們使用 Font squirrel webfont, 這種字型真的很易用。

字型監聽器

Bram Stein 推出的字型監聽器是一個很了不起的指令碼，可以幫助檢查字型是否已被載入。至於你是如何載入字型的，是通過一個網頁字型服務，還是自己上傳就不可知了。在這個監聽器告訴我們所有自定義的字型已經下載完畢後，我們就可以在 <html> 元素上新增一個字型載入完畢的類，我們的頁面就會重新用新的字型：

CSS

html {
   font-family: Georgia, serif;
}

html.fonts-loaded {
   font-family: Noto, Georgia, serif;
}

1234567

html {font-family:Georgia,serif;}html.fonts-loaded {font-family:Noto,Georgia,serif;}

注意：為了簡短，我沒有給上面CSS中的 Noto 加上 @font-face 的宣告。

我們可以設定一個cookie來記住所有的字型已經被載入過，就可以讓他們快取在瀏覽器裡面了。我們使用這個cookie來做重複的瀏覽，這個我後續會解釋。

在不久的將來，我們或許不需要 Bram Stein 的指令碼來監聽這個行為。CSS開發團隊已經提案一個新的 @font-face 描述器，也叫 font-display。它的屬性值控制著一個可下載的字型是如何在還沒加載出來時就渲染頁面的。這是CSS對font-display的描述：它將帶給我們像上面方法一樣的行為效果。你可以讀讀更多關於 font-display 的屬性。

JS和CSS懶載入

一般來講，我們都是儘可能快的載入需要的資源。我們移除一些堵塞的請求來加快頁面渲染，優化首屏，用瀏覽器快取來處理重複的頁面。

JS懶載入

設計上，我們的網站並沒有很多JS。我們發展了一個JavaScript工作流來處理我們目前已有的js, 以及未來會用到的js資源。

JS在 <head> 塊裡面渲染，這是我們想要的。JS應該只是用來提高使用者體驗，不應該是訪問者需要的關鍵。處理JS堵塞渲染的簡單方法就是把指令碼放在頁面的尾部。這樣網頁就會在整個HTML 渲染完畢後才去載入JS。

另一種可以把指令碼放在 head 執行的方案是在 <script> 標籤裡面新增 defer 屬性，來延遲指令碼的執行。由於瀏覽器下載指令碼是很快的，不會堵塞頁面渲染程序，等到頁面完全載入完，才會執行腳本里面的程式碼。還有一件事，我們沒有使用像jQuery這些庫，所以我們的指令碼取決於 vanilla 指令碼的特性。我們只是想要在瀏覽器載入指令碼來支援這些特性。最終的結果就像下面的程式碼這樣：

XHTML

<script>
if ('querySelector' in document && 'addEventListener' in window) {
  document.write('<script src="index.js" defer><\/script>');
}
</script>

12345

我們把這小段指令碼放在頁面頭部，來檢測瀏覽器是否支援原生JavaScript的document.querySelector 和 window.addEventListener 屬性。如果支援，我們通過<script> 標籤直接給頁面載入指令碼，並使用 defer 屬性讓它不會堵塞頁面渲染。

懶載入CSS

對於首屏來講，網站最大的渲染堵塞資源就是CSS了。只有當 <head> 裡面的CSS檔案完全載入完畢時，瀏覽器才會開始渲染頁面。這種做法是經過深思熟慮的，若不是這樣，瀏覽器就需要在整個渲染過程中不斷重新計算佈局尺寸，不斷重繪。

為了防止CSS堵塞渲染，我們就需要非同步載入CSS檔案。我們使用了 Filament Group的 awesome loadCSS 函式。該函式提供了一個回撥，當CSS檔案載入完後，我們設定一個cookie來宣告CSS檔案已經載入了。我們使用這個cookie來重現頁面，這一點我後續會解釋到。

CSS非同步載入也帶來這樣一個問題，儘管 HTML 真的很快被渲染出來，但看起來就只有純粹的HTML，只有等到整個CSS檔案載入完且停止時，才會有樣式。這時就要提到關鍵CSS了。

關鍵CSS

關鍵CSS就是阻塞瀏覽器渲染出使用者可識別的網頁的一小部分CSS。我們注意網頁的 上半版版面。很明顯，兩個裝置的版面的位置有很大的區別。因此，我們做了一個大膽的猜測。

手動地檢測這部分關鍵性的CSS是個很耗時的過程，尤其是樣式、特性等不斷改變時。這裡有幾個好的指令碼，可以在你構建網頁時，生成關鍵性CSS。我們採用了 Addy Osmani的版本。

下面是我們分別用關鍵性CSS和整份CSS分別渲染的頁面效果。注意到下半版仍然有部分內容還沒有樣式。

左側網頁是用關鍵CSS渲染的，而右側網頁則是用整份的CSS。紅線是分界線。

服務端

我們自己部署 de Voorhoede 網站，因為我們希望能夠控制伺服器環境。我們也想要嘗試，是否可以通過改變服務端的配置來大大提升效能。當前我們使用了 Apache 服務和 HTTPS 協議。

配置

為了提升效能和安全性，我們研究瞭如何配置服務端。

我們使用 H5BP apache樣板配置，這個對於改善Apache網路服務的效能和安全性是個很好的開始。他們也有其他伺服器環境的配置。對於我們的大部分 HTML、CSS 和 JS，我們使用GZIP壓縮。對於我們的所有網站資源，都使用快取HTTP標頭的做法。有興趣請閱讀檔案層級快取的章節。

HTTPS

用HTTPS來服務你的網站會對效能造成影響。這主要是設定了SSL握手，引入了大量潛在的東西。但通常情況下，我們可以做一些改變！

HTTP Strict Transport Security 是一個HTTP標頭，可以讓伺服器告訴瀏覽器只能用HTTPS來與它互動。這種方式防止HTTP請求被重定向為HTTPS。所有嘗試用HTTP來訪問站點的請求都會被自動轉換成HTTPS。這樣就節省了一個來回。

TLS false start 允許客戶端在第一個TLS回合結束後，馬上向後端傳送加密的資料。這種優化為一個新的TLS連線減少了握手次數。一旦客戶端知道了金鑰，就可以開始傳輸應用資料。剩下的握手用來確認是否有人篡改了握手記錄，並且可以並行處理。

TLS session resumption 通過確認瀏覽器和伺服器是否已經取得聯絡來幫我們節省一個來回。瀏覽器會記住這一次的識別符號，下次發起連線時，這個識別符號就會被重用，節省了一個來回。

我聽起來像是一個搞開發和運維的，但確實不是。我只是讀過一些書，看過一些視訊。我喜歡 Google I/O 2016 的 Mythbusting HTTPS：Emily Stark 的安全性都市傳奇。

cookies的使用

我們沒有用一門服務端的語言，只有靜態的 Apache 網路服務。但一個 Apache 網路服務仍可以做包括SSI在內的後端服務，並且讀取cookies。通過巧用cookies和執行那部分被Apache改寫的HTML，我們可以大大提升前端效能。下面這個例子就是了（我們實際的程式碼比這個複雜點，但是思想上是一致的）：

XHTML

<!-- #if expr="($HTTP_COOKIE!=/css-loaded/) || ($HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != '0d82f.css' )"-->

<noscript><link rel="stylesheet" href="0d82f.css"></noscript>
<script>
(function() {
    function loadCSS(url) {...}
    function onloadCSS(stylesheet, callback) {...}
    function setCookie(name, value, expInDays) {...}

    var stylesheet = loadCSS('0d82f.css');
    onloadCSS(stylesheet, function() {
        setCookie('css-loaded', '0d82f', 100);
    });
}());
</script>

<style>/* Critical CSS here */</style>

<!-- #else -->
<link rel="stylesheet" href="0d82f.css">
<!-- #endif -->

123456789101112131415161718192021

<noscript><link rel="stylesheet"href="0d82f.css"></noscript><script>(function(){functionloadCSS(url){...}functiononloadCSS(stylesheet,callback){...}functionsetCookie(name,value,expInDays){...}varstylesheet=loadCSS('0d82f.css');onloadCSS(stylesheet,function(){setCookie('css-loaded','0d82f',100);});}());</script><style>/* Critical CSS here */</style><link rel="stylesheet"href="0d82f.css">

Apache 服務端邏輯看起來像一行一行的備註，一般以<!-- #開始。我們一步一步來看下吧：

$HTTP_COOKIE!=/css-loaded/ 檢測是否存在CSS快取cookie。 $HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != '0d82f.css' 檢測快取的版本是不是當前所要的版本。

If  如果是true的話，我們就假定這是使用者的第一次瀏覽。

第一次瀏覽我們添加了 <noscript> 標籤，裡面放置了 <link rel="stylesheet">。之所以這樣做，是因為我們要非同步載入整份CSS和JS。如果JS不能用的話，這種做法是不能執行的。這意味著，我們要用常規的載入CSS的方法來做回退。

我們添加了一個行內的指令碼來懶載入CSS，onloadCSS 回撥裡面可以設定cookies.

在同一份腳本里面，我們非同步載入了整份CSS。

在 onloadCSS的回撥裡面，我們用版本號來設定cookie的值。

在這個指令碼後面，我們添加了一行關鍵CSS的樣式。這個會阻塞渲染，但時間是非常短的，而且可以避免頁面展示出來只有純粹的HTML而沒有樣式的情況。

 宣告（意味著 css-loaded 的cookie 已經存在）使用者重複瀏覽。因為我們可以從某種程度上來假定，CSS檔案之前已經被載入過了，我們可以利用瀏覽器快取來提供樣式表。這樣從快取裡面載入速度就很快了。同樣的方法也被用來在第一次非同步載入字型，後續的重複瀏覽也是從快取裡面獲取字型。

這就是我們第一次和重複瀏覽時，我們用來區分的cookies。

檔案級快取

由於我們在重現頁面時很大程度上依賴於瀏覽器快取，所以我們需要確認我們的快取是否合理。理想中我們是要永遠的儲存資源（CSS、js、字型、圖片），只有當這些檔案被修改時才需要更新。當請求的URL是唯一時，快取就會失效。每更新一個版本，我們都會用git tag 打個標籤。所以最簡單的方式就是給我們請求的URL加上一個引數（程式碼版本號），如 https://www.voorhoede.nl/assets/css/main-8af99277a6.css?v=1.0.4.。

但是，這種做法的缺點就是當我們要寫一個新的部落格post（這也是我們程式碼庫的一部分，並沒有永久地儲存在CMS），原來快取的資源將會失效，儘管沒有改變原來那些資源。

就在我們嘗試去改善這種方法時，我們發現了 gulp-rev 和 gulp-rev-replace 。這些指令碼會自動合理地在我們的檔名稱後面新增一竄hash值。這意味著只有實際上檔案被改變時，才會去改變請求的URL，這樣每個檔案的快取就會自動失效。這種做法讓我興奮不已啊！

結果

如果你看到這裡，你應該是想要知道結果的。測試網頁的效能可以採用像 PageSpeed Insights 這樣的工具，它有很實用的提示。也可以使用 WebPagetest來測試，有擴充套件性的網路分析。我認為測試網頁渲染效能的最好方法就是在瘋狂地遏制網路通訊時來觀察網頁的程序。這意味著，用一種不切實際的方法來遏制通訊。在谷歌瀏覽器，你可以這樣操作 (via the inspector > Network tab) 來限制通訊，觀察網頁形成過程中，請求是如何緩慢載入的。

下面是我們的網頁在 50KB/s 的情況下的載入狀況。

這是 de Voorhoede site 首屏的網路分析，是網頁第一次程序的一個概覽。

注意到在50KB/s的網速中，我們是如何讓首屏的渲染只用了 2.27 秒的。也就是第一張幻燈片和瀑布圖裡面的黃色線所代表的位置。黃線恰好繪在就是HTML已經載入完的時間位置。HTML包含了關鍵CSS，保證頁面的可觀性。所有其他的CSS都是用懶載入，所以我們可以等到全部資源載入完時才與頁面進行互動。這也是我們想要的效果！

另一個值得注意的就是自定義字型從來不在這緩慢的連結上載入。 font face 觀察器會自動注意到這一點。但是，如果我們不非同步載入字型，你注視大多數瀏覽器，都會出現FOIT(不可見文字的閃現，上文有提及)的情況。

所有的CSS檔案僅在8s後就都載入完畢。相反，如果我們不採用載入關鍵CSS的方式，而是採用載入全部CSS，我們在前8秒看到的將會是空白的頁面。

如果你感到好奇，想與那些不太注重效能的網站對比一下載入時間，那趕緊試試吧。那個時間肯定是飛漲啊！

用上面介紹的工具測試了我們的網站，結果也是讓人滿意的。 PageSpeed insights 在移動效能方面給了我們100分，多麼了不起啊！

PageSpeed insights 對 voorhoede.nl的測試結果! 速度100分！

當我們檢視 WebPagetest 時，我們得到下面這樣的結果：

WebPagetest 對 voorhoede.nl的檢測結果

可以看出，我們的伺服器執行良好，首屏的速度指標是693。這意味著我們的頁面在693毫秒後就可以在寬屏纜線下被使用了。

技術路線

我們這樣還不算完成，還會不斷地重複我們的方法。我不久的將來，我們會主要關注以下內容：

HTTP/2

目前我們正在試驗HTTP/2。本文所描述的大多數東西都是基於 HTTP/1.1 許可權內的最好實踐。簡言之，HTTP/1.1 要追述到1999年，那時 table佈局和行內樣式都如火如荼。HTTP/1.1 從沒為 2.6MB的網頁要接受200個請求而設計。為了減輕舊版協議帶來的痛楚，我們結合JS、CSS、關鍵性CSS，還為小圖片設定資料來源URI等。用各種方法來節省請求。自從 HTTP/2 可以在同一個TCP連結上平行地執行多個請求後，所有的這些聯結使用和減少請求的做法都可能成為反面模式了。當我們跑完這個實驗後，我們將會採用 HTTP/2 協議。

Service Workers

這是一個在後臺執行的現代瀏覽器的 JavaScript API。它擁有很多特性，這些特性在以前的網站上都是沒有的，如離線支援、訊息推送、背景同步等。我們現在正嘗試用 Service Worker, 但還是得在我們自己的網站上實現先。我向你保證，我們會做到的！

CDN

因此，我們想要自己控制和部署我們的網站。而且現在我們也要採用CDN來擺脫由服務端和客戶端實際距離所帶來的網路問題。儘管我們的使用者基本上都是荷蘭的，我們也想向世界的前端社群反映我們在質量、效能和推動網路發展方面做的最好。

如何運用最新的技術提升網頁速度和效能

效能設計

內容優先

可控性

靜態站點生成器

圖片傳輸

WebP格式

生成

生成圖片

最小化圖片

在markdown檔案中寫[圖片描述](image.jpg).

SVG動畫

自定義網頁字型

字型子集設定

字型監聽器

JS和CSS懶載入

JS懶載入

懶載入CSS

關鍵CSS

服務端

配置

HTTPS

cookies的使用

檔案級快取

結果

技術路線

HTTP/2

Service Workers

CDN

相關推薦

在markdown檔案中寫`[圖片描述](image.jpg)`.