靜態與動態

差別在於「內容從哪裡來」

一句話區分：靜態是「寫死的」，動態是「活的」。

用餐廳比喻

• 靜態網站像便當店——餐點事先做好，客人來了直接拿。快，但只有既定的品項。
• 動態網站像現點現做的餐廳——客人點什麼，廚房才開始組合。彈性高，但需要準備時間。

快取的作用，就是把常被點的菜先做好放著。 這樣既有彈性，又能快速上菜。

怎麼判斷自己的網站是哪一種

最簡單的判斷方式：你能不能自己登入後台改內容？

• 可以——動態網站
• 不行，每次都要請廠商改——很可能是靜態網站，或該單元沒有做成可管理

常見的混合情況

實務上很多網站是混合的：

• 最新消息、產品——動態，可自行新增
• 公司簡介、關於我們——靜態，寫死在版型中

這是合理的做法，因為不常變動的內容做成可管理，反而增加成本卻用不到。

判斷標準見哪些內容需要做成後台可自行管理。

為什麼企業網站多數需要動態

一、內容會持續增加

產品、案例、消息都會不斷新增。如果每加一則都要請廠商改程式，成本與時效都不合理。

二、同一筆資料要在多處呈現

一項產品可能同時出現在：首頁的推薦、產品列表、分類頁、搜尋結果、相關產品。

靜態的做法要改五個地方，動態只要改一次。

三、需要互動功能

表單、會員、購物車、搜尋——這些都需要程式處理，靜態網站做不到。

靜態網站什麼時候合適

• 內容幾乎不會變動——例如活動的一次性介紹頁
• 頁面數量很少
• 沒有互動功能的需求
• 對速度與穩定性要求極高

但要留意：「現在不會變」通常不成立。 多數業主一年後都會想改點東西。

一個常見的誤會

「我的網站是靜態的，所以比較安全」——這個說法只對了一半。

靜態網站確實少了資料庫與後台這兩個攻擊面，但：

• 主機本身仍可能被入侵
• 若有任何互動功能（例如表單），仍有風險
• 不更新的靜態網站，其所在的主機環境仍需要維護

成本的差異在哪

動態網站的成本主要來自：

• 後台管理系統的開發——每一個可管理的單元都要做
• 資料庫的規劃
• 互動功能的開發

所以報價會問「有幾個單元」

因為每個可自行管理的單元都是獨立的工作項目——最新消息、產品、案例各自需要列表頁、內容頁、後台管理介面。

費用的組成見網站架設費用怎麼算。

接下來可以了解的

• 資料庫在網站中扮演什麼角色——為什麼改一次全站都更新
• 版型與內容的分離——為什麼改版不用重打內容
• 我的網站該選哪一種

資料庫像一個很大的表格系統

你在後台輸入的每一篇文章、每一項產品，都不是存成一個檔案，而是存成資料庫裡的一列。

可以想像成一張試算表：

網站要顯示「最新三則消息」時，就是去這張表裡依日期排序、取出前三筆，再套進版型顯示出來。

一筆資料，多處呈現

這是資料庫最重要的價值。

一項產品可能同時出現在：

• 首頁的推薦區塊
• 產品列表頁
• 所屬分類的頁面
• 搜尋結果
• 其他產品頁的「相關商品」
• 網站地圖

但實際上只有一筆資料。 這代表：

• 改一次，所有地方都會更新
• 不會出現「有些地方是舊資訊」的情況
• 下架時，所有地方一起消失

對照靜態的做法

如果是寫死的，同樣的產品資訊要在六個地方各寫一次。改價格時要改六個地方，漏掉一個就會出現不一致。

這解釋了三件事

一、為什麼備份一定要包含資料庫

只備份檔案，還原出來會是一個沒有內容的空殼。

因為文章、產品、訂單、會員全部在資料庫裡，檔案裡只有程式與版型。

這是最常見也最嚴重的備份疏失，見備份策略怎麼規劃。

二、為什麼後台要保護好

後台是操作資料庫的入口。後台被入侵，等於整個資料庫都可能被讀取或竄改。

見後台的資安。

三、為什麼資料庫出問題網站就打不開

動態網站每次顯示頁面都要向資料庫取資料。資料庫連不上時，網站會顯示錯誤而不是空白頁。

