作者：Declan
譯者：旭日云中竹
鏈接：http://www.zcfy.cc/article/1030
原文：https://www.voorhoede.nl/en/blog/why-our-website-is-faster-than-yours/

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

性能設(shè)計

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

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

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

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

可控性

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

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

我們用 Node.js 實現(xiàn)了靜態(tài)站點生成器纤控。它是采用帶有簡短 JSON 頁面描述標簽的 Markdown 文件來生成整個網(wǎng)站結(jié)構(gòu)和它所有的資源挂捻。為了包括特殊的頁面腳本，也可以附帶一個 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格式的圖片實質(zhì)上比其它格式的小芥驳，有時可以比同樣的 JPEG 圖片小 25%。 WebP被大多數(shù)人所忽略茬高，也沒被經(jīng)常使用兆旬。截止到寫這篇文章的時候，WebP 僅支持Chrome, Opera 和 Android (仍超過了我們50%的用戶)雅采，但我們可以優(yōu)雅降級為 JPG/PNG爵憎。

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

<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">
  [站外圖片上傳中……(7)]
</picture>

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

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

生成

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

生成圖片

在構(gòu)建過程中邑雅，原圖片的多個實例片橡，包括JPG, PNG和WebP格式，我們使用 gulp responsive 來生成淮野。

最小化圖片

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

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

SVG動畫

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

• 首先经瓷，SVG的圖片比位圖更小洞难；

• 其二舆吮，SVG圖片本身就是響應(yīng)式的，有很棒的伸縮性, 所以不需要圖片生成及 <picture> 元素队贱；

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

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

在深入之前，這里有一個關(guān)于在瀏覽器設(shè)置自定義字體的簡短介紹蜗巧。當瀏覽器發(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)頁看起來也完好争涌，也能百分百的正常運行粉楚。勾選/不勾選復(fù)選框來切換我們的網(wǎng)頁字體，來自己體驗一下：

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

字型子集設(shè)定

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

字體監(jiān)聽器

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

html {
   font-family: Georgia, serif;
}

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

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

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

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

JS和CSS懶加載

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

JS懶加載

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

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

另一種可以把腳本放在 head 執(zhí)行的方案是在 <script> 標簽里面添加 defer 屬性闹击，來延遲腳本的執(zhí)行。由于瀏覽器下載腳本是很快的成艘，不會堵塞頁面渲染進程赏半，等到頁面完全加載完贺归，才會執(zhí)行腳本里面的代碼。還有一件事断箫，我們沒有使用像jQuery這些庫拂酣，所以我們的腳本取決于 vanilla 腳本的特性。我們只是想要在瀏覽器加載腳本來支持這些特性仲义。最終的結(jié)果就像下面的代碼這樣：

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

我們把這小段腳本放在頁面頭部婶熬，來檢測瀏覽器是否支持原生JavaScript的 document.querySelector 和 window.addEventListener 屬性。如果支持埃撵，我們通過 <script> 標簽直接給頁面加載腳本赵颅，并使用 defer 屬性讓它不會堵塞頁面渲染。

懶加載CSS

對于首屏來講暂刘，網(wǎng)站最大的渲染堵塞資源就是CSS了饺谬。只有當 <head> 里面的CSS文件完全加載完畢時，瀏覽器才會開始渲染頁面谣拣。這種做法是經(jīng)過深思熟慮的募寨，若不是這樣，瀏覽器就需要在整個渲染過程中不斷重新計算布局尺寸森缠，不斷重繪拔鹰。

為了防止CSS堵塞渲染，我們就需要異步加載CSS文件贵涵。我們使用了 Filament Group 的 awesome loadCSS 函數(shù)格郁。該函數(shù)提供了一個回調(diào)，當CSS文件加載完后独悴，我們設(shè)置一個cookie來聲明CSS文件已經(jīng)加載了例书。我們使用這個cookie來重現(xiàn)頁面，這一點我后續(xù)會解釋到刻炒。

CSS異步加載也帶來這樣一個問題决采，盡管 HTML 真的很快被渲染出來，但看起來就只有純粹的HTML坟奥，只有等到整個CSS文件加載完且停止時树瞭，才會有樣式。這時就要提到關(guān)鍵CSS了爱谁。

關(guān)鍵CSS

關(guān)鍵CSS就是阻塞瀏覽器渲染出用戶可識別的網(wǎng)頁的一小部分CSS晒喷。我們注意網(wǎng)頁的 上半版版面。很明顯访敌，兩個設(shè)備的版面的位置有很大的區(qū)別凉敲。因此，我們做了一個大膽的猜測。

手動地檢測這部分關(guān)鍵性的CSS是個很耗時的過程爷抓，尤其是樣式势决、特性等不斷改變時。這里有幾個好的腳本蓝撇，可以在你構(gòu)建網(wǎng)頁時果复，生成關(guān)鍵性CSS。我們采用了 Addy Osmani 的版本渤昌。

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

左側(cè)網(wǎng)頁是用關(guān)鍵CSS渲染的独柑，而右側(cè)網(wǎng)頁則是用整份的CSS迈窟。紅線是分界線。

