在討論網站要不要「支援手機」的時候，很多人把自適應與響應式混著講，以為只是兩種說法。實際上它們是兩種不同的技術路線，分岔點在於：判斷裝置這件事發生在伺服器端，還是發生在使用者的瀏覽器裡。這個差別會一路影響到你要維護幾份內容、要測試幾種組合、快取怎麼設定、以及日後出現新的螢幕尺寸時要付出多少工。台北企業因為客戶結構與內部系統的關係，偶爾會遇到必須考慮自適應的情境，所以台北自適應網站設計這個題目值得把技術面講清楚再做決定。
技術上的分岔點：判斷發生在哪一端
響應式的運作方式是：伺服器對所有裝置回傳同一份頁面內容，瀏覽器拿到之後，依照目前的視窗寬度套用不同的樣式規則，把版面重新排列。也就是說，內容只有一份，排列方式有很多種，決定權在使用者的瀏覽器。
自適應的運作方式則是：伺服器在回應請求的當下，先判斷這個請求來自哪一類裝置，然後送出專為那一類裝置準備的版本。同一個網址，不同裝置拿到的頁面內容本身就不一樣。決定權在伺服器。
從這個分岔點出發，其他所有差異都可以推導出來。內容一份還是多份、版面在幾個固定尺寸下成立還是連續變化、頁面能不能被單純快取、測試要涵蓋哪些組合——全部都取決於這個判斷發生在哪一端。
裝置判斷為什麼會失準
自適應依賴伺服器判斷裝置，而這個判斷本質上是推測，不是事實。伺服器能拿到的資訊有限，主要是瀏覽器自報的識別字串，而這個字串可以被修改、可能是新型號而不在既有的比對清單裡、也可能來自平板或折疊螢幕這種介於中間的裝置。
判斷失準會產生幾種典型狀況：手機使用者拿到桌機版，畫面過寬需要放大縮小；桌機使用者拿到手機版，畫面顯得空曠而且功能不齊；或是使用者把瀏覽器視窗縮小，版面卻不會跟著變，因為版本在送出的那一刻就決定了。
因應方式是保留手動切換版本的入口，並記住使用者的選擇。這在技術上不難，但很多網站沒做，結果一旦判斷錯誤，使用者就沒有自救的辦法。此外，裝置比對清單需要持續更新，新機型推出後若沒有補上規則，就會落到預設版本去。
台北自適應網站設計的維護代價：多一份版本就是多一份工
自適應最直接的代價是：你維護的不是一個網站，而是好幾個版本。假設分成手機、平板、桌機三種，任何一次內容更新、任何一次功能調整、任何一次修正，理論上都要在三個版本上確認。
更麻煩的是不一致會慢慢累積。第一次更新可能三邊都改到，第二次漏了平板版，第三次手機版少了一個新頁面。半年之後，三個版本的內容就開始出現落差，而使用者在不同裝置上看到不同資訊，最後受影響的是信任感與客服負擔。
測試成本也會放大。響應式的測試主要是在不同寬度下檢查版面，自適應則要測「哪一種裝置拿到哪一個版本」加上「那個版本在該裝置上好不好用」，變成兩層的測試矩陣。再加上快取層：若中間有快取，就必須確保快取會依裝置類型分開儲存，否則可能發生手機使用者拿到被快取起來的桌機版這種很難重現的問題。
什麼情況才值得選自適應
把代價講完之後，還是有幾種情境讓自適應成為合理選項。以下這幾種情況，是台北自適應網站設計比較站得住腳的時候。
- 不同裝置的任務差異極大：桌機端要提供完整的查詢、比對與下載，手機端只需要處理少數幾個動作，兩邊本來就不打算提供一樣的內容
- 舊系統無法重寫版面：頁面由既有系統產生，樣式與結構綁在一起，改成連續調整的版面成本過高，反而是在伺服器端另外產生一份輕量版本比較可行
- 需要在伺服器端就大幅減少傳輸內容：例如桌機版需要載入大量元件，手機版希望只送出必要的部分，而不是送出去之後再用樣式隱藏
- 有明確的裝置分群需求：例如內部使用的系統只在特定裝置上操作，外部頁面則另有一套
值得注意的是，第三點在響應式裡也有其他解法，例如把頁面拆得更細、把非必要元件延後載入。所以「手機版比較輕」本身不是選擇自適應的充分理由，要看你是不是真的需要在伺服器端就把內容分開。
選了之後，長期要付出什麼
決定走自適應，等於是承諾了一組長期義務，最好在專案開始前就寫進維護計畫裡。
第一是內容同步的機制。最好的情況是多個版本共用同一份內容來源，只有呈現方式不同；最糟的情況是各版本各自維護一份內容，那幾乎注定會走樣。這件事要在系統設計階段就決定，事後補救很困難。
第二是裝置規則的維護責任。誰負責在新機型出現時更新比對規則、多久檢查一次、發現判斷錯誤時的回報管道是什麼。沒有指定負責人的規則，通常上線之後就不會再更新。
第三是搜尋表現的一致性。同一個網址在不同裝置回傳不同內容時，要讓搜尋引擎能正確理解你的頁面，包含告知伺服器回應會依裝置而異、確保主要內容在各版本都存在、避免手機版把重要內容整段拿掉。如果手機版被大幅精簡到缺少關鍵內容，長期對搜尋表現是不利的。
第四是版本退場的規劃。裝置生態一直在變，三年後你可能只想維護兩個版本。合併版本時會牽涉到網址、轉址與測試，這些成本應該在一開始就預想到。
折衷路線：以響應式為底，局部做伺服器端處理
實務上，很多專案最後走的不是純粹的自適應或純粹的響應式，而是混合。做法是：整體版面用響應式處理，讓它在任何寬度下都成立；只有在少數特別吃重的區塊，才在伺服器端依裝置送出不同的內容，例如很大的圖像資源、複雜的互動元件、或是只在某類裝置才需要的功能模組。
這種做法的好處是把維護代價控制在局部：內容主體仍然是一份，網址一組，測試的重心還是在寬度變化上；只有被特別處理的那幾個區塊需要多一層檢查。對大多數台北企業來說，這通常比整站切成多版本更務實。
要提醒的是，混合做法仍然會碰到快取與裝置判斷的問題，只是範圍縮小。決定哪些區塊值得這樣處理時，判斷標準應該是「這個區塊在不同裝置上的差異大到不能只靠樣式解決」，而不是「這樣做起來比較快」。
常見問題
自適應是不是比響應式「比較進階」？
不是。兩者是不同的取捨，不是層級關係。自適應在伺服器端就把內容分開，換來的是版本數量與維護負擔；響應式維持單一內容，換來的是版面規則要處理所有寬度。適合與否取決於你的內容結構與維護人力，不是誰比較先進。
搜尋引擎會不會偏好其中一種？
兩種做法都可以被正確索引，關鍵在於實作是否讓搜尋引擎能理解。單一內容、單一網址的做法在設定上比較單純不容易出錯；多版本的做法則需要額外的標註與一致性維護。與其問哪一種被偏好，不如問自己的團隊有沒有能力把後者維護好。
我們已經有響應式網站，還需要改成自適應嗎？
多數情況不需要。除非你遇到的是內容與功能在不同裝置上本質不同的問題，單純因為手機版載入慢就整站改成自適應，通常是用很大的維護成本去解一個可以用其他方式處理的問題。
選了自適應之後還能改回去嗎？
可以，但等同於一次網站搬遷：要處理版本合併、網址對應與轉址，並預期短期內會有波動。所以在一開始就把退場路徑想清楚，比事後再處理省事得多。
如果你正在評估這兩條路，建議先從兩個問題著手：你的內容在不同裝置上是不是真的需要不一樣，以及你的團隊每個月有多少人力可以投入維護。這兩個答案通常比任何技術比較表都更能決定方向。
創昇SEO提供免費的網站健檢，也提供全台免費到府解說。若你手上已有既有網站或系統限制的說明，我們可以協助一起釐清哪些差異必須在伺服器端處理、哪些用單一版本就能解決。