欄位：資料的結構

每一種內容都有自己的欄位設計。例如一項產品可能包含：

• 名稱、編號、價格
• 主圖、多張附圖
• 簡介、詳細說明
• 規格表
• 所屬分類
• 上下架狀態
• 排序

欄位要在規劃階段決定

這是報價的重要依據。 欄位越多，後台介面越複雜，開發成本越高。

而且欄位越多，你自己上架資料時的時間成本也越高——一百項產品，每項多填三個欄位就是三百次輸入。

只保留真正會用到的欄位。 沒有人會填的欄位，做了也是浪費。

關聯：資料之間的關係

資料庫可以記錄資料之間的關係，例如：

• 一項產品屬於某個分類
• 一筆訂單包含多項商品
• 一則留言對應某一篇文章

這讓網站能做到「顯示這個分類下的所有產品」「顯示這位會員的所有訂單」這類功能。

實務上的意義

分類架構要在規劃階段想清楚。 上線後要調整分類方式，可能牽涉大量資料的重新歸類。

搜尋與篩選也靠資料庫

網站的站內搜尋、依價格排序、依規格篩選，都是對資料庫下條件查詢。

這也是為什麼篩選功能會影響報價

每一個可篩選的條件，都需要在資料中有對應的欄位。「依材質篩選」的前提是每項產品都有記錄材質。

資料量大時會變慢

資料筆數少時感覺不出來，但成長到數萬筆之後，查詢速度會明顯下降。

常見的改善方式

• 加上索引——讓資料庫能快速定位，不必逐筆掃描
• 使用快取——把結果暫存起來
• 分頁——不要一次撈出全部

這些屬於技術層面，但業主可以知道：網站變慢不一定是主機不夠力，也可能是資料查詢的方式需要調整。

見網站慢的常見原因與優先處理順序。

資料的匯出與帶走

這是很重要但常被忽略的一點。

你的內容存在資料庫裡，所以「能不能匯出資料庫」決定了你能不能帶走自己的資料。

發包時該確認的

• 能不能自行匯出完整資料
• 匯出的格式是什麼
• 換廠商時資料怎麼交接

使用租用型平台時特別要問清楚——有些平台的資料無法完整匯出。

見開店平台、套版還是自建。

內容與外觀是分開的

這是動態網站最核心的設計概念，也是理解「改版」為什麼可行的關鍵。

• 內容存在資料庫——標題、內文、圖片、日期
• 版型存在檔案中——決定這些內容長什麼樣子、排在哪裡

顯示網頁時，系統把兩者組合起來。

用信件比喻

想像一份制式的通知信：

親愛的 ●●● 先生／女士：

您訂購的 ▲▲▲ 已於 ■■■ 出貨。

信的格式是版型，填進去的資料是內容。

同一份格式可以套用給一千位客戶，每個人看到的是自己的資料。網站的運作方式是一樣的——一個產品頁的版型，套用給所有產品。

這帶來三個實際的好處

一、改版不用重打內容

換一套新的版型，資料庫裡的內容不動。五百篇文章、三百項產品都會自動套用新設計。

這是改版最大的價值——你付的是設計與開發的費用，不是重新輸入內容的費用。

二、統一調整很容易

想把所有產品頁的價格改成紅色？改版型一處，三百頁一起變。

如果是寫死的，就要改三百次。

三、可以有多種呈現方式

同一筆資料，在列表頁顯示縮圖與標題，在內容頁顯示完整內文。取的是同一筆資料，只是套用不同的版型。

所以：內文中不要寫死樣式

這是實務上最重要的一個提醒。

在後台編輯內容時，很多人會直接調整字體大小、顏色、粗細，讓它看起來符合心中的樣子。

這會造成什麼問題

• 改版時這些設定會殘留——新版型套上去，但內文還是舊的顏色與字體，看起來很突兀
• 無法統一調整——想改樣式要一篇一篇改
• 手機上可能破版——寫死的寬度或字級在小螢幕上會出問題

正確的做法

• 用「標題」功能，不要用「放大加粗」——標題有層級意義，樣式由版型統一控制
• 用「清單」功能，不要自己打符號
• 不要在內文中設定固定的寬度或字級
• 從別處貼上文字時，先清除格式——這是最常見的問題來源

