RWD 流言終結者

RWD 全稱為 Responsive Web Design（適應性網頁設計），簡單來說就是讓你的網頁能夠伸縮自如的設計方式。在前兩篇文章介紹完九個 RWD 小撇步之後，接下來小小分析一些常見的 RWD 流言，並不是說這些流言都是胡謅一通，但我們如果常因為流言中的一些負面模糊形容而卻步，很可能就錯失了一些正面的改變機會，所以我在這邊針對一些形容詞，提供數據和參考資料，並對應現實的情況讓大家有一個基本的依據可循。

流言之一：RWD 在手機上的 UX 很爛？

建議大家可以實際瀏覽一些使用適應性設計的網站，看看依現在的 RWD 技術，UX 能做到什麼樣的程度，例如 Mozilla 美國官網、Mozilla 台灣官網、Firefox Marketplace、Web Maker 等等網站服務。另外你也可以在 Awwwards 網站上經常看到很多支援 RWD 的精美新站。畢竟好與壞的認定是主觀的，如果你不確定 RWD 是否能達到你期望的效果，先看看別的網站做得如何吧！

如果手機版是你整個網站的重心，重要性超過桌面版或大螢幕裝置，那麼建議你不妨嘗試手機優先設計（Mobile First，類似之前提到過的漸進增強概念）搭配 RWD，從手機版開始設計開發的好處是，可以在一開始就投入新鮮的肝資源把網站的最核心功能做好，不必等在桌面版做了一堆超炫功能之後，再來煩惱在手機上要如何砍掉哪些功能。這種作法讓你不得不從一開始就考慮行動裝置的資源和功能限制，進而能夠去蕪存菁只先進行最重要的核心部分。而且在手機版完成時，效能和 UX 已經針對手機優化過，之後在為桌面版增加功能時就像倒吃甘蔗，較不易遇到效能或設計瓶頸。

流言之二：RWD 的網站檔案太大載入很慢？

這是在開發行動版網站時一個常見的考量，畢竟手機的網路頻寬不比桌機，節省頻寬是一個很重要的課題。問題是，使用 RWD 就一定會浪費頻寬嗎？

先來分析一下網頁的頻寬通常用在哪些地方，以 Mozilla 美國官網的原始碼為例，圖片總計有 83.2 MB、CSS 檔 3.7MB（合併且壓縮過）、JS 檔 2.5MB（合併且壓縮過）、HTML 2.2MB（原始樣版檔，實際上可能更大一些）。也就是說 Mozilla 美國官網的圖片資源佔網頁原始檔總比例的九成左右。

就圖片來說，要節省行動網頁頻寬除了仰賴圖片壓縮技術的進步（如 Mozjpeg 2.0），上一篇文章提到了 CSS 背景圖片可以依據不同螢幕尺寸指定不同大小的圖片（或乾脆把大圖隱藏起來）。CSS 載入圖片的策略是用到時才載入，因此如果你的背景圖片在小螢幕的 media queries 設定中被覆蓋為尺寸較小的圖片設定，或是元素被設定為

display: none

以 CSS 檔案來看的話，同樣拿 Mozilla 美國官網的原始碼來統計，我寫了一個小小的 python 腳本來 粗略算出所有 CSS 檔案中，media queries 所佔的行數比例，沒有用到 media queries 的檔案則忽略不計，結果總共有 140 支 CSS 檔案使用了 media queries，而 media queries 佔總行數的 15.74%。以總體比例來看，media queries 設定的部分大約只佔所有網站原始檔案的 0.6 %。

如果考慮到行動版網站所真正使用的 HTML/JS/CSS 比起桌面版少很多（可能是不需要的函式庫，或是資料查詢筆數較少），有些東西載入到手機上真的太浪費頻寬和伺服器資源了，那麼除了考慮透過 Javascript 動態載入這些資料以外，也可以搭配網站後端判斷 

User Agent

流言之三：RWD 的網站很難維護更新？

要增加網站的可維護性，就要能夠預測網站未來的擴充方向，以利預留變更的空間，本系列第一篇提到的 DRY 原則是一個不錯的參考。

另外就 CSS 的可維護性來說，現在愈來愈多工具可以簡化 CSS 定義，如 LESS/SASS， 這些工具可幫助你將重覆的定義減至最低，避免造成改版時的絆腳石。究竟 LESS 可以幫你省去多少功夫呢？以檔案大小來比較的話，Mozilla 美國官網的 LESS 原始檔案總共 1.6 MB，而編譯產生的 CSS 總共 4.7 MB（合併未壓縮），居然節省了 66% 容量，也就是說，原本要寫 100 行的 CSS 定義檔，使用 LESS 來寫可能只需要寫 34 行。當然因為這邊統計的 CSS 檔案裡包含了一些共用的部分，這原本就能透過切割 CSS 檔案來達成，但檔案數多也會影響載入效能，且 LESS 一些方便的功能如變數定義、參數傳遞等等，其帶來的好處就不只是檔案大小可以比較得出來的了。

那麼 media queries 佔所有 LESS 定義的比例又是多少呢？用前面提到的 python 腳本掐指一算，media queries 佔了 27.54 %，也就是說 100 行 LESS 裡有 27 行是 media queries。換個角度來說，如果你的桌面版網站原本只有 73 行 LESS，那麼只要再加上 27 行，你就有一個行動版網站了耶！

當然事情通常不會這麼單純，在實作 RWD 時通常都會發現一些當初沒有考慮清楚、或是無法避免會變動的地方，這時就常會需要進行重構，本系列第二篇介紹了 media queries 的常見用法以及一些要預先注意的地方，在網站開發的初期就先注意到這些的話，在實作 RWD 時，就可以少花費一些時間在重構上面。

結論：流言破解？

看完這一系列介紹 RWD 的文章，原本對於 RWD 有點卻步的人，有沒有覺得自己也可以來嘗試看看呢？其實要選擇什麼樣的設計方式和技巧，還是要回歸到網站本身的規模和用途，什麼樣的網站適合 RWD 呢？本文提供的一些資料也許可以作為參考。如果你對於某些 Web 技術相關的流言有疑慮，也歡迎留言發問。