服務(wù)端

我們自己部署 de Voorhoede 網(wǎng)站群嗤，因為我們希望能夠控制服務(wù)器環(huán)境菠隆。我們也想要嘗試，是否可以通過改變服務(wù)端的配置來大大提升性能狂秘。當前我們使用了 Apache 服務(wù)和 HTTPS 協(xié)議骇径。

配置

為了提升性能和安全性，我們研究了如何配置服務(wù)端者春。

我們使用 H5BP apache樣板配置破衔，這個對于改善Apache網(wǎng)絡(luò)服務(wù)的性能和安全性是個很好的開始。他們也有其他服務(wù)器環(huán)境的配置钱烟。對于我們的大部分 HTML晰筛、CSS 和 JS，我們使用GZIP壓縮拴袭。對于我們的所有網(wǎng)站資源读第，都使用緩存HTTP標頭的做法。有興趣請閱讀文件層級緩存的章節(jié)拥刻。

HTTPS

用HTTPS來服務(wù)你的網(wǎng)站會對性能造成影響怜瞒。這主要是設(shè)置了SSL握手，引入了大量潛在的東西般哼。但通常情況下吴汪，我們可以做一些改變！

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

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

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

我聽起來像是一個搞開發(fā)和運維的，但確實不是代咸。我只是讀過一些書蹈丸，看過一些視頻。我喜歡 Google I/O 2016 的 Mythbusting HTTPS：Emily Stark 的安全性都市傳奇呐芥。

cookies的使用

我們沒有用一門服務(wù)端的語言逻杖，只有靜態(tài)的 Apache 網(wǎng)絡(luò)服務(wù)。但一個 Apache 網(wǎng)絡(luò)服務(wù)仍可以做包括SSI在內(nèi)的后端服務(wù)思瘟，并且讀取cookies荸百。通過巧用cookies和運行那部分被Apache改寫的HTML，我們可以大大提升前端性能滨攻。下面這個例子就是了（我們實際的代碼比這個復(fù)雜點够话，但是思想上是一致的）：

<!-- #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 -->

第一次瀏覽我們添加了 <noscript> 標簽，里面放置了 <link rel="stylesheet">光绕。之所以這樣做女嘲，是因為我們要異步加載整份CSS和JS。如果JS不能用的話诞帐，這種做法是不能執(zhí)行的欣尼。這意味著，我們要用常規(guī)的加載CSS的方法來做回退景埃。

我們添加了一個行內(nèi)的腳本來懶加載CSS媒至，onloadCSS 回調(diào)里面可以設(shè)置cookies.

在同一份腳本里面，我們異步加載了整份CSS谷徙。

在 onloadCSS的回調(diào)里面拒啰，我們用版本號來設(shè)置cookie的值。

在這個腳本后面完慧，我們添加了一行關(guān)鍵CSS的樣式谋旦。這個會阻塞渲染，但時間是非常短的，而且可以避免頁面展示出來只有純粹的HTML而沒有樣式的情況册着。

`` 聲明（意味著 css-loaded 的cookie 已經(jīng)存在）用戶重復(fù)瀏覽拴孤。因為我們可以從某種程度上來假定，CSS文件之前已經(jīng)被加載過了甲捏，我們可以利用瀏覽器緩存來提供樣式表演熟。這樣從緩存里面加載速度就很快了。同樣的方法也被用來在第一次異步加載字體司顿，后續(xù)的重復(fù)瀏覽也是從緩存里面獲取字體芒粹。

這就是我們第一次和重復(fù)瀏覽時，我們用來區(qū)分的cookies大溜。

文件級緩存

由于我們在重現(xiàn)頁面時很大程度上依賴于瀏覽器緩存化漆，所以我們需要確認我們的緩存是否合理。理想中我們是要永遠的存儲資源（CSS钦奋、js座云、 字體、圖片）付材，只有當這些文件被修改時才需要更新朦拖。當請求的URL是唯一時，緩存就會失效伞租。每更新一個版本贞谓，我們都會用 git tag 打個標簽。所以最簡單的方式就是給我們請求的URL加上一個參數(shù)（代碼版本號）葵诈，如 https://www.voorhoede.nl/assets/css/main-8af99277a6.css?v=1.0.4.裸弦。

但是，這種做法的缺點就是當我們要寫一個新的博客post（這也是我們代碼庫的一部分作喘，并沒有永久地存儲在CMS）理疙，原來緩存的資源將會失效，盡管沒有改變原來那些資源泞坦。

就在我們嘗試去改善這種方法時窖贤，我們發(fā)現(xiàn)了 gulp-rev 和 gulp-rev-replace 。這些腳本會自動合理地在我們的文件名稱后面添加一竄hash值贰锁。這意味著只有實際上文件被改變時赃梧，才會去改變請求的URL，這樣每個文件的緩存就會自動失效豌熄。這種做法讓我興奮不已笆卩帧！

結(jié)果

