「先優化圖片還是先處理 JavaScript」是前端效能討論裡的常見爭論，但依照 web.dev 對 LCP 的拆解觀點，這個問題其實沒有通用答案——LCP 時間可細分為「首位元組時間（TTFB）」「資源載入延遲」「資源載入時間」與「元素渲染延遲」四段，參考佔比約為 40%、10% 以下、40%、10% 以下。這是來源觀點：若瓶頸在 TTFB，那麼「在後端送出第一個位元組之前，前端什麼事也做不了」；若 LCP 元素是圖片，web.dev 的建議是讓圖片網址能直接從 HTML 回應中被發現，或以 fetchpriority="high" 提升關鍵圖片優先級——在 Google Flights 的案例中，LCP 因而從 2.6 秒降至 1.9 秒；而若渲染被 <head> 中的樣式表或同步腳本阻擋，動的就不該是圖片。本文嘗試把這場爭論重新框成一個有條件的編輯決策：先弄清你的 LCP 時間花在哪一段，再決定該動圖片、動 JS，還是回頭修後端回應。

  • 先別選邊站：圖片與 JS 不是二選一的戰場
  • 第一步永遠先看 TTFB：前端優化之前的前置條件
  • 什麼情況下真的要先動 JavaScript：渲染阻塞判斷法
  • 什麼情況下該先動圖片：可發現性與資源優先級
  • 把你的狀況對應到行動：一份條件式決策順序

先別選邊站：圖片與 JS 不是二選一的戰場

「先壓圖片還是先刪 JavaScript」常被講成立場之爭，但 LCP 的參考拆解先把問題換了位置：首字節時間約佔四成，資源載入耗時也約佔四成，資源載入延遲與元素渲染延遲則各低於一成，合計為百分之百。同一份 web.dev 資料也提醒，後端尚未送出第一個位元組前，前端什麼都不能開始。

所以本節不替任何一邊背書；比較精確的問法是：你的 LCP 時間究竟卡在哪一段。若連第一個位元組都還沒到，討論前端要動圖片還是動腳本，順序上天然被排在後面；但這不等於宣告後端永遠優先，因為參考拆解只是分布示意，不是替你的頁面開處方。能把直覺對立拆成可量測的分段，已經比選邊站更接近問題本身。

舉個假設情境：某頁面自測後發現主要時間落在資源載入耗時，那麼候選檢查自然會圍繞資源本身；另一位開發者若看到首字節明顯偏高，同一套前端清單就該先降權。這裡的差異不是誰比較懂效能，而是兩人面對的瓶颈段落不同；把別人的情境直接搬過來，容易把參考分布誤用成行動命令。

需要保留的界線是：來源提供的是 LCP 子環節與首字節前置關係，並沒有規定圖片或 JavaScript 必然對應哪一段，也沒有替所有網站指定先修順序。讀者可以做的，是在自己的頁面模板、裝置與網路條件下量出分段，再決定下一步；在量測之前，任何「一定先圖片」或「一定先 JS」的說法，都超出這份資料能支撐的範圍。

LCP 四大子環節與佔比摘要卡：TTFB 約四成、資源載入耗時約四成，其餘兩段各不到一成

第一步永遠先看 TTFB：前端優化之前的前置條件

在爭論先動圖片還是先動 JavaScript 之前，有一份來自 web.dev 的參考拆解值得先攤開看：在該拆分的示意中，首字節時間約佔 LCP 的四成，資源載入耗時同樣約佔四成，資源載入延遲與元素渲染延遲則分別低於一成，合計百分之百。同一來源還指出一個順序上的事實：後端尚未送出第一個位元組之前，前端什麼事都做不了；因此，任何能加快 TTFB 的手段，都會連帶改善其他所有載入指標。

由上至下為：後端送出第一個位元組、前端資源開始載入、改善 LCP 等載入指標；箭頭：後端送出第一個位元組到前端資源開始載入、前端資源開始載入到改善 LCP 等載入指標
文章內容導讀：先別選邊站：圖片與 JS 不是二選一的戰場、第一步永遠先看 TTFB：前端優化之前的前置條件、什麼情況下真的要先動 JavaScript：渲染阻塞判斷法、什麼情況下該先動圖片：可發現性與資源優先級

什麼情況下真的要先動 JavaScript：渲染阻塞判斷法

