響應式網頁設計 RWD：手機版網站不漏接任何客戶

其實不少人都這樣：在辦公室用 27 吋大螢幕看自己的網站，覺得版面漂亮、動線順暢，滿意地關掉分頁。直到有一天，你在通勤的捷運上用手機打開同一個網址，才發現字小到要捏著放大、按鈕擠成一團點不準、首頁那張大圖還把整個畫面撐到要左右滑才能看完。

那批在捷運上捏螢幕的人，就是你正在錯過的客戶。響應式網頁設計（Responsive Web Design，業界簡稱 RWD）要解決的，就是這一件事：用同一個網址、同一份內容，讓版面在不同尺寸的螢幕上自動重排。手機就是手機該有的樣子，平板有平板的樣子，桌機回到桌機的樣子，使用者不用縮放、不用橫拉、也不用被轉去另一個手機專屬網址。它不是「有加分的進階功能」，而是 2026 年任何一個商業網站的基本入場券。

這一篇會把 RWD 一次講到底：從 Google 到底怎麼看你網站、Core Web Vitals 怎麼算分，一路到斷點怎麼挑、圖片怎麼塞、觸控目標多大才夠，並延伸到現代 CSS 的 clamp、container queries、電商與無障礙等進階主題，結尾附上一份 WordPress 站長能直接照做的落地路徑與上線前檢查清單。

【重點摘述】30 秒抓重點

• RWD = 一個網址 + 一份 HTML，版面靠 CSS 自動適應，桌機與手機共用同一套內容、同一份 SEO 權重。
• Google 在 2023 年完成 mobile-first indexing 遷移，主要以智慧型手機檢索器看到的內容建立索引。
• 手機版會不會被扣分，主要看 Core Web Vitals 三個指標：LCP（最大元素渲染）、CLS（版面位移）、INP（互動延遲）。
• 換一個主打「響應式」的主題不等於過關，斷點、圖片、觸控目標、字級才是真正決定體驗的地方。
• RWD 的斷點不該照抄 Bootstrap，要以內容開始破版的位置決定，再用實際訪客的裝置資料排定測試優先順序。
• 現代 CSS 的 clamp()、min()、max() 與 container queries 可以讓元件自己根據容器大小變化，不再只看視窗寬度。
• 行動版圖片不只是縮小，art direction 可以在不同斷點給不同的裁切與構圖。
• 電商的篩選器、排序、產品列表在手機上需要重新構想，不是把桌機版縮小了事。

先把三個常被搞混的詞分清楚：RWD、AWD、獨立手機版

「響應式」這三個字被濫用到快要變成「手機看起來正常」的同義詞，但技術上它有明確定義。RWD 是 2010 年 Ethan Marcotte 在 A List Apart 發表的〈Responsive Web Design〉提出的概念，核心是三件事湊在一起：流動格線（fluid grid）、可縮放媒體（flexible media）、媒體查詢（media queries）。換句話說，就是同一份 HTML，讓 CSS 依照螢幕寬度去重新編排版面。

問題是很多人會把 RWD、AWD、獨立手機版這三種做法搞混，決策的時候就走錯路。用一張表把差異攤開：

做法	網址結構	HTML 內容	維護成本	SEO 友善度
RWD 響應式	單一網址	桌機手機同一份	低（改一次）	高，設定最簡單
AWD 適應式	單一網址	伺服器依裝置回傳不同 HTML	中（兩套邏輯）	可行，需正確設定 Vary 標頭並維持內容一致
獨立手機版（m. 子網域）	example.com + m.example.com	兩份各自獨立	高（兩個站）	可行，需處理 alternate/canonical 與重新導向

結論很直白：對多數中小型網站，RWD 是 CP 值最高的選擇，一份內容改到底、一個網址集中訊號，也不需要處理跨裝置網址的 canonical 與重新導向；頁面本身仍建議使用指向自己的 self-canonical。AWD 不是不能用，但只有在需求足以承擔裝置偵測與維護複雜度時才值得採用；獨立手機版在 2026 年則已很少是新網站的首選。需要做架構決策時，可以對照著看 AWD vs RWD 完整比較。

手機流量早就超過桌機，而你還在用桌機思維做網站

根據 Statista 的統計（2026 年 4 月），全球行動版網頁流量在過去幾年長期市佔最高，這個數字每一季都在震盪，但行動裝置一直是不可忽視的主要入口。在台灣，捷運上、餐桌旁、睡前的使用情境也經常發生在手機上。你的網站在桌機上多漂亮，這群人仍只會看到行動版體驗。

更關鍵的是，手機常被用在時間短、干擾多的情境。只要首屏遲遲沒有給出使用者要的答案，他就可能按下返回鍵回到搜尋結果，去找下一個選項。這也是為什麼行動版的版面必須更狠心地剪掉裝飾、把重點往首屏推，別把桌機版的所有東西原封不動塞進去。

問題在於，很多站長的「滿意」是建立在桌機預覽上的。設計師交稿你看的是筆電、老闆驗收看的是辦公室螢幕，真正掏錢的客戶卻可能在手機上很快決定要不要留下。行動版體驗一差，跳出率（bounce rate）與參與率會提供線索；在 GA4 裡，跳出率是「未達參與工作階段條件的工作階段比例」，不是單純的「只看一頁就離開」（見 Google Analytics 的參與率與跳出率說明）。如果你還沒在追蹤這條線，可以先看 跳出率與 SEO 的關係。

換個方式想：你開了一家裝潢精美的實體店，卻把大門做得窄到客人得側身才能擠進來。RWD 就是那道「把門做到任何人都能走進來」的工程。它不是為了讓網站變酷，而是為了不漏接任何一位已經走到門口的客戶。

Google 用「手機版」決定你的排名：mobile-first indexing 的真實影響