如果你看到這里锣险，你應(yīng)該是想要知道結(jié)果的蹄皱。測試網(wǎng)頁的性能可以采用像 PageSpeed Insights 這樣的工具览闰，它有很實用的提示。也可以使用 WebPagetest來測試巷折，有擴展性的網(wǎng)絡(luò)分析压鉴。我認為測試網(wǎng)頁渲染性能的最好方法就是在瘋狂地遏制網(wǎng)絡(luò)通信時來觀察網(wǎng)頁的進程。這意味著锻拘，用一種不切實際的方法來遏制通信油吭。在谷歌瀏覽器，你可以這樣操作 (via the inspector > Network tab) 來限制通信逊拍，觀察網(wǎng)頁形成過程中上鞠，請求是如何緩慢加載的际邻。

下面是我們的網(wǎng)頁在 50KB/s 的情況下的加載狀況芯丧。

這是 de Voorhoede site 首屏的網(wǎng)絡(luò)分析，是網(wǎng)頁第一次進程的一個概覽世曾。

注意到在50KB/s的網(wǎng)速中缨恒，我們是如何讓首屏的渲染只用了 2.27 秒的。也就是第一張幻燈片和瀑布圖里面的黃色線所代表的位置轮听。黃線恰好繪在就是HTML已經(jīng)加載完的時間位置骗露。HTML包含了關(guān)鍵CSS，保證頁面的可觀性血巍。所有其他的CSS都是用懶加載萧锉，所以我們可以等到全部資源加載完時才與頁面進行交互。這也是我們想要的效果述寡！

另一個值得注意的就是自定義字體從來不在這緩慢的鏈接上加載柿隙。 font face 觀察器會自動注意到這一點。但是鲫凶，如果我們不異步加載字體禀崖，你注視大多數(shù)瀏覽器，都會出現(xiàn) FOIT(不可見文本的閃現(xiàn)螟炫，上文有提及)的情況波附。

所有的CSS文件僅在8s后就都加載完畢。相反昼钻，如果我們不采用加載關(guān)鍵CSS的方式掸屡，而是采用加載全部CSS，我們在前8秒看到的將會是空白的頁面然评。

如果你感到好奇仅财，想與那些不太注重性能的網(wǎng)站對比一下加載時間，那趕緊試試吧沾瓦。那個時間肯定是飛漲奥拧谦炒！

用上面介紹的工具測試了我們的網(wǎng)站，結(jié)果也是讓人滿意的风喇。 PageSpeed insights 在移動性能方面給了我們100分宁改，多么了不起啊魂莫！

PageSpeed insights 對 voorhoede.nl的測試結(jié)果! 速度100分还蹲！

當我們查看 WebPagetest 時，我們得到下面這樣的結(jié)果：

可以看出耙考，我們的服務(wù)器運行良好谜喊，首屏的速度指標是693。 這意味著我們的頁面在693毫秒后就可以在寬屏纜線下被使用了倦始。

技術(shù)路線

我們這樣還不算完成斗遏，還會不斷地重復(fù)我們的方法。我不久的將來鞋邑，我們會主要關(guān)注以下內(nèi)容：

HTTP/2

目前我們正在試驗HTTP/2诵次。本文所描述的大多數(shù)東西都是基于 HTTP/1.1 權(quán)限內(nèi)的最好實踐。簡言之枚碗，HTTP/1.1 要追述到1999年逾一，那時 table布局和行內(nèi)樣式都如火如荼。HTTP/1.1 從沒為 2.6MB的網(wǎng)頁要接受200個請求而設(shè)計肮雨。為了減輕舊版協(xié)議帶來的痛楚遵堵，我們結(jié)合JS、CSS怨规、關(guān)鍵性CSS陌宿，還為小圖片設(shè)置數(shù)據(jù)源URI等。用各種方法來節(jié)省請求椅亚。自從 HTTP/2 可以在同一個TCP鏈接上平行地運行多個請求后限番，所有的這些聯(lián)結(jié)使用和減少請求的做法都可能成為反面模式了。當我們跑完這個實驗后呀舔，我們將會采用 HTTP/2 協(xié)議弥虐。

Service Workers

這是一個在后臺運行的現(xiàn)代瀏覽器的 JavaScript API。它擁有很多特性媚赖，這些特性在以前的網(wǎng)站上都是沒有的霜瘪，如離線支持、消息推送惧磺、背景同步等颖对。我們現(xiàn)在正嘗試用 Service Worker, 但還是得在我們自己的網(wǎng)站上實現(xiàn)先。我向你保證磨隘，我們會做到的缤底！

CDN

因此顾患，我們想要自己控制和部署我們的網(wǎng)站。而且現(xiàn)在我們也要采用CDN來擺脫由服務(wù)端和客戶端實際距離所帶來的網(wǎng)絡(luò)問題个唧。盡管我們的用戶基本上都是荷蘭的江解，我們也想向世界的前端社區(qū)反映我們在質(zhì)量、性能和推動網(wǎng)絡(luò)發(fā)展方面做的最好徙歼。