拖曳圖片或點擊選擇
PNG, JPEG, WebP, GIF, BMP, AVIF
運作方式
佔位圖就是在圖片下載期間代替它的內容。它有兩個不同的作用：預留圖片將要佔據的確切空間，使圖片出現時周圍的文字不會跳動；以及顯示與最終內容相似的畫面，讓等待的感覺比面對一個灰色矩形要短。
解決方案分為三類。精簡雜湊（BlurHash 與 ThumbHash）把圖片壓縮成極短的文字字串，短到可以和記錄的其餘欄位一起存進資料庫的一欄；瀏覽器解碼後繪製出模糊圖。data URI（LQIP 縮圖與 SVG）把已編碼的圖片直接放進 HTML 或 CSS，因此完全不需要 JavaScript。而純色是所有佔位方案中最省的：七個字元。
選哪一種取決於 HTML 從何而來。如果圖片來自資料庫、而且要成百上千地列出，那麼按記錄計算雜湊最輕。如果你產生靜態頁面，或使用已經支援佔位圖的框架，data URI 可以省去加入解碼程式碼。你在這裡看到的所有數值都在你的瀏覽器中計算：圖片不會上傳到任何伺服器。
範例
blurhash 4 × 3LGHC162?|cKNqSWDjtaghVfjfQfjBlurHash 的長度只取決於分量數量，與圖片的尺寸和內容無關：4 × 3 始終是 28 個字元，3 × 3 是 22 個，5 × 4 是 44 個。thumbhash3wcKNZpwh3eAiIh3iHiIiHCAB/eH一個 ThumbHash 占 17 到 25 位元組，即 Base64 下的 24 到 36 個字元。確切大小取決於圖片的長寬比以及是否帶透明度，因為該格式還會編碼 alpha 通道。lqip 24 px webpdata:image/webp;base64,UklGRi…寬 24 px 的 WebP 縮圖通常小於 1 KB。它內嵌在 HTML 中，不會產生額外請求，但會讓文件變大，而文件不會被單獨快取。使用情境
- 把 BlurHash 或 ThumbHash 存進圖片表，讓列表或無限捲動的資訊流從第一刻起就有內容可顯示。
- 當圖片不是靜態匯入時，填寫 next/image 的 blurDataURL 屬性或 NgOptimizedImage 的 placeholder。
- 把佔位圖與 width、height 屬性結合使用，避免產品卡片或文章卡片出現版面位移（CLS）。
- 在無法執行解碼 JavaScript 的靜態 HTML、郵件或範本中嵌入佔位圖。
- 在網頁和行動應用中重複使用同一個 BlurHash，行動端有 Swift、Kotlin 與 Flutter 的解碼器。
- 當位元組預算連一張縮圖都容不下時，用平均色彩作為容器背景。
常見問題
選 BlurHash 還是 ThumbHash？
ThumbHash 用更少的位元組更忠實地還原圖片，保留透明度並記錄長寬比，因此你甚至不需要知道原始尺寸就能繪製它。BlurHash 出現得更早、精度較低，但在更多平台與語言上都有實作。如果從零開始，選 ThumbHash；如果你的技術堆疊裡已經有 BlurHash 解碼器，就沒必要遷移。
這樣能改善 LCP 嗎？
不會直接改善。佔位圖提升的是速度的主觀感受，搭配 width 和 height 還能消除版面位移，但 LCP 指標仍然以真實圖片繪製完成的時刻來計算。更進一步：如果主圖就是 LCP 元素，不要給它加 loading="lazy"，也不要把它藏在佔位圖後面延遲載入；應該用 fetchpriority="high" 標記它，讓瀏覽器更早發出請求。佔位圖是給首屏之外的圖片用的。
BlurHash 該用多少個分量？
橫向圖片用 4 × 3 效果不錯，直向圖片用 3 × 4。每增加一個分量會多出兩個字元和一點細節，但超過六或七之後，肉眼就分辨不出差別了，因為結果本來就是模糊顯示的。
選雜湊還是 data URI？
雜湊每張圖片只占幾十個位元組，在同一頁面有大量圖片時非常合適，但需要用戶端程式碼來解碼。data URI 什麼都不需要，不過體積要大十到五十倍，而且隨 HTML 一起傳輸，而 HTML 不會被單獨快取。圖片不多且是重點展示時，用 data URI 更合適；列表很長時，用雜湊。
為什麼要用 SVG，而不是直接用縮圖？
因為模糊是瀏覽器在繪製 SVG 時施加的。這樣你可以從更小的縮圖出發，放大時也不會出現像素方塊，而且在任何尺寸下都同樣平滑。SVG 還會把 alpha 固定為不透明，以免模糊讓邊緣變透明。
佔位圖有大小限制嗎？
取決於所用的工具。當佔位圖的 data URI 超過 4000 個字元時，Angular 的 NgOptimizedImage 會在主控台發出警告，因為從那時起 HTML 的體積代價開始超過收益。這是一個不錯的通用參考：如果你的縮圖超過這個數值，就降低寬度或品質。