我怎樣將網站的加載時間減少 67%？

本文最初發佈於 Hacker Noon 博客，經原作者授權由 InfoQ 中文站翻譯並分享。

在大多數情況下， JeremyMorgan.com 網站的首頁在世界各地的加載時間都不到一秒。

這個網站的速度之前就很快， 3 秒鐘就可以加載完成，但現在更快了。我將在本文中披露我是怎麼設置的。

我選擇使用 Hugo 構建這個網站，並託管在 Netlify 上。

之前的網站設置

大約在 2011 年的某個時候，我決定從 WordPress 轉移到靜態站點生成器。理由很簡單：我寫好一篇文章，發表它，之後不會修改太多。這當然不足以證明從數據庫提供服務更合理。因此，有一個系統可以為每篇文章生成一個 HTML 頁面並以靜態的方式提供出來就夠了。

我決定選用 Octopress ，它在當時是一個非常受歡迎的 Jekyll 包裝器，也很好地滿足了我的需求。

僅這一步就大大減少了加載時間。然後，我變得有點沉迷於頁面加載速度，做了很多事情來讓它加載得更快，包括：

• 圖像優化（我用過的一些工具）
• 簡化 CSS 和 JavaScript
• 對某些資產使用 CDN

我對這種設置當然很滿意。多年來，我的工作流程就是新建一篇文章，在筆記本電腦或臺式機上生成它，然後將文件 SCP 到運行 Nginx 的 FreeBSD 服務器上。這種方式持續了很長一段時間。回顧過去，那是一個糟糕的工作流程，但我兩個月才寫一篇文章，所以這樣也沒什麼問題。

我花了很多年來定製我的 Octopress 安裝，併為項目貢獻代碼和補丁。

問題成堆

雖然一開始我很喜歡 Octopress，也很欣賞 Brandon Mathis 等人的工作，但 Octopress 開始變得讓人非常痛苦。

對我來說，最大的問題不是 Octopress 本身，而是 Ruby 依賴。這裡就不介紹太多細節了，但它變得非常難以管理。Octopress 需要比較老的 gems 來完成操作，因此，隨著 Ruby 以及某些 gems 的發展，維護一個可構建的 Octopress 安裝變得很有挑戰性。

我無法再從我的筆記本電腦進行構建，因為我需要維護所有舊軟件。我用舊軟件搭建了一個 Linux 服務器，並用它來完成構建。然後，把這些東西轉移到一個容器中，這樣就可以維護 Ruby 以及那些 gems 的舊版本用來生成輸出。例如，運行的 Ruby 版本不能高於 1.9.3 。

所以，我幾年前就開始研究解決方案，但一直沒有時間去切換。幾年來，我的工作流程是這樣的：

還不錯，但這個過程有個致命缺點，就是 Octopress 構建，我知道這一點。為一個簡單的構建步驟維護所有這些舊軟件很容易，但前提是我不碰任何東西。

上個月，我用於構建 Octopress 鏡像的服務器壞了。所以我啟用了另一臺服務器，安裝了 Docker 和容器，但它無法工作。我試了我能想到的所有方法，事實很清楚：

我可以花數小時用這些古老的軟件構建出另一個容器來讓 Octopress 運行起來，或者我能把時間花在更換到另一個 CMS 上。

因此，我開始認真評估另一個靜態站點生成器的選項。

為什麼選擇 Hugo

我花了很多時間來評估不同選項，歸結起來就是以下幾個：

• Hugo （Go）
• Gatsby （JavaScript）
• Pelican （Python）

這些都是靜態站點生成器，它們都可以很好地解決我的問題。我瞭解 Go、JavaScript 和 Python，所以我可以修改一些東西。這只是一個普通的博客，它只是一個目錄結構下的一組文件。這些方法都是可行的。但是，我的要求是什麼呢？

• 靜態文件生成器
• 必須可以快速構建
• 必須容易定製化
• 必須可移植（Mac、OSX、Linux）

最後一點可能看起來有點傻，但我永遠不知道我將在什麼平臺上寫作。我可能使用 Mac、Windows 或 Linux，這取決於所寫的內容。我希望先在本地構建並查看頁面，然後再推到開發環境，最後推到生產環境。這對我來說很重要。不過，經過大量評估後，我發現：

所有這些靜態文件生成器都滿足這些需求。