很多站長以為「手機版比較醜沒關係，反正桌機版漂亮就好」，這個假設在 2026 年是錯的，而且錯得很貴。Google 在 2023 年的 Mobile-first is here 公告正式宣布 mobile-first indexing 已經全面到位，白話文是：Google 主要使用智慧型手機檢索器看到的內容建立索引與評估排名。如果桌機版有主要內容、手機版卻沒有，Google 能用來理解頁面的資訊就會變少（見 Google 的 mobile-first indexing 最佳實務）。

這件事對 RWD 的設計決策有幾個直接影響，列幾個最容易被輕忽的：

• 手機版不能缺少桌機版的主要內容。為了節省空間，把已存在 HTML 裡的內容收進 accordion 或 tab 沒問題；但若內容被手機版模板刪除，或必須點擊後才從伺服器載入，Googlebot 可能拿不到。重點是讓手機與桌機的主要內容相等，而不是禁止所有視覺上的收合。
• 結構化資料、內部連結、標題層級，手機版必須完整。桌機版有 schema、有導覽列、有完整的 H2 層級，手機版只剩一層薄薄的頁面，等於自己把 SEO 彈藥庫丟掉一半。
• 行動裝置友善仍是重要的頁面體驗原則。不過 Google 早在 2016 年就移除搜尋結果中的「適合行動裝置」標籤，Search Console 的「行動裝置可用性」報告與 Mobile-Friendly Test 也已於 2023 年 12 月退役；現在應以 Lighthouse、瀏覽器開發工具與實機測試檢查（見 Google 對頁面體驗角色的說明）。

實務上要確認這件事，最快的方法是直接看 Googlebot 看到的版本。在 GSC 的「網址審查」輸入頁面網址，按「測試實際網址」，再開啟「查看測試的網頁」，就能查看 Google-InspectionTool 取得的轉譯後 HTML、畫面截圖與載入資源（見 Google Search Console 的 URL Inspection tool 說明）。如果你發現渲染結果缺少重要標題、結構化資料或內部連結，那就是你「以為有、其實 Google 沒看到」的內容。這項檢查適合在重要版型改動後執行。

本質上來說，mobile-first indexing 把「手機版是附屬品」這個老觀念整個翻過來：Google 主要依據手機檢索器取得的內容建立索引，但這不代表桌機版被指定成重複頁或副本。你在做任何 RWD 決策時，都應該先問「手機上看起來如何」這個問題，同時確保桌機與手機都提供完整體驗。

RWD 跟 Core Web Vitals 是同一件事的兩面

「我的網站是響應式的啊，為什麼 Google Search Console 還是給我紅字？」這是 RWD 裡最常被問到的問題之一。實務上最常碰到的劇本幾乎一模一樣：站長以為換了響應式主題就過關，打開 GSC 的 Core Web Vitals 報告才發現行動版長期紅字，而桌機版反而一切正常。響應式跟「手機版跑得快、用起來順」是兩個獨立的維度，前者管版面，後者管體驗指標。

Google 用 Core Web Vitals 這一組指標來量化「使用者體驗」這件抽象的事，而速度本身會直接影響使用者的去留（見 web.dev 的〈Why does speed matter?〉）。三個核心指標，翻譯成 RWD 決策語言：

指標	它在量什麼	RWD 上常見的扣分原因	修正方向
LCP 最大元素渲染	主要內容算「載完」的時間	手機版首圖太大、沒設 width/height、被 CSS 延後載入	響應式圖片 srcset、明確尺寸、移除首屏 render-blocking
CLS 累計版面位移	版面在載入過程跳動的程度	圖片無尺寸、廣告或字型載入後把內容往下推	所有媒體都給固定長寬比、預留 placeholder
INP 互動延遲	使用者點了之後頁面多久才有反應	手機版掛太多 JS、第三方追蹤、動畫卡主執行緒	延遲載入非必要腳本、用 CSS 動畫取代 JS

這三個指標常會在手機上暴露得更明顯，因為部分手機的處理能力與網路條件不如開發用筆電。桌機版綠燈仍有參考價值，但不能替代行動版資料；除了在桌機模擬，也應拿實際手機、在常見的行動網路條件下測試。Core Web Vitals 與排名的完整對應，可以看 Core Web Vitals 與 SEO，這裡就不重複展開。

順帶一提，INP 於 2024 年 3 月 12 日正式取代舊指標 FID（首次輸入延遲），成為 Core Web Vitals 的一員，變更細節見 web.dev 的公告。它會觀察頁面生命週期內的點擊、輕觸與鍵盤互動，並以最慢或接近最慢的互動代表整體反應性，而不只是測第一次輸入（見 web.dev 的 INP 文件）。這代表不能只優化首屏那一兩個互動；手機版反應遲緩的選單、彈窗與篩選器，都可能影響 INP。

響應式版面的三層骨架：Viewport、流動格線、媒體查詢

回到實作。RWD 的技術骨架只有三層，把它們搞懂，後面任何主題、任何頁面編輯器你都能看懂它在幫你做什麼。

第一層：Viewport meta tag

每一個 RWD 網站的 HTML <head> 裡都該有這一行：

<meta name="viewport" content="width=device-width, initial-scale=1">

沒有這一行，手機瀏覽器會把你的網站當成桌機版直接縮小塞進螢幕，使用者就會看到那個經典的「整頁縮到看不清楚、要捏捏放大」的畫面。這是 RWD 的開關，少一行就全毀。絕大多數現代主題都會自動加上，但你自己刻 HTML 的時候別忘了。

viewport 這一行還有兩個常被略過的細節。width=device-width 告訴瀏覽器「讓版面 viewport 寬度配合裝置寬度」；initial-scale=1 則是「進站時使用 1:1 的初始縮放比例」。有些舊教學會加上 user-scalable=no 禁止使用者縮放，這在 2026 年是被視為無障礙反模式的做法，因為它剝奪了視力不佳使用者放大網頁的權利。除非你有非常明確的理由，否則不要關掉縮放功能。

