Categories
程式開發

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


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

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

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

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

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

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

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

之前的網站設置

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

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

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

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

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

我花了很多年來定制我的Octopress安裝,並為項目貢獻代碼和補丁。

問題成堆

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

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

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

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

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

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

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

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

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

為什麼選擇Hugo

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

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

這些都是靜態站點生成器,它們都可以很好地解決我的問題。我了解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

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

下一個問題是在哪里托管它。當服務器崩潰時,我決定把靜態文件轉移到一個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幫我實現了這個目標。

英文原文:

How I Got My Website To Load in 1 Second