[備忘錄]建立本部落格時的架構決策和注意事項

📅 發布日: 2023/01/01, 更新日: 2023/04/08 ⏱️ 預計閱讀時間約8分鐘 (3,291字)

一份全面的備忘錄，涵蓋靜態與動態站點選擇、託管平臺評估、自定義Pandoc SSG架構、基於Confluence的UI設計和多語言SEO。

目錄

（考慮因素 1）靜態站點與動態站點？
1. 靜態站點和動態站點之間的差異
（考慮因素2）選擇靜態站點託管平臺
（考慮因素 3）選擇靜態站點生成器
（考慮因素 4）定製 UI 和資訊設計
（考慮因素 5）SEO 策略和最佳實踐
總結

（考慮因素 1）靜態站點與動態站點？

評估靜態網站生成器還是動態 CMS 是否更符合您的技術要求是構建網站時的關鍵架構決策。
這兩種正規化之間的選擇從根本上影響功能集、開發人員體驗、可維護性、可擴充套件性和安全狀況。

靜態站點和動態站點之間的差異

靜態站點
純粹由預渲染的靜態資源（HTML、CSS、JavaScript、媒體檔案）組成。進行內容更改需要直接重建或編輯檔案。
非常適合內容保持相對一致且不需要實時使用者特定資料庫寫入的技術文件、個人部落格和資訊網站。
動態站點
根據每個 HTTP 請求，透過伺服器端執行時、資料庫和應用程式框架動態呈現內容。
非常適合互動式應用程式、多租戶協作平臺、電子商務或涉及頻繁實時使用者互動的場景。
以下是靜態和動態架構之間的優缺點比較。高優先順序標準以斜體顯示。

靜態站點的優點

快速的頁面載入速度和卓越的使用者體驗（TTFB / Core Web Vitals）。
源伺服器上沒有計算負載，可以透過 CDN 快取輕鬆擴充套件到高流量峰值。
穩定的內容交付，停機時間或伺服器崩潰風險幾乎為零。
可靠的安全態勢，攻擊面最小（無直接資料庫注入或後端漏洞）。
與動態伺服器例項相比，執行和託管成本極低。

靜態站點的缺點

內容更新需要執行構建/部署管道。
如果沒有客戶端 API，則無法執行任意後端邏輯，從而限制了互動式伺服器端工作流程。
不適合需要事務資料庫寫入或個性化伺服器會話的複雜應用程式。

動態站點的優點

豐富的實時互動性促進活躍的使用者交流和社群功能。
直接從關聯式資料庫或文件資料庫支援的瀏覽器 GUI 輕鬆進行內容編輯。
透過動態外掛和按需伺服器端指令碼實現高可擴充套件性。

動態站點的缺點

如果沒有積極的快取，頁面響應時間會變慢，並且可能會降低使用者體驗。
伺服器和資料庫負載過重，導致基礎設施和運營成本較高。
持續安全維護（修補 CMS 漏洞、SQL 注入、CVE）。

雖然動態站點使標記和搜尋等橫切功能更容易實現，但選擇靜態站點架構是為了消除維護開銷並使運營成本接近於零。
參考：
靜態網站和動態網站的區別、優缺點 |Xserver業務

（考慮因素2）選擇靜態站點託管平臺

部署靜態站點需要可靠的儲存和 CDN 分發基礎設施。
雖然由於熟悉 GCP，Google Cloud 的 Firebase Hosting 成為主要候選平臺，但我們對替代平臺進行了系統評估。
根據比較靜態站點託管平臺|JavaScript 公告，領先的託管提供商包括：

網路化
韋爾塞爾
Firebase 託管
Cloudflare 頁面
GitHub 頁面
亞搏體育appGitLab頁面

根據四個關鍵標準進行評估：“日本的 Edge CDN PoP”、“透過 GitHub / Cloud Build 自動部署”、“足夠的免費套餐配額”和“允許的商業用途”。

託管服務	日本CDN PoP	GitHub / 雲構建部署	慷慨的免費套餐	商業用途
網路化	×	⚪︎	⚪︎	⚪︎
韋爾塞爾	⚪︎	⚪︎	⚪︎	×
Firebase 託管	⚪︎	⚪︎	⚪︎	⚪︎
Cloudflare 頁面	⚪︎	⚪︎	⚪︎	⚪︎
GitHub 頁面	⚪︎	×	⚪︎	×
亞搏體育appGitLab頁面	⚪︎	×	⚪︎	？