第二層：流動格線與相對單位

傳統網站用像素（px）寫死寬度，.container { width: 1200px; } 在桌機完美、在 375px 寬的手機上就會爆出去。RWD 改用相對單位：百分比、fr、vw/vh，以及現代 CSS 的 clamp()、min()、max() 函式。例如字級可以用 font-size: clamp(1rem, 2.5vw, 1.5rem)，讓它在手機跟桌機之間平滑放大，不會出現某個斷點瞬間跳字的尷尬。

同樣的邏輯也用在容器寬度上。與其寫死 max-width: 1200px，不如寫 max-width: 90ch（以字元寬度為單位，閱讀最舒服的行寬大約是 45 到 75 個字元），讓版面跟著字體大小自動伸縮。再搭配 box-sizing: border-box，padding 與 border 就不會把元素撐超過你設定的寬度，手機上那種「明明設了 100% 卻還是橫向溢出」的鬼問題就會消失。

流動格線的基礎是 CSS box model，搞懂 padding、border、margin 怎麼疊加，你才知道為什麼手機版寬度算起來老是差一點點。這部分的底層觀念整理在 CSS Box Model 完整指南，搭配 box-sizing: border-box 服用，可以少踩很多雷。如果 padding、margin 這些名詞對你還很模糊，先回頭把CSS 基本功補穩，再回來看流動格線與相對單位，思路會順很多。

第三層：媒體查詢，以及正在接班的 container queries

媒體查詢（media query）是 RWD 的「如果就」機制：@media (max-width: 768px) 代表「當 viewport 寬度不超過 768px 時，套用這組規則」。斷點就是這個數字。

但它有一個根本限制：媒體查詢看的是「視窗大小」，不是「元件所在容器的大小」。於是同一個卡片元件放在寬版側邊欄跟窄版內文裡，會得到一樣的版面，看起來就很怪。container queries 就是為了解決這個問題而出現的新規格，它讓元件可以根據「自己被放在多大的容器裡」來變換樣式（見 MDN 對 @container 的說明）。2026 年主流瀏覽器都已經支援，你設計可重用的卡片、側邊欄、產品區塊時，container queries 會比 media queries 更精準。

舉個最直觀的例子。一張產品卡片，用 media query 你只能寫「視窗小於 768px 時變成單欄」；但同一張卡片可能被放在寬 300px 的側邊欄、也可能被放在寬 800px 的內文區，這兩種情況視窗大小一樣、卡片需要的版面卻完全不同。container query 讓你改寫成「當容器寬度小於 400px 時變單欄」，判斷依據變成卡片自己的容器，不再看整個視窗，元件才真正能跨頁面重複使用而不破版。

現代 CSS 的流動數學：clamp、min、max 與 Grid 自動欄位

了解了三層骨架，再往下一層是現代 CSS 提供的數學函式與 Grid 自動排版。它們讓響應式設計不再只是「寫死斷點再覆蓋」，而是讓數值在一個範圍內流動，能大幅減少斷點數量。

clamp(min, preferred, max) 會回傳一個「不小於 min、不大於 max、儘可能接近 preferred」的值（MDN 的 clamp() 條目）。把它用在字級或間距上，例如 font-size: clamp(1rem, 2.5vw + 1rem, 2rem)、margin: clamp(1rem, 5vw, 3rem)，數值就會在螢幕尺寸之間平滑變化，不會在某個寬度瞬間跳動。對於那些「中間有很多奇怪螢幕尺寸」的情況（例如各種折疊裝置、介於手機與平板之間的機型），流動數學比固定斷點穩健得多。

min() 與 max() 則適合用在「不能超過、也不能低於特定尺寸」的情況。width: min(90%, 1200px) 取兩者較小的值，自然產生最大寬限制；padding: max(1rem, 2vw) 保證間距至少 1rem，螢幕夠大時才放大。這種寫法比傳統「設 max-width 再補一個 media query」簡潔，維護時不用追蹤一堆斷點。

來到 CSS Grid，repeat(auto-fit, minmax(250px, 1fr)) 這一行是自動欄位的魔法。每欄最小 250px、最大均分剩餘空間，視窗縮小時欄位自動換行，完全不需要 media query，特別適合產品列表、文章卡片、相簿這類重複元件。auto-fit 與 auto-fill 的關鍵差別在於：auto-fill 會保留空的欄位佔位，auto-fit 則會把空的欄位收掉，讓剩下的欄位變寬來填滿空間（見 MDN 對 repeat() 的說明）。實務上 auto-fit 更符合「讓卡片填滿那一行」的需求，auto-fill 則適合你想保留固定欄寬、不接受被拉伸的情況。

2026 年主流瀏覽器也已支援 subgrid（見 Can I use 的 CSS Subgrid 資料），讓嵌套的 Grid 可以對齊父 Grid 的欄線。對於「一張卡片內部又需要格子排版」的複雜版面特別有用，不用再為每個卡片獨立算一次欄寬，整個列表的標題、價格、按鈕能跨卡片對齊。

Flexbox 端，flex: 1 是 flex-grow: 1; flex-shrink: 1; flex-basis: 0% 的簡寫，代表平均分配剩餘空間。響應式常見的模式是「小螢幕全寬、大螢幕只佔一部分」：手機用 flex-basis: 100%（單欄），桌機改成 flex-basis: 48%（兩欄，留 4% 間距）。這比傳統用百分比配 float 簡潔，而且 Flexbox 自動處理垂直對齊，省下算 margin 的功夫。

斷點不是抄來的：讓內容與數據一起決定

這是整篇文章最想講、也最容易被一般教學跳過的一段。打開任何一篇 RWD 教學，幾乎都會給你一套現成斷點：576 / 768 / 992 / 1200px（Bootstrap 風格），或 640 / 768 / 1024 / 1280px（Tailwind 風格）。這些數字沒有錯，但它們是框架作者的通用假設，不是你網站的真實狀況。