因此，這讓選擇變得困難起來。我有一個 JeremyMorgan.com 版本，在所有的平臺上使用這三個生成器運行都沒有問題。我可以自定義一些東西，它們都能快速地構建好頁面。但我必須選擇一個。

我最終選擇了 Hugo ，因為我害怕陷入另一個依賴地獄。Gatsby 很酷，也很強大，但對我所做的事情來說似乎太複雜。它在 JavaScript 生態系統中也有大量的依賴，眾所周知，JavaScript 生態系統有時會突發奇想做出破壞性的更改。

Pelican 依賴於 Python 生態系統，而 Python 生態系統不那麼古怪，所以 Pelican 排第二位。而 Hugo 是從可執行文件構建的。因此，即使它被放棄或依賴關係被破壞，我也總是可以使用可執行文件來生成網站，直到我找到一個替代方案。

這就是我選擇 Hugo 的原因。它有一個簡單的保護層，可以讓你免受依賴關係被破壞的影響。並不是每個人都關心破壞性更改和向後兼容性。項目被放棄，這是使用開源軟件的一部分代價。Hugo 簡單、可移植，而且是用 Golang 編寫的，所以如果它被拋棄，我可以 fork 或修改它。

為什麼選擇 Netlify

下一個問題是在哪裡託管它。當服務器崩潰時，我決定把靜態文件轉移到一個Amazon Lightsail設置中。這個過程超級簡單，而且非常快，我知道，另找一個託管服務器不會更好。

幾乎沒有理由在 2020 年建立一個完整的 Linux 服務器來託管一個靜態網站。

我對於託管設置的要求如下：

• 必須快
• 必須安全
• 必須能輕鬆部署

因此，我考慮了以下選項：

• 安裝了 Nginx 的另一臺 Linux/FreeBSD 服務器
• Azure Windows VM with IIS
• AWS Amplify 設置
• Netlify

我開始準備服務器並進行測試。我發現，無論如何優化，託管的 Web 服務器都無法跟 AWS 或 Netlify 的速度相比。這部分是由於邊緣服務器。我在以下地點測試速度：

• 波特蘭，俄勒岡州
• 杜勒斯，弗吉尼亞州
• 奧蘭多，佛羅里達州
• 達拉斯，德克薩斯州
• 舊金山，加利福尼亞
• 聖保羅，巴西
• 倫敦，英國
• 玫瑰山，毛里求斯

我在世界各地做了抽樣測試，但這些是我最關注的城市。我想看看，所有這些地方中哪裡最快。我選擇了一個有很多文字和圖片的頁面。結果讓我大吃一驚。

託管的 FreeBSD 服務器和 IIS 服務器速度很快，但在我離開美國後，與 Netlify 和 AWS 就不在一個級別了。我希望所有的網站訪問者都能快速瀏覽，而不僅僅是我身邊的人。這是我重點考慮的一個因素。

比速度，Netlify 幾乎在每個地區都是贏家。

經過一天中不同時段的長時間測試，Netlify 勝出，AWS Amplify 與之相近。如果我在 AWS 的優質資產上花上一大筆錢，我相信也能取得好成績，但我這個網站不賺錢，所以那不是我的選擇。

看看我的要求，Netlify 全部滿足：

• 速度快（它最快）；
• 安全（據我所知它是安全的）；
• 工作流異常簡單。

我將我的 Github 庫連接到 Netlify。我可以提交到任何分支來存儲更改。我能提交到一個開發分支，我可以把它推送到預覽。當我把它推送到主幹時，它會自動發佈到 JeremyMorgan.com。

為什麼加載速度如此之快？

以下是我的網站加載速度如此之快的原因：

• 它是一個靜態網站；
• 只有 HTML、JavaScript 和 CSS；
• 它比以前輕量化；
• 使用了最少的 CSS 和元素；
• 經過優化的 JPEG 圖片；
• 發佈之前會壓縮；
• Netlify 真得很快，在哪都很快。

綜合上面這些因素，我的網站主頁加載時間不到一秒，而帶有大量圖片和文本的頁面大約在三秒內加載完畢。超級快。

從用途方面說，網站快速加速非常重要。因為這個網站會提供關於開發的教程和信息，我不希望人們等半天才能看到。我希望，即使在互聯網接入較差的國家，這個網站也能正常使用。無疑，Hugo 和 Netlify 幫我實現了這個目標。

關注我並轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！