從文書處理軟體直接複製貼上，會帶入大量隱藏的格式設定，日後改版時特別麻煩。

詳細做法見後台編輯器怎麼用。

圖片也是同樣的道理

不要把文字做在圖片上

常見的做法是把整段文案做成一張圖直接放上去。這會造成：

• 搜尋引擎讀不到那些文字
• 手機上會縮到看不清楚
• 要改一個字就要重做整張圖
• 多語系網站要每個語言各做一張

正確做法是把文字放在圖片外面，或用網頁文字疊在圖上。

見圖片的替代文字與檔名該怎麼寫。

版型可以更換，內容是資產

這個觀念值得建立：

所以內容的乾淨程度很重要。 內文中殘留越多寫死的樣式，日後改版的整理成本就越高。

常見的問題與處理

改版後舊文章的排版很亂

通常就是內文中殘留了舊的樣式設定。處理方式：

• 用編輯器的清除格式功能
• 大量文章可請廠商批次處理
• 從現在開始養成不寫死樣式的習慣

某一篇文章特別想要不同的樣式

如果是偶爾的特殊需求，可以請廠商為該類型建立一個版型變體，而不是在內文中寫死。

想要每篇文章有不同的版面

這通常代表需要的是可選擇的版型——後台提供幾種版面讓編輯選擇。這是可以開發的功能，但要在規劃時提出。

驗收時可以確認的事

1. 後台編輯器有沒有「標題」層級可選
2. 有沒有清除格式的功能
3. 貼上文字時會不會自動處理格式
4. 編輯後在手機上看是否正常

版型的選擇與客製程度見版型、模組化與客製設計的差別。

動態網站每次都要「組合」

訪客打開一個頁面時，動態網站要做這些事：

1. 接收請求
2. 執行程式
3. 向資料庫查詢資料——可能不只一次
4. 把資料套進版型
5. 產生完整的網頁回傳

靜態網站則是直接把現成的檔案送出去，省下了中間的所有步驟。

這就是速度差異的來源。

但動態不一定慢

這一點要說清楚：設計良好的動態網站，速度可以與靜態網站相近。

實務上網站慢的原因，多半不是「因為它是動態的」，而是：

• 圖片沒有壓縮——這是最常見的原因
• 資料庫查詢沒有最佳化
• 安裝了過多的外掛
• 沒有使用快取
• 主機規格不足

先處理圖片，通常比換主機有效得多。 完整的排查順序見網站慢的常見原因與優先處理順序。

快取是什麼

把處理過的結果暫存起來，下次直接使用，不必重新處理。

回到餐廳的比喻：常被點的菜先做好放著，客人來了直接上，不用從頭開始煮。

對動態網站的意義

第一個訪客打開頁面時，系統完整跑一次流程並把結果存起來。後面的訪客直接拿現成的結果，速度接近靜態網站。

快取存在很多地方

這解釋了為什麼「改了東西看不到變化」有時候特別難處理——可能有好幾層快取都要清。

改了看不到變化怎麼辦

依序排除：

1. 用無痕視窗開啟——排除瀏覽器快取
2. 用手機的行動網路開啟——排除本地網路的快取
3. 清除網站後台的快取
4. 若有使用加速服務，清除該服務的快取

判斷方法

• 無痕視窗看得到新內容→ 是瀏覽器快取，只有你看到舊的
• 無痕視窗也是舊的→ 問題在伺服器端，需要清除系統快取

更完整的說明見快取是什麼。

快取的取捨

快取讓網站變快，但也帶來一個問題：內容更新後，訪客可能還看到舊版本。

常見的處理方式

• 設定較短的快取時間——更新較快反映，但效能提升較少
• 更新內容時自動清除相關快取——較理想，需要開發配合
• 更新資源時改檔名——例如圖片改版時用新檔名，這是最可靠的做法

建議在驗收時確認：後台有沒有清除快取的功能。 沒有的話，每次更新都要請廠商處理。

哪些頁面不該快取

這一點很重要，涉及資安。

• 登入後的個人頁面——會員中心、訂單查詢
• 購物車
• 後台
• 任何顯示個人資料的頁面

為什麼

如果把 A 使用者的頁面快取後回應給 B，就是一次個資外洩。

