最近更新了我們的網(wǎng)站卸夕，它是經(jīng)過了設(shè)計上的全面驗收的哑了。但實際上积糯，作為軟件開發(fā)者，我們會注重很多技術(shù)相關(guān)的零碎的東西护戳。我們的目標(biāo)是控制性能，注重性能垂睬，未來可伸展媳荒，為網(wǎng)站增添內(nèi)容是一種樂趣。接著就來告訴你驹饺，為什么我們的網(wǎng)站速度比你們的快吧（抱歉钳枕，確實是這樣的）。
性能設(shè)計
在我們的項目中赏壹，我們每天都會和設(shè)計師和產(chǎn)品負(fù)責(zé)人討論關(guān)于平衡美觀和性能的問題鱼炒。對于我們自己的網(wǎng)站，這樣做是很簡單的蝌借。簡言之昔瞧，我們認(rèn)為好的用戶體驗從快速的內(nèi)容傳輸開始，也就意味著 性能 > 美觀菩佑。
好的內(nèi)容自晰、布局、圖片和交互是吸引用戶的重要因素擎鸠。這每個因素都會影響頁面的加載時間和終端用戶體驗缀磕。每一步我們都在探討如何在獲得好的用戶體驗和保證設(shè)計美感的同時，最小化對性能的影響劣光。
內(nèi)容優(yōu)先
我們想要把核心內(nèi)容盡快地呈現(xiàn)給用戶袜蚕，意味著我們要處理好基本的 HTML 和 CSS。每個頁面都應(yīng)該達(dá)到基本的目的：傳遞信息绢涡。JS牲剃、CSS、網(wǎng)頁字體雄可、圖片凿傅、網(wǎng)站分析等優(yōu)化都是位居于核心內(nèi)容之下的缠犀。
可控性
給理想網(wǎng)站定義了標(biāo)準(zhǔn)后，我們總結(jié)出：要想達(dá)到預(yù)期效果聪舒，就要能對網(wǎng)站各方面的控制都游刃有余辨液。我們選擇構(gòu)建自己的靜態(tài)站點生成器，包括資源傳輸箱残，并且由我們自己操控滔迈。
靜態(tài)站點生成器
我們用 Node.js 實現(xiàn)了靜態(tài)站點生成器。它是采用帶有簡短 JSON 頁面描述標(biāo)簽的Markdown 文件來生成整個網(wǎng)站結(jié)構(gòu)和它所有的資源被辑。為了包括特殊的頁面腳本燎悍，也可以附帶一個 HTML 文件。以下是一個簡單化的描述標(biāo)簽和 markdown 文件盼理，用于博客的發(fā)布谈山，用它來生成真正的 HTML。
JSON 描述標(biāo)簽:
{
"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">
[站外圖片上傳中……(6)]
</picture>
我們使用Scott Jehl 的 picturefill 來使那些不支持<picture> 元素的瀏覽器獲得支持，在各個瀏覽器中達(dá)到一致的效果
我們使用 <img>作為那些不支持<picture>或者 JS 的瀏覽器的后備元素约谈。使用圖片的最大實例確保了它在后備方案中的可行性笔宿。
生成
盡管圖片傳輸方式已經(jīng)確定了，我們?nèi)孕枰伎荚撛鯓佑行У貓?zhí)行棱诱。我喜歡 <picture>元素的功能泼橘，但不喜歡寫上面那些代碼段，尤其是寫內(nèi)容時必須把它加進(jìn)去迈勋。我們不想做這么費力的事情：每張圖片都要寫 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)站選擇了特定的圖標(biāo)類型育苟，其中SVG插圖占了主要地位。這樣做有以下幾個原因：
- 首先椎木，SVG的圖片比位圖更小宙搬；
- 其二，SVG圖片本身就是響應(yīng)式的拓哺，有很棒的伸縮性, 所以不需要圖片生成及
<picture>元素；
- 最后也是很重要的一點脖母，就是我們可以通過CSS來不斷改變它士鸥，賦予它新的活力！我們所有的組合頁面都有一個自定義的動態(tài)SVG圖, 可以被概述頁面所復(fù)用谆级。這張圖片作為我們所有組合頁面的一種循環(huán)風(fēng)格烤礁，使得頁面設(shè)計一體化，同時又幾乎不會對性能造成影響肥照。請看這張動畫脚仔，看看我們是如何用CSS來改變它的。
[站外圖片上傳中……(7)]</img>
自定義網(wǎng)頁字體
在深入之前舆绎，這里有一個關(guān)于在瀏覽器設(shè)置自定義字體的簡短介紹鲤脏。當(dā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彻桃。當(dāng)自定義的字體下載完成后，再代替標(biāo)準(zhǔn)字體并且重新渲染晾蜘。這樣邻眷，即使自定義字體下載失敗眠屎，仍然不會影響內(nèi)容的可讀性。然而肆饶，有人會認(rèn)為這是一種妥協(xié)的做法改衩，但我們認(rèn)為自定義字體只是一種優(yōu)化。盡管沒有自定義字體驯镊，網(wǎng)頁看起來也完好葫督，也能百分百的正常運行。勾選/不勾選復(fù)選框來切換我們的網(wǎng)頁字體板惑，來自己體驗一下：
切換下載的字體類 使用自定義網(wǎng)頁字體可以改善我們的用戶體驗橄镜，只要你能夠優(yōu)化他們，并且負(fù)責(zé)任地為之服務(wù)冯乘。
字型子集設(shè)定
到目前為止洽胶，子集設(shè)定是改善網(wǎng)頁字體性能最快的方式。我將會向每個使用自定義字體的網(wǎng)頁開發(fā)者推薦它裆馒。如果你能完全控制網(wǎng)頁內(nèi)容姊氓，并且知道它將要展示哪些特性的話，你可以完全使用子集設(shè)定喷好。但是翔横，即使是僅僅把字體設(shè)為西方語言，也會對文件大小造成很大的影響梗搅。例如禾唁，我們的 Noto Regular WOFF 字體，默認(rèn)是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>標(biāo)簽里面添加defer屬性归榕，來延遲腳本的執(zhí)行锭碳。由于瀏覽器下載腳本是很快的爹土，不會堵塞頁面渲染進(jìn)程赤嚼，等到頁面完全加載完捉超，才會執(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>標(biāo)簽直接給頁面加載腳本，并使用defer屬性讓它不會堵塞頁面渲染俏橘。
懶加載CSS
對于首屏來講允华，網(wǎng)站最大的渲染堵塞資源就是CSS了。只有當(dāng)<head>里面的CSS文件完全加載完畢時，瀏覽器才會開始渲染頁面靴寂。這種做法是經(jīng)過深思熟慮的磷蜀，若不是這樣，瀏覽器就需要在整個渲染過程中不斷重新計算布局尺寸榨汤，不斷重繪蠕搜。
為了防止CSS堵塞渲染，我們就需要異步加載CSS文件收壕。我們使用了 Filament Group的 awesome loadCSS 函數(shù)妓灌。該函數(shù)提供了一個回調(diào)，當(dāng)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ù)端的配置來大大提升性能冕房。當(dāng)前我們使用了 Apache 服務(wù)和 HTTPS 協(xié)議躏啰。
配置
為了提升性能和安全性，我們研究了如何配置服務(wù)端耙册。
我們使用 H5BP apache樣板配置给僵，這個對于改善Apache網(wǎng)絡(luò)服務(wù)的性能和安全性是個很好的開始。他們也有其他服務(wù)器環(huán)境的配置详拙。對于我們的大部分 HTML帝际、CSS 和 JS，我們使用GZIP壓縮饶辙。對于我們的所有網(wǎng)站資源蹲诀，都使用緩存HTTP標(biāo)頭的做法。有興趣請閱讀文件層級緩存的章節(jié)弃揽。
HTTPS
用HTTPS來服務(wù)你的網(wǎng)站會對性能造成影響脯爪。這主要是設(shè)置了SSL握手，引入了大量潛在的東西矿微。但通常情況下痕慢，我們可以做一些改變！
HTTP Strict Transport Security 是一個HTTP標(biāo)頭涌矢，可以讓服務(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ù)泰偿。剩下的握手用來確認(rèn)是否有人篡改了握手記錄，并且可以并行處理蜈垮。
TLS session resumption 通過確認(rèn)瀏覽器和服務(wù)器是否已經(jīng)取得聯(lián)系來幫我們節(jié)省一個來回耗跛。瀏覽器會記住這一次的標(biāo)識符，下次發(fā)起連接時攒发，這個標(biāo)識符就會被重用调塌，節(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>標(biāo)簽，里面放置了 <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)頁面時很大程度上依賴于瀏覽器緩存，所以我們需要確認(rèn)我們的緩存是否合理厘熟。理想中我們是要永遠(yuǎn)的存儲資源（CSS偎血、js诸衔、 字體、圖片）颇玷，只有當(dāng)這些文件被修改時才需要更新笨农。當(dāng)請求的URL是唯一時，緩存就會失效帖渠。每更新一個版本谒亦，我們都會用git tag 打個標(biāo)簽。所以最簡單的方式就是給我們請求的URL加上一個參數(shù)（代碼版本號）空郊，如 https://www.voorhoede.nl/assets/css/main-8af99277a6.css?v=1.0.4.份招。
但是，這種做法的缺點就是當(dāng)我們要寫一個新的博客post（這也是我們代碼庫的一部分狞甚，并沒有永久地存儲在CMS）锁摔，原來緩存的資源將會失效，盡管沒有改變原來那些資源哼审。
就在我們嘗試去改善這種方法時谐腰，我們發(fā)現(xiàn)了 gulp-rev 和 gulp-rev-replace 。這些腳本會自動合理地在我們的文件名稱后面添加一竄hash值涩盾。這意味著只有實際上文件被改變時十气，才會去改變請求的URL，這樣每個文件的緩存就會自動失效春霍。這種做法讓我興奮不已霸椅鳌！
結(jié)果
如果你看到這里址儒，你應(yīng)該是想要知道結(jié)果的芹枷。測試網(wǎng)頁的性能可以采用像 PageSpeed Insights 這樣的工具，它有很實用的提示莲趣。也可以使用 WebPagetest來測試鸳慈，有擴展性的網(wǎng)絡(luò)分析。我認(rèn)為測試網(wǎng)頁渲染性能的最好方法就是在瘋狂地遏制網(wǎng)絡(luò)通信時來觀察網(wǎng)頁的進(jìn)程妖爷。這意味著，用一種不切實際的方法來遏制通信理朋。在谷歌瀏覽器絮识，你可以這樣操作 (via the inspector > Network tab) 來限制通信，觀察網(wǎng)頁形成過程中嗽上，請求是如何緩慢加載的次舌。
下面是我們的網(wǎng)頁在 50KB/s 的情況下的加載狀況。
這是 de Voorhoede site 首屏的網(wǎng)絡(luò)分析兽愤，是網(wǎng)頁第一次進(jìn)程的一個概覽彼念。
注意到在50KB/s的網(wǎng)速中挪圾，我們是如何讓首屏的渲染只用了 2.27 秒的。也就是第一張幻燈片和瀑布圖里面的黃色線所代表的位置逐沙。黃線恰好繪在就是HTML已經(jīng)加載完的時間位置哲思。HTML包含了關(guān)鍵CSS，保證頁面的可觀性吩案。所有其他的CSS都是用懶加載棚赔，所以我們可以等到全部資源加載完時才與頁面進(jìn)行交互。這也是我們想要的效果徘郭！
另一個值得注意的就是自定義字體從來不在這緩慢的鏈接上加載靠益。 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分！
當(dāng)我們查看 WebPagetest 時魂爪，我們得到下面這樣的結(jié)果：
可以看出先舷，我們的服務(wù)器運行良好，首屏的速度指標(biāo)是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é)使用和減少請求的做法都可能成為反面模式了。當(dāng)我們跑完這個實驗后颠悬，我們將會采用 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ā)展方面做的最好斯棒。
