前言...呃，或者說，先來點牢騷
每次要聊「手機網站優化」，總覺得有點膩。老實說，現在都 2025 年了，還在講「移動優先」好像有點...落伍？這不是早就該是基本功了嗎？ Google 從 2018 年就開始搞移動優先索引了，理論上大家應該都已經上軌道了才對。
但現實就是，很多網站的手機版體驗還是一團糟。點個按鈕卡半天，頁面載入時圖文亂跳... 這種網站，就算內容再好，我也只想立刻關掉。慢速網站每年讓零售商損失幾十億美元，這可不是開玩笑的。
我看了一些文章，大多在談那些老生常談的技巧：壓縮圖片、合併 CSS/JS。不能說錯，但就是少了點什麼。感覺像是教你怎麼用算盤，但現在大家都在用計算機了。所以，這篇我想聊點不一樣的，一些我自己在踩坑之後覺得真正有用的策略，可能有點硬，但效果很好。
所以，重點到底是什麼？
一句話結論：別再只盯著載入「速度」，該關心的是載入「過程」的體驗。
使用者不是機器，他們感受不到你快了 0.1 秒，但他們能清楚感覺到頁面是不是「穩定」、互動是不是「順暢」。Google 的 Core Web Vitals 指標，像是 LCP、INP、CLS，其實就是在量化這些「體感」。 我們要做的，就是針對這些指標去動手腳。
大家都在講的，跟我們該做的有什麼不同？
我看現在大部分的教學，都還停留在「減少請求數量」、「壓縮檔案大小」的層次。 這些很重要，但這是基本分。現在真正的戰場，是瀏覽器拿到資源之後的「渲染階段」。
我們該思考的是：
- 瀏覽器渲染的順序對不對？最重要的東西有先出來嗎？
- JavaScript 是不是佔據了主線程（Main Thread），導致使用者點什麼都沒反應？
- 第三方工具（像是一些分析、廣告、客服插件）是不是拖垮了整個網站？
這些問題，光靠壓縮圖片是解決不了的。
我的 5 個關鍵策略
好，牢騷發完，來講點正經的。這五個策略是我目前認為最有效，而且很多人沒做好的地方。
1. 圖片優化：不是只有壓縮而已
圖片絕對是拖慢手機網站的頭號戰犯。但「優化」不只是用工具把檔案壓小而已。
- 現代格式優先： 拜託，2025 年了，還在用 JPG 跟 PNG 當主力嗎？現在應該優先提供 AVIF 或 WebP 格式。 它們的壓縮率高很多，畫質卻差不多。可以用
- 響應式圖片 `srcset`： 手機螢幕根本不需要載入 2000px 寬的超大圖片。用 `srcset` 屬性提供不同尺寸的圖片，讓瀏覽器根據裝置寬度去抓最適合的那張，這能省下超多流量。
- 精準控制載入時機： 不是所有圖片都要「延遲載入 (Lazy Load)」。 在畫面第一屏、使用者馬上會看到的最大內容 (LCP)，例如首圖，反而要用 `loading="eager"` 或 `` 讓它優先載入。把 Lazy Load 用在畫面以外的圖片就好。
這點在 Google 的開發者文件裡有提，但在日本的一些 SEO 文章中，他們更強調 Core Web Vitals 的整體性，認為 LCP 只是其中一環，不該過度優化單一指標而忽略了全局。 我自己是覺得，先抓住 LCP 這個大頭，通常體感改善最明顯。
2. CSS 優化：拆分「關鍵」與「非關鍵」
很多人會把所有 CSS 打包成一個檔案，這對手機來說是災難。瀏覽器要下載完、解析完這一大包東西，才能開始畫頁面。正確做法是「關鍵 CSS (Critical CSS)」。
- 什麼是關鍵 CSS？ 就是讓使用者「第一眼」看到的畫面（Above the fold）所需要的最小樣式集合。
- 怎麼做？ 把這部分的 CSS 直接內嵌到 HTML 的
裡。這樣瀏覽器不用另外發請求，拿到 HTML 就能立刻渲染首屏。 - 剩下的怎麼辦？ 其他的、非首屏才用到的 CSS，就用非同步方式載入。
這能大幅改善 LCP 跟 CLS（累計版面配置位移），因為版面不會在載入過程中亂跳。
3. JavaScript 執行：別讓它「堵塞」主幹道
JavaScript 是造成互動延遲（現在 Core Web Vitals 叫 INP，取代了以前的 FID）的主因。 當它在執行複雜運算時，整個頁面就像卡死了一樣，使用者點什麼都沒反應。這在效能較差的手機上尤其嚴重。
- 程式碼拆分 (Code Splitting)： 不要一次把所有功能的 JS 都塞給使用者。利用 Webpack 或 Vite 這類工具，把程式碼按「路由」或「功能」拆分成小塊，使用者需要時再載入。
- 善用 Web Worker： 對於那些很耗時、但又不需要操作畫面的運算（例如複雜的數據處理），可以把它們丟到 Web Worker 這個背景執行緒去跑。 這樣就不會卡住主線程，頁面依然滑順。
- 推遲執行： 很多 JS 其實不用在頁面一載入就馬上執行，像是頁腳的某些功能、一些互動特效等。可以用 `requestIdleCallback` 或單純的 `setTimeout` 讓它們在瀏覽器比較閒的時候再跑。
4. 第三方指令碼：找個「沙盒」關起來
Google Analytics、Facebook Pixel、客服聊天工具... 這些第三方指令碼是效能黑洞。我們無法控制它們的程式碼品質，但它們卻在我們的網站上執行，拖慢一切。
Partytown 是一個蠻酷的解決方案。它的概念是把這些第三方腳本都丟到 Web Worker 裡去執行。這樣它們就算再怎麼亂搞，也只會在背景的「沙盒」裡，影響不到主線程的使用者體驗。這對改善 INP 特別有效。
5. 字型載入策略：別讓文字消失又閃現
Web Font (網路字型) 載入時，常會發生兩種惱人的情況：FOIT (Flash of Invisible Text，文字直接消失) 或 FOUT (Flash of Unstyled Text，先顯示系統預設字型，再換成目標字型)。這都會造成 CLS 分數飆高。
最簡單的解法是使用 `font-display: swap;`。這會讓瀏覽器先用系統字型顯示文字，等網路字型下載好再替換上去。雖然會閃一下，但至少使用者能馬上開始閱讀。再搭配 `` 預載字型檔，可以把閃爍的時間縮到最短。
優化策略的風險評估
當然，不是所有優化都有益無害。有些技術導入起來很麻煩，還可能把網站搞壞。所以我整理了一個簡單的風險矩陣，純屬個人看法。
| 優化策略 | 預期效能提升 | 實作難度 | 搞壞網站的風險 |
|---|---|---|---|
| 圖片格式現代化 (AVIF/WebP) | 高 | 中等。需要後端或建置流程配合。 | 低。用 |
| 關鍵 CSS | 非常高 | 高。自動化工具設定複雜，手動維護很累。 | 中。如果沒抓準，首屏樣式會跑掉，很醜。 |
| JS Code Splitting | 高 | 中等。現代前端框架大多內建，但要規劃好怎麼拆。 | 中。拆不好可能導致某些功能在需要時才發現 JS 沒載入。 |
| Partytown 管理第三方 | 中等 | 中等。需要研究一下文件，不是所有腳本都 100% 相容。 | 中高。某些依賴 DOM 操作的第三方腳本可能會出問題。 |
| 字型優化 `font-display` | 中等 | 非常低。就加一行 CSS 屬性。 | 極低。頂多就是字型閃一下，但不會壞。 |
結論...嗎？
嗯，與其說是結論，不如說是一些心得吧。手機網站的效能優化，現在已經是個很細緻的工藝了。它不是一個 checklist，打勾完就沒事。更像是在跟瀏覽器打交道，理解它的運作脾氣，然後引導它用最高效的方式把內容呈現給使用者。
今天講的這些策略，可能無法一步到位。我的建議是，先用 PageSpeed Insights 或 Chrome DevTools 跑一下你的網站，看看 Core Web Vitals 的報告。 找出分數最差的那個指標（LCP、INP 或 CLS），然後從對應的策略開始著手。一次解決一個問題，持續改進，效果才會慢慢出來。
最後想問問大家，你在優化手機網站時，踩過最大的坑是什麼？或是有什麼獨門秘技？在下面留言分享一下吧。