不同網站的訪客可能使用不同的裝置組合，但斷點不應直接綁定特定機型。先看內容在哪個寬度開始擁擠、溢出或失去可讀性，再用實際訪客的裝置資料決定哪些尺寸優先測試，才不會拿別人的尺量自己的版面。

正確的做法是從內容本身找斷點，再用分析資料排定測試優先順序：

1. 在 Chrome DevTools 的裝置模式中連續拖曳 viewport，記下版面開始擠、溢出或閱讀困難的寬度。
2. 到 GA4 的「技術總覽／技術詳細資料」查看裝置類別、裝置型號與螢幕解析度；GSC「成效」報告只能依 desktop、mobile、tablet 裝置類別篩選，不能提供實際螢幕寬度。
3. 用實機或 DevTools 優先測試流量較高的裝置類型，同時補測資料裡沒有、但版面可能出問題的中間寬度。
4. 把內容發生明顯變化的寬度設成屬於你網站的斷點，不要把分析工具列出的每個裝置寬度都變成一條 media query。

GSC 的「成效」報告仍適合比較不同裝置類別的搜尋表現，如果你還沒上手，可以先看 Google Search Console 操作指南。設計端建議在 Figma 裡先開好這幾個關鍵寬度的 frame，把每一個斷點都當成獨立畫面來設計，避免畫完桌機稿才「縮小成手機」。關於這套設計流程，可以參考 Figma 響應式設計實務。

另一個要決定的是斷點的方向：min-width（手機優先，從小到大往上加規則）還是 max-width（桌機優先，從大到小往下覆蓋）。在 mobile-first 的時代，強烈建議手機優先。先把手機版寫好，再用 min-width 往桌機加東西，這跟你網站被索引的主版本一致，也強迫你先顧好最受限的那個版面。

手指才是真正的滑鼠：行動版 UX 的硬底線

RWD 不是把版面縮小就好。手機的輸入裝置是手指，不是滑鼠，這件事改寫了所有互動元件的設計底線。列四個最常出問題、也最好修的地方。

觸控目標以 44×44 px 為實務目標

Apple 的 Human Interface Guidelines 建議按鈕的 hit region 至少為 44×44 pt。WCAG 2.2 的 2.5.5「Target Size (Enhanced)」也採 44×44 CSS pixels，但它是 AAA 等級；AA 等級的 2.5.8「Target Size (Minimum)」則要求至少 24×24 CSS pixels，或符合間距等例外（WCAG 2.2 的 Target Size (Enhanced)、Target Size (Minimum)）。成年人的食指指腹寬度約 10 到 14 mm（LukeW 的 Touch Target Sizes），因此重要操作採較大的目標並拉開間距，通常更容易準確點擊。

很多設計師為了「精緻」，把按鈕做到 32px、把導覽列的連結擠在一起。視覺上乾淨，手指上災難。修正方式很簡單：用 padding 把觸控區撐大，視覺尺寸可以不變，但實際可點擊範圍要夠。

表單控制項字級避免小於 16px

這是一個很少被講、卻很傷的細節。iOS Safari 預設會在表單輸入框 font-size 小於 16px 時自動放大整個頁面，方便使用者輸入（見 CSS-Tricks 的說明）。結果就是使用者一點進搜尋框或表單，畫面突然 zoom in、輸入完又 zoom out，整個體驗在跳動。解法就是把所有輸入框字級設到至少 16px，這個惱人的自動縮放就會消失。不要用 maximum-scale=1 或 user-scalable=no 來硬關縮放，那是無障礙反模式。

字級之外，行高與行寬也直接影響手機閱讀的疲勞程度。行高可從 1.5 左右開始測試，讓中文字之間有足夠的呼吸空間；WCAG 對可調整文字間距的測試包含 1.5 倍行高，而 CJK 文字每行不超過 40 字是可及性上限，不等同所有版面的唯一理想值；一般英數內文則常以 50 到 75 字元作為閱讀性參考（Baymard Institute 的研究）。行寬過長時，讀者換行較難找到下一行的起點。手機版應保留適當留白，也要避免文字貼齊螢幕兩側。

留白與拇指熱區

手機上的點擊大多集中在螢幕下半部，那是單手握持時拇指搆得到的「拇指熱區」（thumb zone），這個概念最早由研究人員 Steven Hoober 在觀察手機握姿時提出，發表於 A List Apart。把主要行動按鈕（加入購物車、送出表單、聯絡我們）放在下半部、再把按鈕之間的垂直留白拉開，點擊率與完成率通常會比擠在一起的版本好。字級、行高、留白怎麼系統性地拿捏，可以搭配 字體與排版設計要點 一起看。

動態效果要尊重使用者的偏好

還有一個常被低估的底線，是動畫與自動播放。有些人對動態效果特別敏感，前庭功能失調或偏頭痛的患者看到大量視差滾動、自動輪播、入場動畫會明顯不舒服。CSS 提供 @media (prefers-reduced-motion: reduce) 這個媒體查詢，作業系統一旦偵測到使用者開啟「減少動態效果」的設定，你的網站就該自動收斂非必要的動畫。這不只是無障礙的加分題，而是 2026 年一個有質感的網站該有的基本禮貌，也跟 Apple HIG、WCAG 一致重視使用者舒適度的方向相通。

行動版字級系統：流動排版與模組化尺度

手機上的閱讀體驗，字級與間距的系統性設計比單一數字重要。一套好的字級系統應該滿足三個條件：各斷點下都舒適、字級之間有明確的階層關係、維護時不用手動調每個斷點。

流動字級（fluid typography）的核心想法是：不要為每個斷點寫死字級，而是用 clamp() 讓字級在螢幕尺寸之間流動。例如 H1 用 clamp(1.8rem, 4vw + 1rem, 3rem)、內文用 clamp(1rem, 1.5vw + 0.9rem, 1.25rem)。前一個寫法代表標題不會小於 1.8rem、也不會大於 3rem，中間依 preferred 值平滑流動，不必為每個標題寫「手機多少、平板多少、桌機多少」。

