RWD網站設計實作攻略：斷點設定、圖片優化與效能驗收全流程

作者｜晨星行銷　陳俊鳴執行長（網路流量操盤手・企業行銷顧問）

你可能已經知道RWD是什麼了——同一個網站、同一份內容，能依螢幕大小自動調整版面。但真正麻煩的問題通常出現在下一步：網站做完RWD之後，要怎麼確定它是「真的做好」，而不是「看起來做好」？

這正是這篇文章要處理的問題。不重複講RWD的定義、不比較RWD跟AWD怎麼選、也不談費用怎麼抓——這幾件事，另一篇文章〈RWD跟手機版網站差在哪？改版前要確認的SEO風險與費用〉已經完整寫過了。這篇要往下一層走：斷點怎麼設定才合理、圖片要怎麼處理才不拖速度、RWD對網站效能會有什麼實際影響，以及2026年到底該用什麼工具去驗證這些東西。

RWD做得好不好，不是看畫面會不會動

多數人驗收RWD的方式，就是拉一下瀏覽器視窗，看版面會不會跟著縮放。這個測試能抓到最基本的問題，但抓不到真正影響使用者體驗與SEO表現的細節。

一個網站可以做到「畫面會自動調整」，同時圖片沒有壓縮、載入速度慢、手機版點擊時整個版面還在跳動。這種狀態業界有個說法叫「表面響應式」——版面框架響應了，但響應式設計真正該解決的問題（速度、穩定、可用）一個都沒處理。

從實際協助企業檢視網站的經驗來看，多數企業主自己用肉眼很難分辨網站是真的做好響應式、還是表面響應式——因為兩者在手機上第一眼打開的觀感可能很接近，版面看起來都會自動調整。真正的差別要攤開數據才看得出來：載入速度、版面穩定度、圖片是不是真的依裝置給了合適尺寸，這些都不是肉眼掃一眼能判斷的，這也是這篇文章要花大篇幅講「怎麼用工具驗證」的原因。

RWD的技術實作大致分三層：版面層（用CSS Media Query或現代的容器查詢，依螢幕寬度調整排版）、圖片層（依裝置提供合適尺寸與格式的圖片，而不是同一張大圖硬塞給所有裝置）、效能層（版面與圖片調整的過程，不能拖慢載入速度、不能讓畫面跳動）。多數坊間文章只講版面層，這篇會把三層都講到，因為驗收只看第一層，等於只驗收了三分之一。

斷點怎麼設？從「背裝置寬度」到「內容決定斷點」

斷點（breakpoint）是RWD的骨架——網頁寬度到達某個數值時，CSS的媒體查詢就會切換一套排版邏輯。常見的做法是背一組固定數字：桌機大於1024px、平板768到1024px之間、手機小於768px，用`@media (min-width: 768px){…}`這種寫法去切版。（px是螢幕寬度的計量單位，可以想成手機、平板、電腦螢幕的「寬窄刻度」；那行`@media`是工程師寫給瀏覽器的規則，白話翻譯就是「螢幕寬度只要超過768px，就換一套排版方式」，不用自己看懂程式碼，知道這句在講什麼就夠了。）

這套數字能用，但有個先天問題：它是「背裝置寬度」，不是「看內容需要」。手機型號一直在變，某一年的斷點數字，過幾年可能就對不上主流裝置的實際寬度了。

2026年比較成熟的做法，是先不管裝置，直接把瀏覽器視窗慢慢拉窄，看版面在哪個寬度「開始壞掉」——文字擠在一起、按鈕疊到一塊、留白失衡——那個寬度，才是這個網站真正需要的斷點。這種做法叫「內容驅動斷點」，斷點數量通常比想像中少，因為只在真正需要調整的地方切版，不是每個標準尺寸都切一次。

除了傳統的媒體查詢，CSS也發展出「容器查詢」（container queries）這個較新的工具——差別在於媒體查詢是依整個瀏覽器視窗的寬度切版，容器查詢則是依「這個元件所在的容器」有多寬來切版。根據MDN（Mozilla官方開發者文件）的說明，容器查詢讓網頁元素可以依照自己所在容器的尺寸來套用樣式，而不是只能依整個視窗寬度判斷——作法上是先幫某個區塊宣告「這是一個查詢容器」，再針對這個容器的寬度寫對應樣式規則。舉個例子：同一張卡片元件，放在側邊欄裡很窄、放在主版面裡很寬，用容器查詢就能讓這張卡片自己判斷所在空間、自動調整內部排版，不用管整個頁面現在是手機還是桌機。這對元件庫比較複雜的網站特別實用，主流瀏覽器目前都已經支援。

