[譯] 如何運用新技術提升網(wǎng)頁速度和性能

mj 發(fā)布于2019-07-24 10:32 / 803人閱讀

摘要：簡言之，我們認為好的用戶體驗從快速的內(nèi)容傳輸開始，也就意味著性能美觀。每一步我們都在探討如何在獲得好的用戶體驗和保證設計美感的同時，最小化對性能的影響。字型子集設定到目前為止，子集設定是改善網(wǎng)頁字體性能最快的方式。

作者 Declan

原文鏈接

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

性能設計

在我們的項目中，我們每天都會和設計師和產(chǎn)品負責人討論關于平衡美觀和性能的問題。對于我們自己的網(wǎng)站，這樣做是很簡單的。簡言之，我們認為好的用戶體驗從快速的內(nèi)容傳輸開始，也就意味著 性能 > 美觀。

好的內(nèi)容、布局、圖片和交互是吸引用戶的重要因素。這每個因素都會影響頁面的加載時間和終端用戶體驗。每一步我們都在探討如何在獲得好的用戶體驗和保證設計美感的同時，最小化對性能的影響。

內(nèi)容優(yōu)先

我們想要把核心內(nèi)容盡快地呈現(xiàn)給用戶，意味著我們要處理好基本的 HTML 和 CSS。每個頁面都應該達到基本的目的：傳遞信息。JS、CSS、網(wǎng)頁字體、圖片、網(wǎng)站分析等優(yōu)化都是位居于核心內(nèi)容之下的。

可控性

給理想網(wǎng)站定義了標準后，我們總結出：要想達到預期效果，就要能對網(wǎng)站各方面的控制都游刃有余。我們選擇構建自己的靜態(tài)站點生成器，包括資源傳輸，并且由我們自己操控。

靜態(tài)站點生成器

我們用 Node.js 實現(xiàn)了靜態(tài)站點生成器。它是采用帶有簡短 JSON 頁面描述標簽的 Markdown 文件來生成整個網(wǎng)站結構和它所有的資源。為了包括特殊的頁面腳本，也可以附帶一個 HTML 文件。以下是一個簡單化的描述標簽和 markdown 文件，用于博客的發(fā)布，用它來生成真正的 HTML。

JSON 描述標簽:

{
  "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...

圖片傳輸

平均一個 2406kb 的網(wǎng)頁中 1535kb 是圖片。就因為圖片在網(wǎng)站中占據(jù)了這么大的一個比例，所以它也是性能優(yōu)化的重點之一。

WebP格式

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

使用元素我們可以把圖片從 WebP 優(yōu)雅地降級到其它被廣泛支持的圖片格式，如JPEG:

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

我們使用作為那些不支持或者 JS 的瀏覽器的后備元素。使用圖片的最大實例確保了它在后備方案中的可行性。

生成

盡管圖片傳輸方式已經(jīng)確定了，我們?nèi)孕枰伎荚撛鯓佑行У貓?zhí)行。我喜歡元素的功能，但不喜歡寫上面那些代碼段，尤其是寫內(nèi)容時必須把它加進去。我們不想做這么費力的事情：每張圖片都要寫 6 個實例，所以優(yōu)化這些圖片并且把它們寫在markdown文件的里面。所以：

生成圖片

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

最小化圖片 在markdown文件中寫[圖片描述](image.jpg).

在構建過程中使用自定義Markdown渲染器來為已經(jīng)完全成熟的元素編譯傳統(tǒng)的markdown圖片聲明。

SVG動畫

我們?yōu)樽约旱木W(wǎng)站選擇了特定的圖標類型，其中SVG插圖占了主要地位。這樣做有以下幾個原因：

首先，SVG的圖片比位圖更小；

其二，SVG圖片本身就是響應式的，有很棒的伸縮性, 所以不需要圖片生成及元素；

最后也是很重要的一點，就是我們可以通過CSS來不斷改變它，賦予它新的活力！我們所有的組合頁面都有一個自定義的動態(tài)SVG圖, 可以被概述頁面所復用。這張圖片作為我們所有組合頁面的一種循環(huán)風格，使得頁面設計一體化，同時又幾乎不會對性能造成影響。請看這張動畫，看看我們是如何用CSS來改變它的。

自定義網(wǎng)頁字體

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

切換下載的字體類
使用自定義網(wǎng)頁字體可以改善我們的用戶體驗，只要你能夠優(yōu)化他們，并且負責任地為之服務。

