題目
頁面的最大內容繪製元素通常是一張響應式圖片。請設計使用 fetchpriority、loading、preload 和 srcset 的優化方案，並說明實驗、回滾與無障礙要求。
場景與限制
桌面與行動裝置的 LCP 圖片不同，頁面還會載入字型、關鍵 CSS 和分析腳本。瀏覽器會自行調度資源，優先級提示只是提示；不能假設所有瀏覽器都以相同方式執行。
核心考點
考察能否區分發現時機、載入策略與請求優先級。fetchpriority=high 提高資源在瀏覽器佇列中的相對優先級，loading=eager/lazy 影響是否延遲載入，preload 提前宣告資源；三者疊加可能造成重複請求或擠占 CSS、字型頻寬。
參考解法
先用真實使用者資料與效能面板確認 LCP 元素及請求鏈，再只給確定的首屏 LCP 圖片設定高優先級。用 srcset 與 sizes 選擇合適尺寸，避免同時預載桌面和行動資源。不要批量給清單圖片 high，也不要把首屏圖片設為 lazy。用實驗比較 LCP、關鍵 CSS 完成時間、總位元組和長任務，逐步擴大流量。
關鍵細節
響應式圖片候選必須與 preload 的 imagesrcset、imagesizes 一致，否則可能預載一張、最終渲染另一張。檢查 Network 面板的 priority、Initiator、快取命中與請求時序；在低階裝置和慢網路驗證。保留移除提示的開關與回滾版本。
常見誤區
把 high 當成強制下載；所有圖片都 high；用 preload 取代正確的 HTML 圖片；只看 Lighthouse 不看真實使用者；忽略圖片 alt、尺寸佔位和跨域快取；沒有基線就宣稱 LCP 一定改善。
評估標準
優秀答案能說明 LCP 候選、資源優先級衝突、響應式一致性、實驗指標和回滾條件，並承認瀏覽器實作差異。一般答案只給一個屬性，沒有驗證請求佇列和真實使用者結果。
追問
何時只用 preload 而不用 fetchpriority？
當資源在 HTML 早期不可發現且確實需要提前建立請求時可考慮 preload；若瀏覽器已能及時發現圖片，優先級提示通常更小且更易回滾，仍需實驗確認。
如果 LCP 變好但字型變慢怎麼辦？
比較關鍵 CSS、字型與圖片的請求時序及頻寬占用，降低非必要圖片優先級或移除重複 preload，設定字型載入策略後再測試。
如何保證圖片優化不損害無障礙？
保留準確 alt、明確寬高或比例佔位避免版面偏移，確保低頻寬與停用圖片時仍有可理解內容，並在真實輔助技術上檢查。