Firebase Hosting 和 Cloudflare Pages 成為最有力的競爭者。
雖然 Cloudflare Pages 提供了引人注目的邊緣工作人員功能，如 [Cloudflare Pages vs Firebase Hosting | 中詳細介紹的]Bejamas](https://bejamas.io/compare/cloudflare-pages-vs-firebase/)， 選擇 Firebase Hosting 是因為它利用我們現有的 Google Cloud 帳戶基礎架構，與 Google Analytics 無縫整合，並與 Cloud Build 管道本地連線。

（考慮因素 3）選擇靜態站點生成器

靜態站點生成器 (SSG) 將源標記（Markdown、AsciiDoc）和模板編譯為生產就緒的靜態資產。
評估了三個具有代表性的靜態站點生成器：
最初的目的是採用 Hugo 來最小化設定開銷。
然而，事實證明，找到與 Atlassian Confluence 文件美學緊密匹配的現有主題很困難。因此，開發了一個利用 Pandoc 的自定義 Python 驅動構建管道。

Jekyll 優點

本機 GitHub Pages 整合。
透過 Liquid 和 Markdown 進行直觀的模板.
豐富的外掛生態系統。

傑基爾的缺點

Ruby 環境管理和大型站點上較慢的構建時間。

雨果·普洛斯

用 Go 編寫的編譯速度極快。
主題和內容清晰分離。
簡單的 Markdown 創作工作流程。

雨果·康斯

Go 模板語法學習曲線和相對較少的專業社群主題。

蓋茨比優點

強大的 GraphQL 資料層和豐富的 React 元件生態系統。
整合無頭 CMS 後端的龐大外掛庫。

蓋茨比的缺點

架構複雜度高、依賴性膨脹、學習曲線陡峭。

（考慮因素 4）定製 UI 和資訊設計

Pandoc 跨格式轉換文件（Markdown、HTML、PDF、Word）。透過使用“–template”標誌指定自定義 HTML 模板，可以使用自定義佈局和 CSS 樣式來格式化靜態頁面。
Pandoc 使用者指南 - 模板

Confluence 風格的側邊欄

使用 Python 和 JavaScript 開發，複製 Atlassian Confluence 空間側邊欄的簡潔導航，使使用者能夠輕鬆地在類別和帖子之間跳轉。
參考： Atlassian Confluence Space 側邊欄文件

目錄 (ToC)

實現了一個 Python 指令碼來解析 HTML 標題標籤（ h2 、 h3 ）並動態生成互動式目錄。
參考： DevelopersIO - 透過 Python 從 HTML 標題生成目錄

程式碼塊的語法突出顯示

將 Prism.js 與“明晚”主題和自定義 CSS 顏色調整整合。
參考： Prism.js 官方網站
語言包包括 Bash、Python、Docker、YAML、JSON、Git 和 Markdown。

站內搜尋

整合的 Google 自定義搜尋引擎 (CSE)，在所有索引部落格頁面上提供強大的搜尋功能，無需記憶體搜尋伺服器。

網站圖示

使用 GIMP 生成並透過線上圖示工具調整大小（512x512 縮小至 256x256、32x32、16x16），以確保在桌面和移動裝置上呈現清晰的渲染效果。

（考慮因素 5）SEO 策略和最佳實踐

搜尋引擎最佳化 (SEO) 確保技術文章在搜尋引擎結果頁面 (SERP) 中排名靠前，並吸引尋求解決方案的開發人員。

1. 多語言和全球搜尋引擎最佳化

最初專注於日本讀者，該網站轉變為雙語（英語/日語）架構，以覆蓋更廣泛的全球工程受眾。
在 <html> 根上配置正確的 lang 屬性，並實現相互的 <link rel="alternate" hreflang="..."> 標記，以幫助 Google 提供正確的本地化頁面。
部署不同的 XML 站點地圖（“sitemap.xml”和“sitemap_en.xml”）以實現全面的搜尋爬蟲發現。

2. 影象最佳化

目標最佳內容寬度為 786px，具有響應式尺寸。
使用 JPG 表示複雜的攝影媒體，使用壓縮的 PNG/SVG 表示技術架構圖。
持續監控 Google PageSpeed Insights，以最大程度地減少 Core Web Vitals 佈局變化 (CLS) 並確保快速的最大內容繪製 (LCP)。

3. 語義 HTML 和標籤最佳化

保留正確的標題層次結構並利用自定義開放圖譜協議 (OGP) 元標記（標題、描述、影象、URL）來最佳化 X (Twitter) 和 Slack 上的社交卡預覽。
將導航結構簡化為單個語義“
”容器，以實現乾淨的螢幕閱讀器可訪問性和可爬行性。

4. 社交分享和放大

為每個帖子配備快速社交分享按鈕（X、Hatena 書籤和本機 URL 副本），以鼓勵開發人員聯合和討論。

5. 固定連結最佳化

標準化、乾淨的字母數字永久段，可防止 URL 百分比編碼問題並保護爬網索引完整性。

總結

透過將靜態站點簡單性 (Pandoc + Python) 與 Firebase 託管和自動化 Cloud Build CI/CD 相結合，該部落格在日語和英語受眾中實現了接近零的執行成本、亞秒級的載入時間和堅如磐石的可靠性。

連結已複製到剪貼簿！