https://yennj12.js.org/yennj12_blog_V4/tags/github-pages/Recent content in GitHub Pages on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/Tue, 30 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/多數人優化靜態站台的做法：壓縮一下圖片、開個快取就收工。 但當站台是由 42 個機器人每天自動寫進去的 5,000 頁報告時，問題不在「檔案大」， 而在「整個 pipeline 的每個環節都在重複放大成本」——搜尋索引、導覽樹、git 歷史、部署觸發頻率。 真正的調校，是找出那些被無限複製的單位成本。 一、問題：一個會自己長大的站台 finance_data 是一個自動化金融分析站台。它的內容不是人手寫的，而是由大約 42 個每日排程任務自動產生：10-K / 10-Q / 13-F 財報摘要、investor day 筆記、AI 生成的個股報告、notebook PDF……每天都有新的 dated report 被寫進 repo，再透過 MkDocs（Material 主題）建置成靜態站台，部署到 GitHub Pages。 這種「機器人持續寫入」的特性，讓站台的成本不是線性增加，而是在好幾個環節同時被放大。等到我們去看的時候，數字已經很難看： 症狀 數字 ────────────────────────────────────────────── 搜尋索引 (search_index.json) 195 MB 首頁 HTML 1.07 MB 單一深層報告頁 HTML 590 KB 單次部署 payload 752 MB 建置完成的站台總大小 ~3.1 GB CI 建置 + 部署時間 ~15 分鐘 每天觸發部署次數 ~42 次（每個分析任務 push 一次） 最致命的不是任何單一數字，而是它們互相加乘：5,000 頁 × 每頁 1MB 的導覽樹 = 站台爆炸；42 次/天 × 752MB 的部署 = CI 排隊塞車。我們要做的，是逐一拆掉這些放大器。