這是實際發生過的事故類型。驗收時務必測試：用兩個帳號分別登入，確認各自看到正確的資料。

其他加快的方式

除了快取，還有幾個常見的做法：

圖片處理

• 壓縮到適當的品質
• 依顯示尺寸提供適當大小，不要用原圖縮小顯示
• 使用較新的圖片格式
• 延後載入未進入畫面的圖片

這通常是投報率最高的一項。

內容傳遞網路

把圖片、樣式等靜態檔案放到分布各地的節點，讓訪客就近取得。對跨地區的客群特別有效。

資料庫最佳化

加上索引、減少不必要的查詢。這屬於開發層面，但可以請廠商檢視。

速度重要到什麼程度

幾個實際的影響：

• 載入時間越長，離開的比例越高——尤其是手機使用者
• 投廣告時，慢的頁面等於浪費預算——錢花了但人還沒看到內容就走了
• 速度是搜尋排名的參考因素之一

但也不要過度追求數字

測速工具的分數是參考，真正該看的是實際使用者的體驗——用手機的行動網路實際開一次，感覺如何。

見怎麼測網站速度。

現在的做法比以前多

「靜態」與「動態」是基本的區分，但實務上發展出了幾種不同的組合方式。

這一篇用白話介紹常見的幾種，目的不是讓你選技術，而是聽得懂廠商在說什麼。

一、純靜態網站

網頁檔案事先寫好，直接放在主機上。

• 優點——最快、最穩定、成本最低
• 缺點——改內容要動程式碼，沒有後台
• 適合——一次性的活動頁、內容極少且不變的網站

二、傳統動態網站（含後台）

目前最常見的做法。內容存在資料庫，透過後台管理，訪客瀏覽時即時組合出頁面。

• 優點——可自行管理、功能彈性、成熟穩定
• 缺點——需要主機與資料庫、要維護更新
• 適合——絕大多數企業網站

這也是本站說明的主要對象。

三、靜態產生器

折衷的做法：後台編輯內容，但系統會事先把所有頁面產生成靜態檔案。

訪客看到的是靜態檔案，速度接近純靜態；編輯者仍然有後台可用。

• 優點——速度快、安全性較高、主機需求低
• 缺點——內容更新後需要重新產生、不適合需要即時互動的功能
• 適合——內容型網站、部落格、文件網站

不適合的情況

有會員、購物車、即時庫存、訂單查詢這類功能時，因為每個使用者看到的內容不同，無法事先產生。

四、前後端分離

把「內容管理」與「呈現」拆成兩個系統：

• 後端——只負責管理與提供資料
• 前端——負責把資料呈現成畫面

兩者透過約定的介面溝通。

什麼情況會用

• 同一份內容要供應多個管道——網站、手機應用程式、其他系統
• 需要高度客製的前端互動
• 有專門的前端開發團隊

對中小企業的實務提醒

這種架構的建置與維護成本通常較高，而且需要對應的技術能力。

如果只是一般的企業網站，傳統的做法通常更務實——成本低、找得到人維護、生態成熟。

五、混合做法

實務上很常見的組合：

• 大部分頁面用快取——效果接近靜態
• 需要即時的部分保持動態——購物車、會員中心
• 靜態檔案放到加速服務

這是多數成熟網站的實際樣貌——不是非黑即白，而是依需求分別處理。

租用型平台又是另一回事

開店平台、網站建置平台屬於另一個類別：

• 你租用的是服務，不是軟體
• 版型與功能在平台的框架內
• 停止付費後網站就消失
• 資料能否完整匯出，依平台而異

初期成本低、上線快，適合驗證市場的階段。但要理解它的性質。

比較見開店平台、套版還是自建。

怎麼判斷廠商的建議是否合理

當廠商提出某種技術方案時，可以問三個問題：

1. 為什麼選這個做法？ 對應到我的哪個需求
2. 日後要找別人維護，好找嗎？
3. 資料能不能完整帶走？

第二題很重要

越冷門的技術，日後越難找到人接手。對中小企業而言，「成熟且普遍」通常比「新穎」更有價值。

第三題是底線

不論用什麼技術，你的內容應該能夠匯出。 這是資產歸屬的問題，見資料庫在網站中扮演什麼角色。

一個務實的結論