字型子集設定

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

字體監(jiān)聽器

Bram Stein 推出的字體監(jiān)聽器是一個很了不起的腳本，可以幫助檢查字體是否已被加載。至于你是如何加載字體的，是通過一個網(wǎng)頁字體服務，還是自己上傳就不可知了。在這個監(jiān)聽器告訴我們所有自定義的字體已經(jīng)下載完畢后，我們就可以在元素上添加一個字體加載完畢的類，我們的頁面就會重新用新的字體：

html {
   font-family: Georgia, serif;
}

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

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

我們可以設定一個cookie來記住所有的字體已經(jīng)被加載過，就可以讓他們緩存在瀏覽器里面了。我們使用這個cookie來做重復的瀏覽，這個我后續(xù)會解釋。

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

JS和CSS懶加載

一般來講，我們都是盡可能快的加載需要的資源。我們移除一些堵塞的請求來加快頁面渲染，優(yōu)化首屏，用瀏覽器緩存來處理重復的頁面。

JS懶加載

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

JS在塊里面渲染，這是我們想要的。JS應該只是用來提高用戶體驗，不應該是訪問者需要的關鍵。處理JS堵塞渲染的簡單方法就是把腳本放在頁面的尾部。這樣網(wǎng)頁就會在整個HTML 渲染完畢后才去加載JS。

另一種可以把腳本放在 head 執(zhí)行的方案是在 "); }

我們把這小段腳本放在頁面頭部，來檢測瀏覽器是否支持原生JavaScript的 document.querySelector 和 window.addEventListener 屬性。如果支持，我們通過

左側網(wǎng)頁是用關鍵CSS渲染的，而右側網(wǎng)頁則是用整份的CSS。紅線是分界線。
服務端
我們自己部署 de Voorhoede 網(wǎng)站，因為我們希望能夠控制服務器環(huán)境。我們也想要嘗試，是否可以通過改變服務端的配置來大大提升性能。當前我們使用了 Apache 服務和 HTTPS 協(xié)議。
配置
為了提升性能和安全性，我們研究了如何配置服務端。

我們使用 H5BP apache樣板配置，這個對于改善Apache網(wǎng)絡服務的性能和安全性是個很好的開始。他們也有其他服務器環(huán)境的配置。對于我們的大部分 HTML、CSS 和 JS，我們使用GZIP壓縮。對于我們的所有網(wǎng)站資源，都使用緩存HTTP標頭的做法。有興趣請閱讀文件層級緩存的章節(jié)。
HTTPS
用HTTPS來服務你的網(wǎng)站會對性能造成影響。這主要是設置了SSL握手，引入了大量潛在的東西。但通常情況下，我們可以做一些改變！

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

TLS false start 允許客戶端在第一個TLS回合結束后，馬上向后端發(fā)送加密的數(shù)據(jù)。這種優(yōu)化為一個新的TLS連接減少了握手次數(shù)。一旦客戶端知道了密鑰，就可以開始傳輸應用數(shù)據(jù)。剩下的握手用來確認是否有人篡改了握手記錄，并且可以并行處理。

TLS session resumption 通過確認瀏覽器和服務器是否已經(jīng)取得聯(lián)系來幫我們節(jié)省一個來回。瀏覽器會記住這一次的標識符，下次發(fā)起連接時，這個標識符就會被重用，節(jié)省了一個來回。

我聽起來像是一個搞開發(fā)和運維的，但確實不是。我只是讀過一些書，看過一些視頻。我喜歡 Google I/O 2016 的 Mythbusting HTTPS：Emily Stark 的安全性都市傳奇。
cookies的使用
我們沒有用一門服務端的語言，只有靜態(tài)的 Apache 網(wǎng)絡服務。但一個 Apache 網(wǎng)絡服務仍可以做包括SSI在內(nèi)的后端服務，并且讀取cookies。通過巧用cookies和運行那部分被Apache改寫的HTML，我們可以大大提升前端性能。下面這個例子就是了（我們實際的代碼比這個復雜點，但是思想上是一致的）：

Apache 服務端邏輯看起來像一行一行的備注，一般以如果是true的話，我們就假定這是用戶的第一次瀏覽。

第一次瀏覽我們添加了

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優(yōu)惠，快來選購！

[譯] 如何運用新技術提升網(wǎng)頁速度和性能