模組化尺度（modular scale）則讓字級之間保持固定比例，而不是隨意挑數字。用 1.25 當比例，以內文 16px 為基準往上推：H3 約 20px、H2 約 25px、H1 約 31px。視覺上和諧，要整體縮放時（例如手機版全部縮小 10%）只要改基準值，所有標題會按比例一起調整，不會出現「H1 縮了但 H3 忘記縮」的破綻。實作上用 CSS 變數定義基準與比例，h1 用 calc(var(--font-base) * var(--ratio) * var(--ratio) * var(--ratio)) 算出來，維護時只改 --ratio 或 --font-base，整個字級階層自動跟著變。

WordPress 站長的 RWD 落地路徑

講完原理，來談絕大多數讀者真正會走的路。WordPress 到 2026 年仍佔全球網站超過四成的市佔（W3Techs 的統計，2026 年 6 月），意味著你很可能是用 WordPress 架站。好消息是，WordPress 生態系已經把 RWD 的門檻降到很低；壞消息是，門檻低不代表一定做對。落地路徑拆成三個層次。

主題層：挑一個原生響應式的主題

2026 年還在賣的主流主題，Astra、Blocksy、Kadence、GeneratePress，幾乎沒有一個不標榜響應式。但「標榜」不等於「每個細節都做好」。挑主題時，實際拿手機開它的 demo 站，看選單怎麼收合、表單怎麼排版、圖片怎麼縮放，別只看桌機截圖。一份完整的主題與頁面編輯器比較，可以參考 最佳頁面編輯器比較 裡的 RWD 段落。

頁面編輯器層：搞懂行動版的獨立控制項

Elementor、Divi、Bricks 這類頁面編輯器，都給你「桌機、平板、手機」三個裝置的獨立設定：欄數、字級、間距、邊界，都可以針對手機單獨調。很多人只調桌機，手機就用預設值，結果桌機排得很美、手機全擠成一坨。

一個特別值得學的功能是行動版的版面順序翻轉。桌機上你把「主圖片」放左邊、「文字」放右邊，縮到手機變成上下堆疊時，順序會變成「圖片在上、文字在下」。但如果你希望手機版先看到文字再看到圖，就要在編輯器裡指定手機版的欄位順序。Divi 在這塊的操作整理在 Divi 行動版版面順序，照著做可以省掉不少 trial and error。

圖片層：響應式圖片是 RWD 的隱形戰場

圖片是手機版 LCP 與流量的最大兇手。RWD 的圖片優化有三個層次：檔案尺寸、格式、art direction。

第一層是 srcset 與 sizes。srcset 提供不同寬度的圖片候選，瀏覽器會依版面顯示尺寸、裝置像素比與自身的資源選擇邏輯挑選合適檔案：

<img srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1200w" sizes="(max-width: 600px) 100vw, 50vw" src="medium.jpg">

關鍵是 sizes 屬性，它告訴瀏覽器「這張圖在版面上會佔多寬」，瀏覽器根據這個資訊挑最接近的檔案。沒有 sizes，瀏覽器會假設圖片佔 100vw，可能會挑一個太大的檔案。WordPress 從 4.4 版起就會自動為上傳的圖片產生多種尺寸，並在輸出 img 標籤時補上 srcset 與 sizes，5.5 版起又加入原生 lazy load。多數佈景也會自動補上 width/height，但你如果是用自訂 HTML 或舊外掛塞的圖，就要自己檢查。

第二層是 WebP 與 AVIF 格式。新一代圖片格式在相同畫質下檔案小得多：WebP 比 JPEG 小約 25 到 34%，AVIF 更可再縮小到將近 JPG 的一半（見 Cloudinary 的格式比較）。2026 年 Chrome、Safari、Firefox、Edge 都已原生支援這兩種格式（Can I use 的 WebP、AVIF 資料），實作上用 <picture> 標籤提供降級：

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

瀏覽器從上往下找，支援 AVIF 就用 AVIF，不支援就試 WebP，再降級到 JPG。享受新格式的小檔案，同時對舊瀏覽器友善。每一張圖也都要給 width 與 height，瀏覽器才能在下載完之前先預留位置、避免 CLS；首屏以外的圖加上 loading="lazy"，不載入使用者還沒滑到的圖。圖片優化的完整流程，可以延伸看 圖片 SEO 優化。

第三層是 art direction（藝術導向）。同一張圖，在手機與桌機上可能需要不同的「構圖」，而不只是不同的「尺寸」。例如一張產品圖，桌機版左邊是產品、右邊是文案（橫式），手機版要讓產品佔滿畫面、文案往下方推（直式）。如果你只是把同一張圖縮小，手機上的產品會變得很小、看不清細節。Art direction 的做法是準備兩張不同裁切，用 <picture> 搭配 media 屬性切換：

<picture>
  <source media="(min-width: 768px)" srcset="product-desktop.jpg">
  <source srcset="product-mobile.jpg">
  <img src="product-mobile.jpg" alt="...">
</picture>

對人像、團隊照片、情境圖特別重要。這不是技術問題，而是設計決策：你願不願意為不同螢幕尺寸準備不同的裁切。

手機版的導覽與選單：漢堡選單不是唯一答案

漢堡選單能解決手機空間不足，但把導覽收起來也可能降低部分項目的可見性。是否影響點擊或轉換取決於網站、標籤與受眾，不能把個別 A/B 測試當成通則；可將少數高價值入口保留在畫面上，再用手機選單收納次要項目，並以本站資料驗證。

這不代表漢堡選單不能用，而是你不該把所有東西無腦丟進去。分層處理比較健康：