圖片響應式處理：RWD最容易被漏掉的效能環節

如果只處理版面、沒處理圖片，RWD做了等於沒做一半。網頁的載入重量，圖片通常占了超過一半——這代表圖片處理得好不好，直接決定這個網站在手機上「感覺快不快」。

圖片的響應式處理，核心工具是`srcset`屬性跟`<picture>`標籤。`srcset`讓瀏覽器依裝置的螢幕寬度或像素密度，自己挑一張合適大小的圖片下載，不會把桌機版的大圖硬塞給手機。`<picture>`標籤則更進一步，可以依螢幕尺寸提供完全不同裁切角度的圖（例如桌機版是橫幅構圖、手機版換成直式構圖），也可以依瀏覽器支援度提供不同格式（能吃新格式的瀏覽器抓小檔案、不支援的抓回舊格式）。

格式選擇上，過去多半用JPEG，這幾年WebP已經是相對成熟穩健的選擇；更新的AVIF格式，壓縮效率又比WebP再高一截。簡單說，這三種格式就像同一張照片的三種壓縮包裝方式——技術越新，同樣畫質下的檔案就能包得越小，對你來說就是網站在客戶手機上跳出來的速度更快，客戶比較不會等到不耐煩就滑走。

算一筆帳：假設一張桌機版設計稿裡的橫幅大圖，原始檔案大小抓在2到3MB，不做任何響應式處理直接塞給手機版，使用者的手機就得下載這整包資料。做好響應式圖片處理（依螢幕寬度給對應尺寸、搭配WebP或AVIF格式）之後，同一個版位在手機上實際下載的檔案，通常可以降到幾百KB的等級——差距往往有五倍以上，這還沒算進頁面上其他張圖片的疊加效果。實際能省多少，會因圖片內容、原始尺寸與壓縮參數而不同，但方向是明確的：不處理圖片格式與尺寸，RWD的效能紅利大部分就沒拿到。

常見誤解：不少人以為「做了RWD，圖片就會自動變小」。實際上瀏覽器不會自己幫你決定該下載哪個尺寸的圖片檔——除非你用`srcset`／`<picture>`明確告訴它有哪些選項可以挑，否則不管螢幕多小，瀏覽器預設還是會把原始檔案整包下載下來，只是在畫面上用CSS把它縮小顯示而已。畫面上看起來變小了，流量卻一點都沒省到，這是最容易被誤會、也最容易被驗收忽略的一點。

搭配`loading=”lazy”`可以讓頁面往下捲動後才會出現的圖片延後載入，減少首次載入需要處理的資源量。但有一個例外要特別注意：首屏最重要的那張大圖（也就是決定LCP分數的那張圖），不該加lazy loading，反而應該優先載入——這一點下一段會再細說。

RWD對網站效能的實際影響：LCP、CLS、INP踩坑點

RWD做得好不好，最後都會反映在Google用來衡量網頁體驗的三個核心指標上：LCP（最大內容繪製，衡量主要內容多快出現）、CLS（累積版面配置轉移，衡量畫面穩不穩定）、INP（互動到下次繪製，衡量操作反應快不快）。根據web.dev（Google官方開發者資源）的原始定義，LCP應在頁面開始載入後2.5秒內出現才算良好，超過4秒屬於不良表現；CLS數值要在0.1以下才算良好，超過0.25屬於不良；INP則要在200毫秒以內才算良好，超過500毫秒屬於不良。這三個門檻不是模糊的感覺，是Google官方定義的具體分級標準。翻成生活感受：LCP 2.5秒，大概是你滑開網頁、眨兩下眼睛的時間；CLS 0.1，代表畫面幾乎不會亂跳動，你正準備點的按鈕不會突然被擠到別的地方去；INP 200毫秒，則是手指點下去、畫面幾乎「秒回」，感覺不出延遲。三項只要有一項掉到「不良」，代表訪客能感覺到網站慢或卡，願意留下來的機率就會跟著往下掉。

