網站首頁靜態化已過時：現代緩存架構才是高效能關鍵

誤區：靜態化 = 高效能

許多開發者認為「將首頁生成靜態 HTML」是提升訪問速度的銀彈。實際上，**靜態化本質是「以磁碟當快取」**，屬於低階、原始、低效的做法。

靜態化的痛點

• 資料一致性難題：輪播圖 1 小時更新、播放數/點贊需即時，靜態化意味著必須頻繁重新生成或接受髒資料。
• 部署複雜度：需分散式檔案系統同步靜態檔、Nginx 快取失效策略、生成腳本維護。
• 無法處理個性化：不同使用者看到不同推薦/登入狀態，靜態頁無法滿足 (除非 ESI/SSI 片段包含，增加複雜度)。
• 磁碟 I/O 瓶頸：高併發下大量讀取靜態檔仍受限於磁碟/檔案系統效能。

現代解決方案：多層快取架構

1. 瀏覽器端快取 (HTTP Cache Headers)

Cache-Control: public, max-age=300, stale-while-revalidate=600
ETag: "v1.2.3"

靜態資源 (JS/CSS/圖片) 強快取；HTML 協商快取或短快取。

2. CDN 邊緣快取

• 將靜態資源推至 CDN (Cloudflare, AWS CloudFront, 阿里雲 CDN)。
• 動態 HTML 可配置 Edge Side Includes (ESI) 或短 TTL 快取。

3. 反向代理快取

Nginx fastcgi_cache / proxy_cache 或 Varnish：

# Nginx 範例
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=PAGE_CACHE:100m inactive=1h;
server {
    location / {
        proxy_cache PAGE_CACHE;
        proxy_cache_valid 200 5m;          # 成功頁面快取 5 分鐘
        proxy_cache_valid 404 1m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_pass https://backend;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

4. 應用層快取 — 核心業務資料

• Redis / Caffeine / Ehcache：快取「首頁聚合資料」 (輪播圖、熱門影片清單、統計數字)。
• 資料結構：用 Hash 存播放數/點贊數 (HINCRBY 即時更新)；用 Sorted Set 存排行榜。
• 快取策略：
  • 輪播圖：TTL 1 小時 + 主動失效 (後台更新時 DEL key)。
  • 播放數/點贊：Redis 原子計數器即時更新，定期 (如每 5 分鐘) 持久化回 DB。

5. 頁面片段快取

Thymeleaf/Freemarker/Velocity 等模板引擎支援片段快取：

...

美拍/抖音等高流量首頁架構縮影

1. 使用者請求 → CDN (快取 HTML 片段/靜態資源)。
2. Miss → Nginx 快取層 (快取渲染後 HTML，TTL 秒級)。
3. Miss → 應用服務 (Spring Boot/Go/Node.js)。
4. 應用服務 → Redis 讀取聚合資料 (輪播圖、推薦列表、計數器)。
5. 應用服務 → 模板引擎渲染 → 回傳 HTML。
6. 非同步任務：計數器定期落地 DB；推薦系統離線計算每小時更新 Redis。

結論

**不要再生成靜態 HTML 檔案了。** 擁抱 **Redis + Nginx/Varnish + CDN + HTTP Cache** 的多層快取體系。它解決了即時性 (計數器)、個性化 (片段快取/ESI)、一致性 (主動失效)、擴展性 (分散式快取) 所有靜態化無法優雅解決的問題。這才是現代高流量網站首頁的標準架構。