根據說明，當頁面的樣式表或 head 內的同步腳本尚未載入完畢時，瀏覽器會把整頁的渲染過程封鎖；即使 LCP 所對應的圖片資源已經完成下載，也因為渲染被阻礙而無法立即在螢幕上繪製。

什麼情況下該先動圖片：可發現性與資源優先級

另一個圖片端手段是 fetchpriority="high"：來源稱它可 boost the priority of the LCP or other critical images，範例寫法是 <img src="lcp-image.jpg" fetchpriority="high">。同一則資料並以 Google Flights 頁面作比較，該頁的 LCP background image 在 loaded with and without Fetch Priority 的情境下，with the priority set to high 時，LCP improved from 2.6s to 1.9s。

我的編輯取捨是：這一節不寫成「圖片永遠先修」，而把順序改成幾個可檢查的問題——LCP 元素是不是圖片、圖片 URL 是否已在 HTML response 中可發現、這張圖是否落在來源所說的 LCP or other critical images。只有答案與這些描述相符時，才把 src／srcset 的可發現性與 fetchpriority="high" 排進同一輪處理。

把你的狀況對應到行動：一份條件式決策順序

到這裡可以把前面幾節收束成一條條件式路徑。依來源的參考拆解，首字節時間與資源載入耗時各約佔四成，資源載入延遲與元素渲染延遲各低於一成，合計百分之百；同一來源也指出，第一個位元組送達之前，前端什麼都無法開始。據此，LCP 慢時的合理起手式，是先量首字節，再看另外三段的占比，而不是直接問先動圖片還是先動 JS。

接下來是佔比到行動的對應。若首字節明顯偏高，先是後端回應檢查，因為加快 TTFB 會連帶改善其他載入指標；若圖片早已載完而渲染延遲是一段明顯空檔，則應檢查 head 中仍在載入的樣式表或同步腳本，此時繼續壓縮圖片不會讓渲染提前。

若時間落在資源載入延遲或載入耗時，且 LCP 元素是圖片，檢查方向就換到圖片端：URL 是否可從 HTML response 直接發現（例如以 img 搭配 src 或 srcset 載入），以及是否該對關鍵圖片加上 fetchpriority="high"。來源引用的 Google Flights 案例中，該頁的 LCP 背景圖設定高優先級後，LCP 從 2.6 秒改善到 1.9 秒——但那是該頁的實測情境，不是任何頁面都會複製的數字。

參考資料10
  1. LCP優化怎麼做？從診斷最大內容渲染到縮短首屏等待 | PageLab
  2. Optimize resource loading with the Fetch Priority API | Articles | web.dev
  3. 網站速度優化避坑指南：Core Web Vitals 三大指標完整拆解與實操教學
  4. Core Web Vitals 是什麼？3 大指標與達標做法｜Kevin Voyage
  5. 改善 LCP：問題分析與三個策略 | 網頁前端 | 生活紀錄 | 攝影
  6. Core Web Vitals 是什麼？LCP、INP、CLS 與網站速度改善教學
  7. WordPress 速度優化完整指南：LCP、INP、CLS 診斷與修復優先順序 | Nitikarn Clinic
  8. 網站載入速度慢的7個原因（修復指南）
  9. WordPress Core Web Vitals 優化：改善 LCP、INP、CLS
  10. Optimize Largest Contentful Paint | Articles | web.dev
Haeng-un Services

把方法落到實際品牌系統

從策略到執行，選擇你現在最需要補強的一環。

網站設計與 SEO網站體驗、搜尋能見度與內容結構攝影與短影音品牌影像、人物內容與社群短影音社群內容與行銷內容企劃、社群節奏與轉換設計

延伸閱讀

數位／創作者觀點結構化資料的效益，傳得到 AI 摘要嗎？從 Google 三個官方案例檢視傳導鏈的斷點數位／創作者觀點HPA 與 KPA 雙軌並行：流量突波時該靠指標還靠請求？數位／創作者觀點婚禮無線多燈組合打造均衡混合光效的完整指南
想在 Google 搜尋與 AI 搜尋中優先看到 Haeng-un？

可將 haeng-un.com 設為 Google 偏好來源。

加入 Google 偏好來源
Work with Haeng-un

把下一步做得更清楚。

需要網站、影像或社群內容一起整理，我們可以從現在最重要的問題開始。

合作洽詢