本文最初發(fā)布于 Hacker Noon 博客，經(jīng)原作者授權(quán)由 InfoQ 中文站翻譯并分享。
在大多數(shù)情況下， JeremyMorgan.com 網(wǎng)站的首頁(yè)在世界各地的加載時(shí)間都不到一秒。
這個(gè)網(wǎng)站的速度之前就很快， 3 秒鐘就可以加載完成，但現(xiàn)在更快了。我將在本文中披露我是怎么設(shè)置的。
我選擇使用 Hugo 構(gòu)建這個(gè)網(wǎng)站，并托管在 Netlify 上。
之前的網(wǎng)站設(shè)置
大約在 2011 年的某個(gè)時(shí)候，我決定從 wordPress/ target=_blank class=infotextkey>WordPress 轉(zhuǎn)移到靜態(tài)站點(diǎn)生成器。理由很簡(jiǎn)單：我寫(xiě)好一篇文章，發(fā)表它，之后不會(huì)修改太多。這當(dāng)然不足以證明從數(shù)據(jù)庫(kù)提供服務(wù)更合理。因此，有一個(gè)系統(tǒng)可以為每篇文章生成一個(gè) html 頁(yè)面并以靜態(tài)的方式提供出來(lái)就夠了。
我決定選用 Octopress ，它在當(dāng)時(shí)是一個(gè)非常受歡迎的 Jekyll 包裝器，也很好地滿(mǎn)足了我的需求。
僅這一步就大大減少了加載時(shí)間。然后，我變得有點(diǎn)沉迷于頁(yè)面加載速度，做了很多事情來(lái)讓它加載得更快，包括：
- 圖像優(yōu)化（我用過(guò)的一些工具）
- 簡(jiǎn)化 css 和 JAVAScript
- 對(duì)某些資產(chǎn)使用 CDN
我對(duì)這種設(shè)置當(dāng)然很滿(mǎn)意。多年來(lái)，我的工作流程就是新建一篇文章，在筆記本電腦或臺(tái)式機(jī)上生成它，然后將文件 SCP 到運(yùn)行 Nginx 的 FreeBSD 服務(wù)器上。這種方式持續(xù)了很長(zhǎng)一段時(shí)間。回顧過(guò)去，那是一個(gè)糟糕的工作流程，但我兩個(gè)月才寫(xiě)一篇文章，所以這樣也沒(méi)什么問(wèn)題。
我花了很多年來(lái)定制我的 Octopress 安裝，并為項(xiàng)目貢獻(xiàn)代碼和補(bǔ)丁。
問(wèn)題成堆
雖然一開(kāi)始我很喜歡 Octopress，也很欣賞 Brandon Mathis 等人的工作，但 Octopress 開(kāi)始變得讓人非常痛苦。
對(duì)我來(lái)說(shuō)，最大的問(wèn)題不是 Octopress 本身，而是 Ruby 依賴(lài)。這里就不介紹太多細(xì)節(jié)了，但它變得非常難以管理。Octopress 需要比較老的 gems 來(lái)完成操作，因此，隨著 Ruby 以及某些 gems 的發(fā)展，維護(hù)一個(gè)可構(gòu)建的 Octopress 安裝變得很有挑戰(zhàn)性。
我無(wú)法再?gòu)奈业墓P記本電腦進(jìn)行構(gòu)建，因?yàn)槲倚枰S護(hù)所有舊軟件。我用舊軟件搭建了一個(gè) linux 服務(wù)器，并用它來(lái)完成構(gòu)建。然后，把這些東西轉(zhuǎn)移到一個(gè)容器中，這樣就可以維護(hù) Ruby 以及那些 gems 的舊版本用來(lái)生成輸出。例如，運(yùn)行的 Ruby 版本不能高于 1.9.3 。
所以，我?guī)啄昵熬烷_(kāi)始研究解決方案，但一直沒(méi)有時(shí)間去切換。幾年來(lái)，我的工作流程是這樣的：
還不錯(cuò)，但這個(gè)過(guò)程有個(gè)致命缺點(diǎn)，就是 Octopress 構(gòu)建，我知道這一點(diǎn)。為一個(gè)簡(jiǎn)單的構(gòu)建步驟維護(hù)所有這些舊軟件很容易，但前提是我不碰任何東西。
上個(gè)月，我用于構(gòu)建 Octopress 鏡像的服務(wù)器壞了。所以我啟用了另一臺(tái)服務(wù)器，安裝了 Docker 和容器，但它無(wú)法工作。我試了我能想到的所有方法，事實(shí)很清楚：
我可以花數(shù)小時(shí)用這些古老的軟件構(gòu)建出另一個(gè)容器來(lái)讓 Octopress 運(yùn)行起來(lái)，或者我能把時(shí)間花在更換到另一個(gè) CMS 上。
因此，我開(kāi)始認(rèn)真評(píng)估另一個(gè)靜態(tài)站點(diǎn)生成器的選項(xiàng)。
為什么選擇 Hugo
我花了很多時(shí)間來(lái)評(píng)估不同選項(xiàng)，歸結(jié)起來(lái)就是以下幾個(gè)：
- Hugo （Go）
- Gatsby （JavaScript）
- Pelican （Python）
這些都是靜態(tài)站點(diǎn)生成器，它們都可以很好地解決我的問(wèn)題。我了解 Go、JavaScript 和 Python，所以我可以修改一些東西。這只是一個(gè)普通的博客，它只是一個(gè)目錄結(jié)構(gòu)下的一組文件。這些方法都是可行的。但是，我的要求是什么呢？
- 靜態(tài)文件生成器
- 必須可以快速構(gòu)建
- 必須容易定制化
- 必須可移植（mac、OSX、Linux）
最后一點(diǎn)可能看起來(lái)有點(diǎn)傻，但我永遠(yuǎn)不知道我將在什么平臺(tái)上寫(xiě)作。我可能使用 Mac、windows 或 Linux，這取決于所寫(xiě)的內(nèi)容。我希望先在本地構(gòu)建并查看頁(yè)面，然后再推到開(kāi)發(fā)環(huán)境，最后推到生產(chǎn)環(huán)境。這對(duì)我來(lái)說(shuō)很重要。不過(guò)，經(jīng)過(guò)大量評(píng)估后，我發(fā)現(xiàn)：
所有這些靜態(tài)文件生成器都滿(mǎn)足這些需求。
因此，這讓選擇變得困難起來(lái)。我有一個(gè) JeremyMorgan.com 版本，在所有的平臺(tái)上使用這三個(gè)生成器運(yùn)行都沒(méi)有問(wèn)題。我可以自定義一些東西，它們都能快速地構(gòu)建好頁(yè)面。但我必須選擇一個(gè)。
我最終選擇了 Hugo ，因?yàn)槲液ε孪萑肓硪粋€(gè)依賴(lài)地獄。Gatsby 很酷，也很強(qiáng)大，但對(duì)我所做的事情來(lái)說(shuō)似乎太復(fù)雜。它在 JavaScript 生態(tài)系統(tǒng)中也有大量的依賴(lài)，眾所周知，JavaScript 生態(tài)系統(tǒng)有時(shí)會(huì)突發(fā)奇想做出破壞性的更改。
Pelican 依賴(lài)于 Python 生態(tài)系統(tǒng)，而 Python 生態(tài)系統(tǒng)不那么古怪，所以 Pelican 排第二位。而 Hugo 是從可執(zhí)行文件構(gòu)建的。因此，即使它被放棄或依賴(lài)關(guān)系被破壞，我也總是可以使用可執(zhí)行文件來(lái)生成網(wǎng)站，直到我找到一個(gè)替代方案。
這就是我選擇 Hugo 的原因。它有一個(gè)簡(jiǎn)單的保護(hù)層，可以讓你免受依賴(lài)關(guān)系被破壞的影響。并不是每個(gè)人都關(guān)心破壞性更改和向后兼容性。項(xiàng)目被放棄，這是使用開(kāi)源軟件的一部分代價(jià)。Hugo 簡(jiǎn)單、可移植，而且是用 Golang 編寫(xiě)的，所以如果它被拋棄，我可以 fork 或修改它。
為什么選擇 Netlify
下一個(gè)問(wèn)題是在哪里托管它。當(dāng)服務(wù)器崩潰時(shí)，我決定把靜態(tài)文件轉(zhuǎn)移到一個(gè)Amazon Lightsail設(shè)置中。這個(gè)過(guò)程超級(jí)簡(jiǎn)單，而且非常快，我知道，另找一個(gè)托管服務(wù)器不會(huì)更好。
幾乎沒(méi)有理由在 2020 年建立一個(gè)完整的 Linux 服務(wù)器來(lái)托管一個(gè)靜態(tài)網(wǎng)站。
我對(duì)于托管設(shè)置的要求如下：
- 必須快
- 必須安全
- 必須能輕松部署
因此，我考慮了以下選項(xiàng)：
- 安裝了 Nginx 的另一臺(tái) Linux/FreeBSD 服務(wù)器
- Azure Windows VM with IIS
- AWS Amplify 設(shè)置
- Netlify
我開(kāi)始準(zhǔn)備服務(wù)器并進(jìn)行測(cè)試。我發(fā)現(xiàn)，無(wú)論如何優(yōu)化，托管的 Web 服務(wù)器都無(wú)法跟 AWS 或 Netlify 的速度相比。這部分是由于邊緣服務(wù)器。我在以下地點(diǎn)測(cè)試速度：
- 波特蘭，俄勒岡州
- 杜勒斯，弗吉尼亞州
- 奧蘭多，佛羅里達(dá)州
- 達(dá)拉斯，德克薩斯州
- 舊金山，加利福尼亞
- 圣保羅，巴西
- 倫敦，英國(guó)
- 玫瑰山，毛里求斯
我在世界各地做了抽樣測(cè)試，但這些是我最關(guān)注的城市。我想看看，所有這些地方中哪里最快。我選擇了一個(gè)有很多文字和圖片的頁(yè)面。結(jié)果讓我大吃一驚。
托管的 FreeBSD 服務(wù)器和 IIS 服務(wù)器速度很快，但在我離開(kāi)美國(guó)后，與 Netlify 和 AWS 就不在一個(gè)級(jí)別了。我希望所有的網(wǎng)站訪(fǎng)問(wèn)者都能快速瀏覽，而不僅僅是我身邊的人。這是我重點(diǎn)考慮的一個(gè)因素。
比速度，Netlify 幾乎在每個(gè)地區(qū)都是贏家。
經(jīng)過(guò)一天中不同時(shí)段的長(zhǎng)時(shí)間測(cè)試，Netlify 勝出，AWS Amplify 與之相近。如果我在 AWS 的優(yōu)質(zhì)資產(chǎn)上花上一大筆錢(qián)，我相信也能取得好成績(jī)，但我這個(gè)網(wǎng)站不賺錢(qián)，所以那不是我的選擇。
看看我的要求，Netlify 全部滿(mǎn)足：
- 速度快（它最快）；
- 安全（據(jù)我所知它是安全的）；
- 工作流異常簡(jiǎn)單。
我將我的 Github 庫(kù)連接到 Netlify。我可以提交到任何分支來(lái)存儲(chǔ)更改。我能提交到一個(gè)開(kāi)發(fā)分支，我可以把它推送到預(yù)覽。當(dāng)我把它推送到主干時(shí)，它會(huì)自動(dòng)發(fā)布到 JeremyMorgan.com。
為什么加載速度如此之快？
以下是我的網(wǎng)站加載速度如此之快的原因：
- 它是一個(gè)靜態(tài)網(wǎng)站；
- 只有 HTML、JavaScript 和 CSS；
- 它比以前輕量化；
- 使用了最少的 CSS 和元素；
- 經(jīng)過(guò)優(yōu)化的 JPEG 圖片；
- 發(fā)布之前會(huì)壓縮；
- Netlify 真得很快，在哪都很快。
綜合上面這些因素，我的網(wǎng)站主頁(yè)加載時(shí)間不到一秒，而帶有大量圖片和文本的頁(yè)面大約在三秒內(nèi)加載完畢。超級(jí)快。
從用途方面說(shuō)，網(wǎng)站快速加速非常重要。因?yàn)檫@個(gè)網(wǎng)站會(huì)提供關(guān)于開(kāi)發(fā)的教程和信息，我不希望人們等半天才能看到。我希望，即使在互聯(lián)網(wǎng)接入較差的國(guó)家，這個(gè)網(wǎng)站也能正常使用。無(wú)疑，Hugo 和 Netlify 幫我實(shí)現(xiàn)了這個(gè)目標(biāo)。