• 最重要的少數分類（例如電商的「新品」「折扣」「全部分類」、內容站的「熱門」「完整指南」），可以直接露在頂部，讓使用者隨時點得到；實際數量要依 viewport 與標籤長度測試。
• 次要的頁面（關於我們、常見問題、服務條款、隱私權政策）才收進漢堡選單，使用者需要時找得到就好，不必佔走首屏。
• 搜尋功能的優先級要拉高。手機上選單被收合之後，搜尋常常變成使用者找東西的主要路徑，把搜尋圖示放在頂部最顯眼的位置，別讓它埋進漢堡裡的第二層。

要不要用 sticky header（固定在頂部的導覽列）也是一個權衡。它的好處是使用者隨時能切頁，壞處是會吃掉手機上寸土寸金的首屏高度。折衷做法是讓 sticky header 在使用者往下滑時自動收起、往上滑時再出現，這樣既保留切換能力、又不擋內容。整體的版面規劃邏輯，可以對照 網站版面配置指南 與 網站版面配置範例 一起思考。

表單與結帳：行動版轉換的最後一哩

如果說選單決定使用者能不能「找到」，表單與結帳就決定他們能不能「完成」。在桌機上輸入資料很輕鬆，在手機上每一個欄位都是摩擦。行動版表單的每一個多餘欄位、每一個選錯的鍵盤、每一次要手動打的地址，都在把已經走到門口的客戶往外推。幾個硬性要求的事：

• 用對的 input type，讓對的鍵盤跳出來。電話欄位用 <input type="tel"> 會召出數字鍵盤，email 欄位用 type="email" 會召出帶 @ 與 . 的鍵盤。少做這一步，使用者就要在那個小小的英文鍵盤上切來切去找符號，摩擦感立刻翻倍。
• 開啟 autocomplete。在姓名、email、地址、電話、信用卡欄位加上對應的 autocomplete 屬性（例如 autocomplete="shipping postal-code"），瀏覽器就能幫使用者帶入已經存好的資料，減少手動輸入。
• 單欄由上到下。手機上多欄表單會逼著使用者的眼睛和拇指上下跳動，單欄由上到下最順，每往下滾一格就是下一個欄位，心智負擔最低。
• 電商一定要開放訪客結帳（guest checkout）。強制註冊才能結帳，是公認的結帳放棄主因之一，研究調查常把它列進前幾大原因（見 Baymard Institute 的結帳放棄統計）。讓人先用訪客身份買完，再在結帳完成頁溫柔地問一句「要不要順便開個帳號」，轉換率會健康得多。
• 送出按鈕要容易點到。讓送出鈕的可點擊區符合前述觸控目標建議；必要時可固定在底部，但要避免遮住欄位、錯誤訊息或系統安全區。

電商網站的行動版特殊考量

電商網站的 RWD 比一般內容站複雜，因為使用者要完成的不是「滑完文章」，而是「找產品、篩選、加購物車、結帳」。每一個步驟在手機上都有不同的摩擦。

產品列表與篩選器

桌機電商的典型版面是：左側篩選器（價格區間、品牌、尺寸）、右側產品列表。直接縮到手機上會有兩個問題：篩選器佔掉整個版面、產品列表被擠得很窄。手機版的常見解法是把篩選器收成一個按鈕，點一下從側邊滑出，選完關掉回到列表；已選的篩選條件做成標籤（tags）顯示在頂部，讓使用者隨時知道自己設了哪些條件、也能點標籤快速取消；排序方式（價格高低、評分高低）放在頂部 sticky，方便隨時切換。

產品卡片在手機上要狠心做資訊密度的取捨。必備的是產品名、價格、主圖；評分（星號數量）、折扣標籤是重要；庫存狀態只在售完時顯示「補貨中」就好。把不重要的資訊藏到「點進產品頁」再顯示，手機版的產品卡片才能保持清爽、易於滑動。

購物車、結帳流程與地址輸入

桌機上使用者可以邊看產品邊改數量、邊看運費計算，手機上螢幕小，流程多一步就多一層摩擦。手機版購物車建議：購物車圖示持續顯示件數；若能提前計算運費，就在購物車頁讓使用者輸入必要資訊查看估算，不要拖到結帳最後才揭露；若系統支援多組優惠碼，讓使用者逐一套用並清楚列出已生效的代碼。

結帳流程在手機上最容易出問題的是表單長度。多步（multi-step）與單頁結帳沒有一種必然較好；重點是只問必要欄位、清楚顯示進度與錯誤，並避免要求重複輸入。若採多步流程，可以依聯絡資訊、配送地址、付款方式、確認送出分組，讓每一步的任務清楚。

地址輸入在手機上是最痛的之一。台灣的 3+3 碼郵遞區號有明確編碼規則：前 3 碼是行政區編號，後 3 碼是投遞區段碼（見 中華郵政的郵遞區號查詢）。後 3 碼不能用來「帶出鄉鎮」；比較可靠的做法是依使用者選取或輸入的完整地址查出 3+3 郵遞區號，或以地址自動完成服務提供建議。再搭配記住常用地址，能減少結帳輸入負擔。如果你跑的是 WooCommerce 電商，Elementor 響應式電商設計 裡有針對商品頁與結帳流程的手機版調整示範，可以直接套用到自己的站。

無障礙與 RWD 的重疊：視覺檢查之外還要聽

很多站長以為「手機看起來正常」就代表 RWD 做好了，但無障礙使用者會告訴你另一個故事。螢幕閱讀器使用者、鍵盤使用者、視力不佳的使用者，他們在手機上體驗到的網站，跟你看到的不一樣。