對絕大多數的企業網站，傳統的動態網站加上適當的快取，就是最合理的選擇。

理由：

• 功能彈性足夠
• 成本可控
• 技術成熟，容易找到維護人員
• 加上快取後速度也不差

不必為了追求新技術而增加成本與風險。 技術的選擇應該服務於需求，而不是反過來。

先問三個問題

1. 內容會不會需要自己更新？
2. 需要互動功能嗎？——表單、會員、購物車、搜尋
3. 頁面數量會持續增加嗎？

只要有任何一題答「是」，就需要動態網站。

實務上，這三題全部答「否」的企業網站非常少。

依情境的建議

一般企業形象網站

建議：動態網站，含後台。

理由：最新消息、產品、案例都會持續增加，需要自行管理。

只有幾頁的簡介型網站

建議：動態，但只把會變動的單元做成可管理。

例如公司簡介寫死沒關係，但最新消息應該可以自己發。

活動或產品的一次性宣傳頁

建議：靜態或簡易動態皆可。

但要注意：活動結束後不要直接刪除頁面，應轉向到相關的常態頁面，否則會產生錯誤頁面。

產品數量多的型錄網站

建議：動態，且要有完整的分類與搜尋。

產品越多，動態的價值越明顯——靜態的做法在維護上完全不可行。

購物或預約網站

必須是動態。 庫存、訂單、會員都需要即時處理。

不是全站都要做成可管理

這是最容易誤解的一點。「動態網站」不代表每一個字都要能在後台改。

建議做成可管理的

• 最新消息、公告——本質上就是持續新增
• 產品或服務項目
• 案例、作品
• 常見問答
• 聯絡資訊——電話、地址可能異動

可以寫死的

• 公司簡介的主文——幾年才會改一次
• 首頁的固定文案
• 版面的結構與設計

判斷標準

一年會改幾次？

• 經常改 → 做成可管理
• 幾年一次 → 請廠商調整即可，做成可管理反而增加成本

詳細判斷見哪些內容需要做成後台可自行管理。

過度追求「什麼都能改」的代價

把每個區塊都做成可自行編輯，聽起來很有彈性，但：

• 開發成本明顯增加
• 後台介面變複雜，不易上手
• 容易被改壞——版面結構被誤動，整頁跑掉
• 實際上多數區塊從來沒被改過

合理的做法是分層：內容可改，結構不可改。

常見的三個決策錯誤

一、為了省錢做成純靜態

初期省下後台的開發費，但之後每次改內容都要付費請廠商處理。

一年改個十次，成本可能就超過當初的差額，而且時效也差。

二、為了「彈性」什麼都做成可管理

如上所述，成本高、複雜、且用不到。

三、沒有考慮誰來維護

有後台不代表有人會用。 規劃時要考慮：

• 誰負責更新內容
• 那個人的技術程度
• 需不需要教育訓練

做了很複雜的後台但沒有人會用，等於沒有做。

發包時該問清楚的事

1. 哪些單元可以自己管理？ 請列出清單
2. 後台可以新增分類嗎？ 還是只能新增資料
3. 圖片可以自己換嗎？ 包含首頁的主視覺嗎
4. 可以自己調整選單嗎？
5. 有教育訓練或操作手冊嗎？
6. 日後要增加一個單元，費用怎麼算？

第一項應該白紙黑字寫進報價單或合約，避免驗收時各自解讀。

可以分階段規劃

不必一次做到最完整：

1. 第一階段——把必要的單元做成可管理
2. 實際使用三到六個月
3. 依實際需求擴充

好處是：你會很清楚哪些真的需要，哪些是想像出來的需求。

常見的情況是，原本以為一定要能自己改的東西，一年下來根本沒動過；反而是當初沒想到的地方經常需要調整。

但架構要預留

發包時要確認：日後要增加可管理的單元，是擴充還是重做？

如果答案是重做，那第一階段就要多考慮一些。

驗收時的確認

1. 清單上的每個單元，都實際新增一筆試試
2. 試著修改與刪除
3. 確認前台正確顯示
4. 請實際會用的同仁操作一次，不要只由主管或工程師代測
5. 確認有操作說明可參考

第四項最有價值。 後台好不好用，決定了往後幾年的維護成本。

驗收項目見網站驗收怎麼做。