為何網站 3 年就要重做：技術債、Core Web Vitals 與手機體驗
網站不是用舊了，而是累積了決定。本文拆解技術債的五個來源（外掛堆疊、未壓縮圖片、追蹤碼、無版本控制、樣式硬改）、它如何影響速度/排名/改動速度，以及三種處理方式（清理、換前台、重寫）的成本差異。
文章目錄（點擊展開）
大部分網站不是「用舊了」，而是「累積了決定」。每一個當時合理的小決定——加一個外掛、加一段追蹤碼、加一張 4MB 大圖——三年後就變成改不動的原因。這篇講技術債怎樣形成，以及幾時應該處理。
決策摘要（30 秒）
技術債唔等於「舊」。判斷標準係：改一樣東西要牽動幾多其他東西。
如果每次改動都要「先備份、再試、唔得就還原」，就係時候處理。
處理方式有三種：清理、換前台、重寫。多數情況唔需要重寫。
一、技術債的五個來源
- 外掛堆疊。每個需求都用外掛解決，最後十幾個外掛互相依賴，更新任何一個都可能壞另一個。
- 圖片無壓縮。直接用設計師的原始檔上載，一張 4MB，首頁十張就 40MB。
- 追蹤碼層層疊。不同年代的 GTM、Pixel、GA 版本同時存在，載入順序互相干擾。
- 沒有版本控制。改動靠複製檔案，出錯無法回滾，只能憑記憶修。
- 樣式硬改。直接在頁面寫 inline style，改一個顏色要改幾十個地方。
二、為何這件事直接影響生意
技術債唔止影響工程，佢直接影響三件事：
| 影響 | 機制 | 結果 |
|---|---|---|
| 載入速度 | 大圖、過多 script、無快取 | 手機用戶跳出，廣告轉換率下降 |
| 搜尋排名 | Core Web Vitals 差、結構混亂 | 同樣內容排得比對手後 |
| 改動速度 | 每改一次都要全站測試 | 市場機會來了但趕不上 |
三、三種處理方式，成本差幾倍
| 方式 | 做什麼 | 適合 |
|---|---|---|
| 清理 | 壓縮圖片、移除無用外掛與 script、整理 CSS | 架構仍可維持，只是累積了雜物 |
| 換前台 | 保留 CMS 與內容，重做前端（Headless） | 內容有價值但前端到天花板 |
| 重寫 | 重新設計架構與代碼 | 連資料結構都無法維持 |
實務上大部分個案係「清理 + 換前台」，真正需要全站重寫嘅比例唔高。所以先做診斷，唔好一開始就假設要重做。
四、三個可以自己做的檢查
- 1. 用 PageSpeed Insights 測手機版，記錄 LCP 與總載入大小
- 2. 開瀏覽器 DevTools 的 Network，睇首頁載入幾多個請求、總共幾多 MB
- 3. 試改一句首頁文案，計由提出到真正上線要幾耐
第三項最能反映技術債：如果需要超過一日，問題通常不在人手，而在架構。
三、技術債的五個來源
技術債不是「寫得差」的同義詞。它通常來自五種合理但代價高的決定：
| 來源 | 當時的理由 | 日後的代價 |
|---|---|---|
| 為趕上線而硬改 | 活動／展覽有死線 | 改一個地方會影響三處，沒人敢動 |
| 外掛堆疊 | 每個需求都裝一個現成外掛 | 載入變慢、衝突、安全更新互相牽制 |
| 直接改主題／核心檔案 | 改得快，不用開子主題 | 無法更新，一更新就白屏 |
| 圖片與素材從未整理 | 編輯直接上傳原圖 | 首頁載入幾十 MB，手機體驗崩壞 |
| 沒有版本控制 | 直接改正式站最快 | 出錯無法回滾，只能憑記憶修 |
四、技術債怎樣變成 Core Web Vitals 問題
三項核心指標各自對應一種技術債：
LCP（最大內容元素繪製）－ 慢
通常是首圖過大、沒有正確尺寸、或主圖由 JavaScript 才載入。技術債來源：素材從未整理、沒有圖片優化流程。
INP（互動至下次繪製）－ 鈍
點擊後頁面沒反應，通常是第三方腳本過多、主執行緒被佔滿。技術債來源：外掛堆疊、追蹤碼沒有節流。
CLS（累計版面位移）－ 跳
載入時內容跳動，通常是圖片沒有指定尺寸、字體載入方式不當、或廣告位沒有預留空間。技術債來源：版型靠外掛拼接、沒有預留容器。
這解釋了為什麼「只叫工程師優化速度」通常無效——真正要處理的是產生這些問題的流程。
五、三種處理方式的成本差距
| 方式 | 做什麼 | 時間 | 何時適合 |
|---|---|---|---|
| 止血 | 壓縮圖片、移除明顯無用腳本、加快取 | 數天 | 立即需要改善分數 |
| 重構 | 整理外掛、改子主題、建立圖片流程、加版本控制 | 數週 | 網站仍可長期使用 |
| 重寫 | 重新設計架構與內容結構 | 數月 | 核心架構已無法支撐業務 |
實務上，八成網站只需要「止血＋局部重構」，不需要重寫。真正需要重寫的，通常是資料模型或核心流程錯了，而不是速度問題。
六、三個你可以自己做的檢查
- 看實際用戶數據，不只看實驗室分數。PageSpeed Insights 分兩部分：實驗室數據與實際用戶數據（Core Web Vitals 評估）。只有後者影響排名。
- 數一數首頁載入多少個第三方腳本。每一個追蹤碼、聊天插件、廣告像素都會佔用主執行緒。
- 用手機網絡測試一次完整流程。不是 Wi-Fi，而是 4G 環境下由進入到提交表單，記錄每一步的感受。
七、常見問題
Q：Core Web Vitals 直接影響排名嗎？
它是排名因素之一，但權重低於內容相關性與連結。真正影響更大的是它對轉換率的影響——載入慢的頁面，查詢完成率會明顯下降。
Q：換主機會不會解決速度問題？
如果問題在主機回應時間，會。但如果問題在圖片大小與前端腳本，換主機不會有明顯改善。應該先量度，再決定。
Q：技術債一定要全部還清嗎？
不需要，也不可能。應該優先處理「影響收入」與「影響改動速度」的部分，其餘可以接受並記錄在案。
八、怎樣排技術債的優先次序
技術債不可能一次還清，所以要排次序。我們用兩個維度評分：影響收入的程度與修復成本。
| 類型 | 影響收入 | 修復成本 | 優先次序 |
|---|---|---|---|
| 首圖過大、載入慢 | 高 | 低 | 立即做 |
| 表單流程多餘步驟 | 高 | 低至中 | 立即做 |
| 外掛衝突與版本鎖死 | 中 | 中 | 排期做 |
| 沒有版本控制 | 中（風險） | 低 | 排期做 |
| 資料模型設計錯誤 | 高 | 高 | 連同重寫一併處理 |
| 舊頁面沒人看但仍在 | 低 | 低 | 可以不理 |
這張表最重要的訊息是：最容易做的往往也是最影響收入的。很多公司花錢重寫，卻沒有先把首圖壓縮——後者一天可完成，對轉換的影響可能更大。
九、建立防止技術債累積的四個習慣
- 圖片上傳前先壓縮。建立一個統一流程，而不是靠個人記得。
- 每次改動都可回滾。有版本控制，就不怕改錯。
- 定期移除沒用的外掛與腳本。每季檢視一次，功能重複的合併。
- 記錄「為什麼這樣做」。日後接手的人（包括未來的自己）才知道限制在哪裡。
ADWire 編輯團隊
ADWire Agency Limited
文章由 ADWire 團隊撰寫及審閱。團隊負責軟件開發、AI 應用與工作流程自動化、SEO／GEO 及數碼營銷項目，內容取材自實際項目經驗及公開的官方資料。
- 軟件及系統開發
- AI 應用及流程自動化
- SEO 及 GEO 搜尋優化
- 數碼營銷及成效量度
相關服務
相關文章推薦
網站幾時應該重做？5 個該換的訊號與 3 個不該換的情況
判斷網站是否需要重做，唔係睇佢有幾舊，而係睇你想解決咩問題。本文列五個應該重做的訊號（手機體驗、載入速度、改動速度、SEO 結構、系統接口）、三個唔應該重做的情況，以及成本通常最低的中間路線：只換前台。
閱讀全文
香港網頁設計收費 2026：三個起步價與報價單要問的八條
做一個網站要幾錢？本文直接列三個起步範圍（形象網站 HK$8,000 起、功能型約 HK$10,000 起、電商 HK$30,000 以上），拆解令價錢差十倍的六個因素、三種收費模式，以及收到報價單時必須問的八條問題。
閱讀全文