手機上最常見的螢幕閱讀器是 iOS 的 VoiceOver 與 Android 的 TalkBack。RWD 在螢幕閱讀器上常見的問題有三個：漢堡選單只是個 <div> 或 <button>，沒有 aria-label="選單"，螢幕閱讀器只會讀成「按鈕」，使用者不知道點下去會發生什麼；手機版用 display:none 藏掉的內容，對螢幕閱讀器來說也讀不到；桌機上可以用 CSS 把順序改成「圖左文右」，但螢幕閱讀器讀的是 DOM 原始順序，可能跟你以為的順序完全不同。最快的確認方法是在 iPhone 上開 VoiceOver、戴耳機聽一次你的網站，會聽到很多「看不到但聽得到」的問題。

鍵盤與觸控的無障礙也要顧。有些使用者因為行動不便或個人偏好，在手機上用外接鍵盤操作。要確保所有互動元件都鍵盤可達（不能用只有滑鼠 hover 才會出現的選單）、focus 狀態清楚可見（鍵盤使用者靠「目前焦點在哪裡」判斷位置）、Tab 順序符合視覺順序（由左到右、由上到下，不要亂跳）。這些檢查在桌機上做、在手機上也要再做一次，因為很多斷點切換後 tabindex 或 DOM 順序可能會出問題。

色彩對比是另一條底線。手機螢幕在戶外或強光下可讀性會打折扣，這時候如果對比不足（例如淺灰字放在白底上），視力不佳的使用者會很難閱讀。WCAG 2.2 AA 標準要求一般文字與背景的對比至少 4.5:1、大字至少 3:1；辨識 UI 元件與有意義圖形所需的視覺資訊，則須與相鄰顏色達到至少 3:1（WCAG 2.2 的 Contrast (Minimum) 與 Non-text Contrast）。可以在設計階段用線上工具（例如 WebAIM Contrast Checker）檢查每一個文字顏色組合，而不是等上線後被使用者回報。動態效果同樣要配合 @media (prefers-reduced-motion: reduce) 收斂。

RWD 體檢裡最常見的六個錯

從各種網站的實際情況來看，RWD 的問題重複率極高。把最常見的六個整理成表，每一個都附上怎麼發現、怎麼修。這些是在各種網站上反覆出現的通則。

錯誤	它會造成的現象	修正方式
漏掉 viewport meta tag	手機上整頁縮小，使用者要捏捏放大	在 head 加上 width=device-width, initial-scale=1
手機版模板刪掉主要內容	Google 手機檢索器取得的資訊不完整	維持桌機與手機主要內容相等；可用已存在 HTML 的摺疊元件節省空間
圖片沒設 width/height	CLS 飆高、版面載入時不斷跳動	所有 img 補上明確尺寸或 aspect-ratio
斷點照抄框架、沒看自家數據	某幾個寬度版面破版、沒人發現	依內容破版處設斷點，再用 GA4 裝置資料排定實測優先順序
重要觸控目標過小或彼此太近	較難準確點擊、容易誤觸	以 44×44px 為實務目標，至少符合 WCAG 2.2 AA 的尺寸或間距規則
只調桌機、手機用預設值	桌機漂亮、手機全擠成一團	頁面編輯器逐裝置調欄數、字級、間距

這六個錯的共同點是：只看單一桌機預覽很容易漏掉。用 DevTools 連續調整 viewport、拿實際手機操作，再用 PageSpeed Insights 檢查效能，才比較容易讓問題現形。更多網頁設計常見的地雷整理在 網頁設計常見錯誤，可以一起對照著健檢。

回過頭，要反覆強調一件事：RWD 不是交案那一刻的事，而是上線之後持續的維護。新增一個頁面、換一張首圖、裝一個新外掛，都可能把原本沒問題的行動版弄壞。把後面那套測試工具鏈變成你改版的固定流程，比追求一次性的完美版面更有價值。

RWD 該怎麼測？一套從免費到實機的工具鏈

前面一直強調「要實際測」，但到底用什麼測？把一套從快到慢、從合成到真實的工具鏈列出來，全部免費：

工具	它給你什麼	資料類型
Chrome DevTools 裝置模式	拖曳寬度即時看版面、模擬特定手機	視覺檢查（非數據）
Lighthouse（DevTools 內建）	LCP、CLS、TBT 等實驗室指標與逐項建議；Lighthouse 不會直接量到 INP	實驗室數據（lab data）
PageSpeed Insights	提供 Lighthouse lab 數據；有足夠 CrUX 資料時也顯示真實使用者的 LCP、CLS、INP	lab + field（CrUX）
Google Search Console	你網站長期累積的行動版體驗報告	field data（來自真實訪客）

這裡有一個關鍵觀念要分清楚：lab data 跟 field data 回答的問題不同。lab data 是 Lighthouse 在合成的網路與 CPU 條件下跑出的結果，可重複、適合 debug；但 Lighthouse 載入頁面時沒有真實互動，因此不能直接量測 INP，只能用 TBT 當實驗室代理指標。field data 來自 Chrome 真實使用者的 Chrome UX Report（簡稱 CrUX），反映一段時間內的實際體驗，也是 Google Core Web Vitals 報告使用的資料來源。Lighthouse 的 Performance 分數不是搜尋排名分數；除了用它找問題，也要到 PageSpeed Insights 與 GSC 查看有資料時的 field 指標。完整的測速工具操作，可以看 網站速度測試。

站長規模一變大，手動測試就不夠用，這時可以加自動化的視覺回歸測試（visual regression testing）。原理是：每次改版後，自動在各個斷點（例如 375、768、1024、1440px）截圖，跟之前的 baseline 比對，有像素差異就標出來讓你判斷是預期的變化還是意外破版。BackstopJS（開源、可客製）、Percy（雲端、整合 CI/CD）、Chromatic（元件層級）都是常見選擇。把它接進 GitHub Actions 之類的 CI，每次 push 程式碼就自動跑一次，有助於提早發現「桌機改 A、手機壞 B」的回歸。要注意視覺測試會有假陽性（例如換了一張圖也算差異），這時要能標示「接受這個差異」並更新 baseline。

