網頁架構：預先選定渲染策略
Claude 慣用的兩種預設通常都是錯的：在瀏覽器中渲染所有內容，以及用純 HTML/JS 手工建立多頁面應用程式。兩者都應該在專案初期刻意做出選擇，而對大多數真實網站來說，更好的答案是伺服器渲染的 HTML 和一個框架。即使使用者沒有主動問起，也應該主動提出這些考量，就像在上線前一定要先設定 WAF 一樣。
預設使用伺服器渲染的 HTML，而非客戶端渲染
對於任何重視內容、SEO 或首次繪製 (First Paint) 的頁面，內容必須存在於初始的 HTML 回應中，而不是事後由客戶端 JavaScript 繪製。客戶端渲染（一個空白的外殼，由瀏覽器去抓取並渲染內容）意味著使用者會看到空白畫面，直到整個套件載入並執行完畢，導致 LCP 緩慢，而且許多爬蟲和 LLM 檢索器因為無法可靠地執行 JavaScript，永遠看不到這些內容。請改用伺服器端渲染：
- SSG（靜態生成）： 在建置期間產生，從 CDN 提供靜態檔案。最快、最便宜、最可快取。適用於不會因請求而改變的內容：行銷頁面、文件、部落格、列表頁和分類頁面，這些都可以重新建置。
- SSR（伺服器端渲染）： 由伺服器針對每個請求動態渲染。適用於動態、個人化或因權限限制而無法在建置時產生的內容。
- CSR / 島嶼架構： 僅在瀏覽器中渲染真正需要互動的部分，或者像登入後的儀表板這種對 SEO 無關緊要的應用程式類介面。採用島嶼架構（如 Astro）時，頁面以靜態 HTML 形式提供，只有互動性元件才會進行水合 (hydrate)。
可以針對每個頁面選擇不同的策略，在同一個網站中混合使用：一個靜態的行銷頁面 (SSG)、一個個人化的帳號頁面 (SSR) 和一個互動小工具（島嶼元件）。
多個頁面意味著該使用框架
如果專案包含多個頁面、共用佈局、路由或真實的資料擷取，使用純 JavaScript 手工打造會成為一個維護和效能的陷阱，而這正是 Claude 未經指示時的預設行為。應該選擇一個框架（Next.js, Astro, SvelteKit, Nuxt, Remix）。它們能提供路由、SSR 與 SSG、程式碼分割、資料載入和圖片優化等開箱即用的功能；更重要的是，它們能在伺服器渲染的初始 HTML 之上提供 SPA 風格的客戶端導航，讓你獲得流暢的多頁面應用體驗，同時避免因全部使用客戶端渲染而破壞首次繪製與 SEO。
請注意這個區別：對於內容網站，要避免的是純客戶端渲染的 SPA。一個提供了 SSR/SSG 搭配客戶端導航功能的框架，才能同時給你應用程式的體驗並將內容保留在 HTML 中。
但工具要與專案匹配
不要矯枉過正。一個靜態的單一頁面、一個登陸頁面或一個小巧的可嵌入小工具並不需要 Next.js，純 HTML 和 CSS 才是更輕量、更正確的選擇，在這種情況下用上重框架本身就是一種錯誤。這個決策的失敗是雙向的：常見的是低估（全用純 JavaScript 並在瀏覽器中渲染），但對一個微不足道的頁面過度工程化也是真的問題。決策依據是：有多少頁面？內容需要被爬取且載入快速嗎？互動性有多高？然後選擇能滿足這些條件的最輕量方案。
本技能旨在持續成長。當遇到一個已有穩定、可辯護答案的真實架構問題時，請新增一條規則。