Skip to main content

ZSL

20251229 嘗試 Astro

Published:
Updated:

上一篇文章 抱怨了那麼多卻還是繼續用,而且自己不推薦人家用 Hugo,在文章裡面建議 Astro 結果自己沒用過那不是很賤嗎?好吧說試就試。

測試 Astro

這份表格是我在 hugo-theme-deca 裡面做的測試,使用 11ty 作者的 benchmark 檔案 測試 4000 份文件 build 速度:

DefaultsidebarCachedRendervs Deca cached
Deca187.7s24.3s
Docusaurus 3.9.2**539.6s22× slower
Hugo Doc theme AError
Hugo Doc theme B382.4s15.7× slower
Hugo Doc theme C***121.8s5× slower
  • *: Tested on M1 MacBook Pro 8G RAM at 2025/11/10.
  • **: With Docusaurus Faster experimental_faster: true.
  • ***: This theme doesn't have mobile sidebar. Without mobile sidebar, Deca takes 106s to build the site.

可以看到我寫的 Deca 碾壓一眾 Hugo 主題,這裡是個人部落格這邊也就不用幫他們遮名字了,ABC 主題分別是 Docsy/Hextra/Doks,最可笑的是 Docsy 連 build 都噴 error 跟你說「sidebar 過多限制數量」,這 TM 是什麼天才設定,到底誰會需要限制 sidebar 數量?天底下誰有這種需求?建立一個沒有直接連結可以訪問的頁面???而且照提示設定還是照樣噴 error message,老大哥這才 4000 個檔案而已欸。

說完別人之後要來說 Astro 了,使用官方主題 Starlight 啥也沒設定,以同樣的 4000 份文件測試,首次冷執行 320 秒,第二次冷執行 280 秒...快到我有點傻眼,這已經爆打市面上所有 Hugo 文檔主題,在 Hugo 中你必須和 Deca 一樣特別優化才能得到比 Astro 更快的速度,就像 Deca 一樣。

這還只是在可憐的 M1 MBP 上面跑的,現在都 M5 了,你用桌機速度還能更快。

這樣就好笑了,Hugo 既難整合構建和前端生態,速度除非特別優化否則沒有和 Astro 拉開量級,還有內部各種奇怪限制再加上那個大便文檔,那是真沒啥優勢了。

這還沒完,你以為這就結束了嗎?Astro Starlight 主題開箱即用零設定的 PageFind 搜尋功能還沒關,關掉之後構建速度剩下 144 秒...我在此宣布 Hugo 可以跟大家說再見了。

那麼現在評價又要改了,對於一般用戶,只有完全不進行任何主題修改的人我才推薦 Hugo,override 功能還是很實用的,但是如果你會稍微進階一點的修改,都要學了為什麼不學 JS 生態、文檔更清晰、社群更龐大、維護者更多、有公司專門維護、速度也不慢的 Astro,非要用 Hugo 找罪受呢?企業用戶就更慘了,從不推薦變成更不推薦。

稍微講講速度問題

文檔主題慢的原因是 sidebar,因為每個頁面都要 walk 別的頁面就變成 O(N^2) 複雜度,Deca 從兩個層面解決這個問題:

  1. 預先建立好頁面關係,之後所有構建只需要字典取值
  2. 提供選項快取 sidebar,複雜度從 O(N^2) 下降到 O(1)

透過這兩個優化才能從 382 秒(hextra 的數值,沒有這優化的話 deca 整體框架和他差不多)變成 187 秒,快取 sidebar 再壓縮成 24 秒。

你說不!那是你網站寫太爛了還能再更快,靠邀我都寫到比 Hugo 三大文檔主題還快了,你還想怎樣?照 Hugo 這種文檔就算有額外加速功能誰翻的出來?光是快取功能我就搞半天,原本用 partialCached 快取發現他有 racing condition,雖然純寫入沒有差但是浪費效能,然後翻遍整個官網終於找到在所有頁面處理之前預先處理的方式,要到 configure output formats 裡面,欸嘿恭喜,整個文檔還是沒有任何一個地方明確告訴你構建順序,就是在 outputs formats 裡面有一個 16px 字體大小的 config key 叫做 weights,他媽的誰能找到?後來遷移到 output formats 方案之後,發現他 live reloading 有時候又會抽風,不知道哪裡出問題 .Store 沒有值導致我整個 sidebar 無法渲染,搞老半天還是回去用 partialCached。我就說照這文檔就算好功能別人都不知道。

回到 Starlight,我就好奇了,他這麼快是不是偷偷快取 sidebar?查看 dist 檔案後證實沒有,每個頁面的 sidebar 對於自己的連結都有 aria-current="page",你完大蛋啦 Hugo,Astro 只比你慢 50%,就我前面說的那些缺點,Hugo 至少要比別的框架快 1.5 個數量級才夠彌補,沒錯是 1.5,一個還不夠。

不過 Hugo 通常一個頁面的構建速度是 6ms,而 Starlight 是 37 ms,怎麼慢六倍的最後反超 30%?我不知道,不要問我1

資訊

當然,如果你需要建立一個五萬頁一百萬頁五百萬頁甚至上億頁面的網站時,Hugo 還是你的首選。


  1. Hugo maintainer 說過 RSS/taxonomy 是元兇之一,但是就算我設定了

    1. disableKinds 關閉這些輸出
    2. 不再構建分頁

    現在這 Deca 和 Starlight 的頁面結構一致了,但這也只讓 Deca 的構建時間從 182 下降到 160,仍然輸給 Starlight。更不要說這種做法是一種反模式,我很討厭這種和框架預設行為不一樣的方式,這很讓混淆用戶。 ↩︎