跟RWD關係最直接的是CLS。行動網頁最常見的CLS成因之一，就是圖片沒有設定明確的寬高尺寸——瀏覽器在圖片真正下載完成之前，沒辦法預先算出要幫這張圖保留多少版位空間，等圖片載入完成，畫面就會被硬推開一塊，使用者正準備點的按鈕可能就在這一瞬間被推走。有研究指出，超過六成的行動網頁存在至少一張沒有設定尺寸的圖片，這也是行動裝置CLS表現普遍不理想的重要原因之一。

LCP方面，容易踩的坑是「把所有圖片一律加上lazy loading」。lazy loading確實能幫助非首屏圖片延後載入、減輕初始負擔，但如果連首屏最主要的那張圖（通常就是決定LCP分數的那張）也一起延後，反而會拖慢LCP表現——這張圖應該優先載入，而不是排隊等待。

打個比方，這有點像餐廳出餐：讓後面桌次的菜晚一點上（lazy loading）沒問題，但如果連第一桌的招牌菜都刻意延後端出來，客人等的時間反而變長了——分寸抓錯，好意反而變成拖累。

INP跟RWD的關聯相對間接，但同樣重要：手機版如果選單、按鈕密度太高、觸控目標太小，使用者要反覆點擊才能點中，介面反應時間跟操作次數都會被拉長，間接影響INP的實際表現與使用者的操作體感。

怎麼驗證RWD做得好不好：2026年還能用的工具組合

這裡有一件容易被忽略、但相當重要的事：Google已經在2023年12月正式關閉了「Mobile-Friendly Test」這個獨立測試工具，以及Search Console裡的「行動裝置可用性」報告。Google Search Central官方當時的說法是：「許多評估行動裝置可用性的可靠資源已經出現，包括Chrome的Lighthouse」，並把原本Mobile-Friendly Test的入口導向Lighthouse。如果你手上正在看的文章或跟你溝通的網頁設計公司，還在建議你「去Mobile-Friendly Test測一下」，代表對方講的是已經停用超過兩年的方法。

實務上建議的驗證順序：先用PageSpeed Insights的行動版分頁抓分數與具體問題點，再對照Search Console的核心指標報告看真實使用者數據是不是良好等級，開發或除錯階段則搭配Chrome DevTools或Lighthouse，直接在不同螢幕寬度下檢查版面與載入狀況。這幾項工具現在都還在維護、都還能用，是目前最務實的組合。

至於「畫面縮放看會不會跑掉」這個最原始的目視檢查，仍然值得做，但只能當第一關的粗篩，不能取代上面這套有數據支撐的驗證流程；更完整的檢測工具與各項速度指標怎麼交叉比對，可以參考網站速度測試怎麼做？工具、指標與拖慢原因完整排查這篇。

發包或驗收前，先把這份技術檢查清單印出來

常見的情況是這樣的：企業主發包做RWD網站，驗收那天只打開手機看首頁縮放正不正常，覺得沒問題就簽收，等網站上線一段時間後才發現手機版速度很慢、Google的核心指標報告一堆紅字，這時候廠商早就結案離場了。驗收如果只停在「畫面會動」，等於把最容易出問題的效能與圖片這兩層直接放過去。

以下這份清單，把上面幾段講的技術重點收斂成可以逐項打勾的驗收項目：

如果你不確定怎麼把這些項目寫進驗收條款、或看不懂PageSpeed Insights回報的建議該怎麼改，晨星行銷這類長期處理SEO與網站技術優化的顧問，通常能幫忙把這份清單轉成廠商聽得懂的驗收語言，避免驗收流於「看起來沒問題」這種主觀判斷。

常見問題

陳俊鳴

網路流量操盤手．企業行銷顧問

操盤SEO與網路行銷實戰逾15年，2014年創辦晨星事業有限公司（晨星行銷），從SEO網站架設、關鍵字策略到銷售漏斗與變現模式一手包辦。現為智信科技、瞻新資訊等多家企業的常年行銷顧問，也獲頒過亞洲十大卓越名師金像獎，把每一次流量成長都當成自己的事業在打。曾是馬來西亞象棋、圍棋國手，拿過亞洲盃第二名。