元伸科技
「我們的網站要做 RWD」——這句話在 2026 年其實是廢話。Google 從 2021 年就把 mobile-first indexing 列為標配，沒做 RWD 的網站連 SEO 入場券都沒有。
但實務上跟客戶聊時最常聽到的誤解是：「RWD 就是畫面會自動縮小吧？」——不是。RWD 是 客製化網頁設計 過程中一連串需要早期定案的設計決策，這些決策晚了、開發成本就翻倍。下面拆解 6 個必須在建站初期（資訊架構與視覺設計階段）就決定的 RWD 關鍵決策，老闆最常踩的坑也順便講清楚。
決策 1：斷點規劃（Breakpoints）
斷點是 RWD 的骨架，決定畫面在哪些寬度會切換佈局。標準框架（Bootstrap、Tailwind）預設 5-6 個斷點，但客製化網頁設計的價值就是根據你的內容決定斷點。常見的客製化斷點：
| 斷點 | 寬度 | 對應裝置 |
|---|---|---|
| sm | < 480px | 小型手機 |
| md | 481-768px | 大型手機 / 直立平板 |
| lg | 769-1024px | 橫向平板 / 小筆電 |
| xl | 1025-1440px | 桌機 / 大筆電 |
| 2xl | > 1441px | 大螢幕 / 4K |
早期定案的好處：設計師畫 mockup 時就用同一組斷點、CSS 變數系統可以一次定義、工程師實作時不用問「1200px 算大還小？」。晚定案的代價：每個元件可能用不同斷點邏輯，網站某些寬度下顯示異常但 QA 抓不到——實務上看過上線三個月後才被使用者回報「我用 13 吋筆電開選單會跑版」的案例，找原因找到一週。
決策 2：Mobile First vs Desktop First 設計順序
這是視覺設計階段最大的方向性決策，影響整個專案的設計思維。Mobile First 從手機開始設計，再往桌機加東西；Desktop First 從桌機開始，往手機減東西。兩者最終結果可能類似，但設計過程中的「優先」不同：
| 決策因素 | Mobile First | Desktop First |
|---|---|---|
| 適合的產業 | B2C 電商、餐廳、預約、社群、媒體 | B2B 工業、企業官網、SaaS、後台系統 |
| 流量結構 | 手機 60%+ | 桌機 50%+（決策者上班看） |
| 設計優先順序 | 先做手機體驗、桌機補空間 | 先做桌機體驗、手機要重新組織 |
| 風險 | 桌機可能顯得「空洞」 | 手機體驗可能淪為「縮小版」 |
我會建議在需求訪談階段就拉出 Google Analytics 數據，看你目標客群實際用什麼裝置造訪同產業競品。沒有數據時，B2C 預設 Mobile First、B2B 預設 Desktop First 但 mobile 至少要做到「不糟糕」。
實務上常看到的反例是「B2B 工業老闆堅持 Mobile First 因為老闆自己常用手機」——但你的客戶（採購、工程師）上班時間 90% 用桌機，這時 Mobile First 反而傷到主流量。比較保險的做法是看數據，不是看老闆習慣。 延伸閱讀 Mobile First Design 完整指南。
決策 3：桌機 hover vs 行動 tap 互動模式
桌機的滑鼠可以 hover（懸停顯示提示、預覽、下拉選單），但手機的觸控沒有 hover 概念——使用者直接 tap 就觸發點擊。這代表所有 hover 才出現的功能，在手機上必須有替代方案：
| 桌機互動 | 手機替代方案 |
|---|---|
| Hover 顯示 tooltip | 點擊後顯示，再點別處關閉 |
| Hover 預覽圖片放大 | 點擊跳出 modal 全螢幕 |
| Hover 下拉選單 | 點擊展開 / 收合 |
| Hover 變色 | 直接顯示色彩、增大 tap target |
建站時要決定的：每個 hover 互動的「手機 fallback」是什麼。沒早期決定，工程師實作時各自為政，網站在手機上會出現「點了沒反應」「按鈕太小點不到」的可用性災難。老闆最常踩的坑是只用桌機驗收，上線後客戶反映「手機按鈕點不到」——這時改一個元件成本還好，但全站幾十個 hover 元件加起來就是 2-3 倍工時。
決策 4：表格與資料密集元件的小螢幕降級策略
表格是 RWD 的最大難題。寬度 1200px 的桌機表格直接縮到 375px 手機，會發生：橫向滾動超出畫面、文字重疊、欄位被擠成 2px。降級策略主要 4 種：
- 橫向滾動：保留表格結構，包進
overflow-x: auto，使用者左右滑動 - 卡片化：手機把每列轉成卡片（標籤 + 值），垂直堆疊
- 隱藏次要欄位：手機只顯示 3-5 個關鍵欄位，其餘藏起來或下拉展開
- 完全重設計：手機版根本不顯示表格，改用「概要 + 詳細頁」結構
建站時要決定的：每個表格採哪種降級。決策依據：欄位數、資料閱讀重要性、互動需求（要排序 / 篩選嗎？）。早期決定後，CMS 後台才能設計對應的「重要欄位」標記功能。
實務上製造業客戶最常碰到這個問題——產品規格表 10-15 個欄位，桌機看清楚但手機完全變糊。我會建議製造業客戶優先考慮「卡片化 + 隱藏次要欄位」組合：手機只露出客戶最在意的 3 個欄位（型號、規格、價格範圍），其餘點開展開——而不是硬塞橫向滾動讓使用者一直滑。
決策 5：字級的 clamp() 彈性系統
傳統 RWD 用 media query 在斷點切換字級（手機 14px、桌機 16px），但斷點之間字級就死板了——999px 還是「桌機字級」、1000px 突然變大，視覺上很突兀。現代解法用 CSS clamp() 函數：
/* H1 字級在 24px 到 48px 之間，根據視窗寬度線性縮放 */
h1 {
font-size: clamp(1.5rem, 4vw + 0.5rem, 3rem);
}
這讓字級隨視窗寬度平滑變化，不再有「突然變大」的視覺斷裂。客製化建站時應建立完整的 clamp() 字級系統（H1-H6 + body + small），整合到 Design Token 中。建站後補做要重寫所有 CSS，工時 = 建站期間的 3 倍。
決策 6：效能差異化（手機載入縮減版資源）
手機網路常常是 4G 甚至 3G，載入桌機等級的資源（大圖、複雜 JS）會讓 LCP 暴炸。客製化建站時應規劃「裝置感知」的資源載入：
- 圖片：
<picture>元素根據螢幕寬度載入不同尺寸（手機載入 480px 寬，桌機載入 1440px 寬） - 影片：手機載入 720p MP4，桌機載入 1080p WebM
- JavaScript：複雜動畫只在桌機啟用（用
matchMedia('(min-width: 769px)')判斷） - 字型：手機只載入英文字 + 必要中文 subset，桌機載入完整字型
- 第三方 widget：聊天機器人、推薦引擎在手機可以延遲載入
這些差異化的優化能讓手機 LCP 從 4-5 秒降到 1.5-2 秒，直接拉高 SEO 與使用者留存。詳見 Core Web Vitals 與 AI 引用 的指標基準。
6 個決策的時程節點
把 6 個決策對應到 客製化網頁設計流程 的階段：
| 決策 | 應該在哪個階段定案 | 延後到下個階段的代價 |
|---|---|---|
| 1. 斷點規劃 | 資訊架構（IA） | 視覺設計返工 1.5x |
| 2. Mobile First vs Desktop First | 需求訪談 | 視覺重畫 2x |
| 3. Hover vs Tap 互動 | 視覺設計（Mockup 階段） | 前端返工 1.5x |
| 4. 表格降級策略 | 視覺設計 | 前端返工 2-3x |
| 5. 字級 clamp 系統 | 視覺設計（Style Guide） | CSS 全站重寫 3x |
| 6. 效能差異化 | 前端開發開始前 | 上線後優化 2-3x |
結語：RWD 是建站期間的決策密度，不是上線後的功能
實務上最常見的 RWD 災難不是「沒做 RWD」，而是「RWD 被當成套版邏輯」——所有元件機械式縮小。真正好的 RWD 是「為每個斷點重新組織內容優先順序」，這需要設計師、工程師、客戶在建站早期就針對 6 個決策對齊。
簽約前可以問開發商這幾個問題：
- 你們的 RWD 設計流程，會在哪個階段討論斷點？
- Mobile First 還是 Desktop First？依據是什麼？
- 表格與圖表的小螢幕降級策略，誰負責決定？
- 字級用 media query 還是 clamp()？
講白一點，如果開發商回答不出這些細節，多半代表他們的 RWD 是「套用框架預設值」而非真正客製。 元伸 24 年的 客製化網頁設計 服務中，這 6 個決策都是需求訪談與視覺設計階段的標準討論項目，企業形象網站方案 的 RWD 從第一張視覺稿就為每個斷點獨立規劃。
📞 03-366-1000 ｜ 🌐 www.ozchamp.com ｜ 免費諮詢，24hr 內回覆
