誰再和我說效能不重要我就扁人。
比如說我收到這個回覆：So even though building with this PR takes ~235% of the time, it is still only 17.25s per build of exampleSite in absolute terms.，這到底？？？？你知道要提升 20% 效能是多困難的事情嗎，然後一個小改動慢兩倍跟我說沒差，頭殼壞掉。
在主題維護者對 Hugo 的心得雜談裡面有提到 Hugo 速度非常快，有能力建立大型網站，以 Building a site with 50,000 pages taking a very long time 為例，構建 50000 個頁面的網站，即使他亂寫每個頁面都遍歷其他頁面 （25億次的開銷） 也僅僅耗時四小時，光是移除那個循環改用正確函式完成功能就降低到 3 分鐘，最後加上一些快取技巧成功縮減到兩分鐘，還不要說這是 2023 的文章，後來 Hugo 更新也有效能優化，還能更快。
然而我們看看其他工具的效能，比如說 LLVM 曾經嘗試使用 Docusaurus 構建 20000 個頁面的文檔
- 首次嘗試 OOM
- 套用最佳化配置後仍在 71% 階段崩潰，總耗時近 5 小時
- 發現問題根源是檔案複雜度而非數量 - 最大檔案達 29MB
- 排除最大檔案後可建構，但頁面達 4MB
- Maintainer 結論：Docusaurus 不適合大型網站 So, I think Docusaurus is definitively not good enough to support that kind of scale. Even if we did, having documents that long would not be great for performance.
- 最終改用 Markdown 格式，Mac 上成功建構但耗時 4+ 小時，GitHub runners 仍失敗
- 小型測試（1000 檔案）仍需 20GB 記憶體，顯示即使中等規模也有明顯限制
那麼 vitepress/vuepress 呢？搜不到有人用他們建過大網站。
那麼 mkdocs 呢？不用測試了，光是 50 頁內的超小網站就能明顯感受到慢，沒必要浪費時間測試。
那麼 hexo 呢？這裡看 hexo 維護者自己寫的文章比較有用 Hexo 5/6/7 生成文章性能对比，四千篇文章 160 秒完成，不過小問題是測試 repo 的文章都很短且沒有圖片，不能完全反應現實。
那麼 Next.js/eleventy/xxx/yyy 呢？我沒有要寫論文啦，懶的查了。
你說五萬十萬個頁面不夠看？那麼請看百萬級別的 V&A Explore The Collections, over 1 million pages generated by Hugo，Hugo 仍然有能力完成。