工具再強，都取代不了實體手機。優先選擇分析資料中常見、且效能不特別高的裝置，定期在實際行動網路下開啟網站。DevTools 的裝置模式主要模擬 viewport、觸控與節流條件，不等於該手機的真實硬體；實機測試更容易發現裝置特有或效能相關的問題。

2026 年的 RWD：折疊裝置與 AI 搜尋的新課題

RWD 不是一成不變的技術。2026 年有兩個趨勢正在改變「響應式」的定義：折疊裝置與 AI 搜尋結果。

折疊手機（例如 Samsung Galaxy Z Fold 系列）到 2026 年已有多款產品。這類裝置的 viewport 可能在折疊與展開時大幅改變，版面也可能從單欄轉成接近平板的配置。RWD 在這類裝置上要考慮：viewport 改變後是否仍可讀，以及在具有實體鉸鏈、且瀏覽器把畫面分成多個 viewport segment 時，關鍵互動是否落在縫隙。CSS 的 @media (horizontal-viewport-segments: 2) 可以偵測兩個並排的顯示區段，但截至 2026 年仍屬 experimental、並非 Baseline，不能當成所有折疊裝置都支援的通用偵測方式（見 MDN 的 horizontal-viewport-segments 條目）。基本做法仍是讓版面在手機與平板之間的各種中間寬度都能自然重排，再把 viewport segments 當漸進增強。

另一個更全面的影響來自 AI 搜尋。Google 的 AI Overviews（前身是 SGE）在 2024 年先於美國正式上線，之後逐步擴展，至 2025 年已提供給超過 200 個國家與地區、支援超過 40 種語言（見 Google 的 2024 年上線公告與 2025 年擴展公告）。這對 RWD 的啟示是：行動版應直接呈現核心資訊與完整脈絡，而不是只留一張大圖和行銷文案。不過，Google 明確表示 AI Overviews 與 AI Mode 不需要特殊 schema.org 標記；結構化資料應使用 Google 仍支援、且與頁面可見內容相符的類型，例如適用頁面的 Article（見 Google 的 AI features and your website 說明）。FAQ rich results 自 2023 年起通常只對具權威性的政府與健康網站顯示，HowTo rich results 則已於 2023 年 9 月淘汰，不能把 FAQPage 或 HowTo 當成取得 AI 曝光的捷徑，這是 2023 年 9 月 Google 對 HowTo 與 FAQ rich results 的調整公告帶來的結論。RWD 不再只是「版面縮放」，而是「手機版本身也要是一個完整的體驗」。

RWD 上線前一定要跑的七項檢查清單

觀念、原理、落地都講完了，接下來是一份照著走就行的檢查清單。在網站上線、或大改版之後，把這七項依序跑一遍，能提早發現許多常見的行動版問題。

1. 實機測試。不要只用 Chrome DevTools 模擬，找一支中階 Android 跟一支 iPhone，在 4G 訊號下開一次。模擬器測不出網路與 CPU 的真實落差。
2. DevTools 跑斷點。從目標最窄的 viewport 一路拉到桌機寬度，看版面在中間任何寬度都不破、不溢出、不出現非預期的橫向捲軸。
3. 跑一次 PageSpeed Insights。查看 Lighthouse 的 LCP、CLS、TBT 與改善建議；若頁面有足夠 CrUX 資料，再核對 field data 的 LCP、CLS、INP。
4. 查 GSC Core Web Vitals 與重要網址。先看行動版 Core Web Vitals 的問題群組，再用「網址審查」測試重要頁面是否能正確轉譯；已退役的「行動裝置可用性」報告不再是檢查入口。
5. 檢查觸控目標。用 DevTools 檢查 computed size 並實際點按，確認重要操作接近 44×44px 的實務目標，且較小目標至少符合 WCAG 2.2 AA 的尺寸或間距規則。
6. 檢查圖片。每一張圖都有 width/height、有 srcset、首屏以外有 lazy load。
7. 走一次完整轉換路徑。從首頁到加入購物車、或從首頁到送出聯絡表單，全程只用手機操作，記下任何卡關的地方。

這份清單不是一次性的。每次你換主題、加外掛、改首頁大圖，都重新跑一遍。RWD 是活的東西，不是上架一次就永遠有效。手機版速度如果還是偏慢，網站速度的實戰拆解 裡有更深入的調校步驟。

把手機版當成你的第二個店面

回到一開始那個捷運上的畫面。你花心力把實體店面開得窗明幾淨，是因為第一印象會影響客人是否繼續逛。手機版就是你在 2026 年的第二個店面，而且對不少網站來說，它已經是重要的流量入口。

RWD 這件事，技術骨架不複雜，三層講完就沒了；真正難的是那種「桌機看沒事、手機看不順」的細節，它需要你願意把手機當成第一螢幕來思考，避免把桌機版縮小了事。把這個觀念轉過來，你的網站就不會再漏接那些已經走到門口的客戶。

RWD 最迷人的地方，在於它是一種「設計哲學」多過「技術技巧」。它要的不是你背下多少 media query 語法，而是你願不願意把每一位使用者都當成主角，不管他今天拿的是 320px 的小螢幕、還是 2560px 的大螢幕。技術骨架三層就講完了，但這種「以使用者為中心」的判斷力，才是分出頂尖網站與普通網站的真正分水嶺。

如果你不知道從哪裡開始，跟著這個三步行動就好：

1. 今天就拿你的手機，用 4G 開一次自己的網站，從首頁走完一次購物或聯絡流程，記下所有卡關的地方。
2. 這週進 GSC 查看行動版 Core Web Vitals 報告，並用「網址審查」抽查重要頁面的轉譯結果；有問題就照本篇的對應欄位修。
3. 這個月把七項檢查清單跑完一遍，建立你網站專屬的斷點與裝置數據檔案，未來改版都照這份資料走。

門已經開好了，接下來就看你願不願意走進去，把每一位滑進你網站的手機使用者，好好接住。