本頁面由 Cloud Translation API 翻譯而成。

來自 2019 年夏季圖片最佳化問卷調查的意見回饋

問卷調查受訪者對各種圖片最佳化技巧的看法

Sam Dutton

這篇文章列出了 Google Web DevRel 在 2019 年夏季圖片最佳化技術問卷調查中收到的自由回饋。我們透過 Web 基礎知識和 @ChromiumDev 徵求回應。這項調查的動機在於瞭解為何大多數網站未遵循圖片最佳化最佳做法，儘管這似乎是改善效能的相對簡單方法。由於問卷調查方法有缺陷，因此這裡沒有列出回覆資料。

目標對象

如果您是網頁程式開發人員，這篇文章或許能幫助您發掘新的圖片最佳化技巧，或詳細說明其他網頁程式開發人員如何解決您遇到的問題，以及各項技巧的成本、優點和限制。
如果您是圖片服務或圖片 CDN 供應商，這篇文章或許能協助您發掘新的市場商機。
如果您是架構、建構工具或 CMS 開發人員，這篇文章或許能提供您實作新功能的構想。

留言

WebP

「我很喜歡 WebP，但這項格式尚未完全就緒。此外，我們的 WordPress 不支援 WebP。最熱門的相片編輯應用程式之一 Photoshop 也無法原生支援 WebP。因此，我們無法依賴第三方應用程式或服務來壓縮圖片。」
「讓 WebP 可在 Safari 上使用」。
「如果可以從 Photoshop/Figma/Sketch 匯出 WebP 圖片，而且所有瀏覽器都支援 WebP，我很樂意使用 WebP。」[注意：Sketch 支援 WebP]
「下一代格式解決方案會很棒。」
「在瀏覽器支援度不佳的情況下，請停止強推 WebP，並考慮使用 PNG 而非 JPEG 做為螢幕截圖。」
「Google 文件不支援 WebP。」
「我們會專門使用 WebP，但擔心瀏覽器相容性。」
「先修正瀏覽器相容性問題，並更新舊版瀏覽器或新增舊版修正程式，這樣使用者才會更願意採用 WebP 等新圖片類型……」
「鼓勵外掛程式/主題開發人員考慮支援 WebP 和其他新一代圖片類型，這樣非開發人員就不需要自行調整。」

SVG 和向量圖片

「如果可以，我會使用 (動畫) SVG。gatsby-image 修正了許多這類問題。但深入瞭解他們的做法後，我們發現一般網站根本不必建構類似的架構，才能讓圖片正常運作。瀏覽器應承擔更多這類責任。」
「能否記錄如何使用 lottie.js 建立 SVG 動畫？」
「我們會盡量在網站上使用解析度高、大小小的 JPEG 圖片，以免造成載入時間。我們也會視需要使用 SVG，為回應式設計提供高品質的圖片。」
「我們會盡量使用最佳化向量圖形，但圖片除外。」

其他圖片格式

「我們需要進一步教育使用者停止使用 GIF。」

延遲載入

「在考慮延遲載入等功能時，請將使用者放在心上，因為許多人會覺得這類功能很煩人。」
「請讓延遲載入屬性與 background-image 搭配運作。」
「架構應提供更優異的素材資源處理功能。」
「我們很久以前就從延遲載入轉換過來了。使用者回報數百萬張圖片和網站「無法載入」。這是我們的團隊對這項問題的理解。非技術人員很難描述問題。」
「我很想進一步瞭解如何使用 Intersection Observer API 進行延遲載入，而非使用傳統技術。」
「我覺得這個網址很實用：pwafire.org/developer/codelabs/progressive-loading。」

背景圖片

「我通常會在 CSS 中將圖片載入為背景。」
「<img> 標記存在問題，且難以控制精細細節，特別是使用者提交的內容。我們更常使用 <div> 和 background-image 樣式，因為這樣我們可以使用 background-size、background-position，並防止使用者按滑鼠右鍵儲存圖片。」

透明度

「現在是 2019 年，為何 JPG 仍沒有 Alpha 透明度？」
「我只會在需要透明背景時，才會使用 PNG 格式儲存相片。」

低品質圖片預留位置 (LQIP)

「我們使用 LQIPS，這是個很棒的技術，可讓訪客保持互動，且不必在很早就載入高畫質圖片。」

成效

「我們最近遇到圖片效能問題，當使用者在網站上向下捲動時，我們會顯示接下來 60 張含有縮圖的資訊卡。由於同一個網域有 6 個連線限制，因此如果使用者繼續向下捲動，系統會封鎖縮圖和下一個 AJAX 要求，以便取得下一個 60 張資訊卡。」
「我們很樂意使用 HTTP/2，但大多數客戶都使用 IE11！因此，我們正在研究網域分割 / 載入 AJAX JSON 資料要求的做法，以便在不同的網域中執行。」

尺寸

「很抱歉，使用內在大小；我認為使用高度/寬度會比較好。」
「我們想找出產生較少尺寸的方法，目前約有 12 個。」
「如果沒有 JS，圖片的動態調整大小功能就會變得非常困難，甚至無法實現。」
「responsivebreakpoints.com 這類工具很適合 web.dev :)。」

高品質和高解析度的圖片

「如何下載壓縮圖片，且不損失 DPI 品質？」
「我們是一家文件管理公司。我們的應用程式會處理數百萬張高解析度掃描圖片，通常是 TIFF 或 PDF。」
「這很麻煩。高解析度圖片檔案是列印格式的必要條件，且必須針對網路最佳化。為網頁縮小圖片很麻煩，但如果作者只提供用於平面出版的圖片輕量檔案，就會造成重大損失。我們在提交手稿時，會提供與插圖相關的不同要求。接著，我們會使用複雜的工作流程處理這些素材。」

瀏覽器功能

「自動回應式 src 裁剪功能 ([內建]) 會非常實用，因為裁剪所有圖片至 4 種大小並編寫所有標記都非常耗時。如果我們可以上傳一張大型相片，並編寫簡單的相片標記，瀏覽器就會自動建立多個 src 屬性，這將是優異的功能。」
「就我個人而言，當 CSS 為回應式圖片設定圖片寬度 (max-width: 100%; height auto 或 height: width: 100%; height auto) 時，我很難避免頁面重新流動，尤其是與自適應圖片/圖片標記的藝術方向搭配使用時。避免這種情況的最佳方式，似乎是使用「負邊框破解」技巧來固定圖片比例，然後將圖片置於這個比例方塊中。更完善的瀏覽器支援/回應式圖片處理功能會非常有幫助！」
「請只擷取第一個影格，停用 GIF 的『自動播放』功能。」

CDN 和圖片服務

「Google 應該提供 Cloudflare 這類免費 CDN。」
「或許可以提供更多工具，讓使用者透過不同的供應商設定動態調整和 CDN。」
「單一超大尺寸的過度壓縮圖片，是一種非常實用的解決方案，而且不會增加製作成本。行動裝置需要約 1000 像素寬的圖片 (500 像素算繪寬度)，這也是大型/電腦螢幕 (非 Retina 螢幕) 所需的大小。我認為圖片大小調整 CDN 是相當糟糕的解決方案，雖然我曾在過去使用過。CMS 應處理調整大小作業，而設定太複雜的作業，單一解決方案是目前的最佳折衷。」
「CloudFlare 會自動調整圖片大小，以便最佳化使用者螢幕顯示效果。這樣一來，系統就能根據使用者的螢幕載入圖片，進而縮短載入時間。舉例來說，如果使用者使用手機，就不會以電腦版大小的背景載入。」
「Cloudflare 會在背景執行這項操作，我們只需在設定面板中勾選方塊即可。」
「我再重申一次，我能成功使用 srcset 等功能，完全是因為 Cloudinary 的簡易性。不過，Cloudinary 的費用很快就會變得非常高，這似乎是開發人員體驗中的主要缺點。」
「我們需要一種方法，以智慧方式輕鬆自動裁剪圖片，讓圖片能在不同情境中使用不同顯示比例。」
「我也會使用 Unsplash 等其他供應商提供的圖片，這些圖片的解析度、品質和壓縮程度都無法完全控制。」

CMS、平台和架構

「在使用 CMS 建構網站時，我仍難以找出使用圖片的最佳方式。作者通常會設定不同尺寸的圖片，並希望圖片不會縮小或縮放。我不確定是否可以為圖片設定寬度或高度上限」
「我過去幾個專案都使用 gatsby-image，從未失望過。」
「圖片通常是難以處理的部分，因為使用者會將圖片上傳至 CMS，而他們可能會使用任何大小和格式，有時原始圖片的圖片格式和尺寸可能無法使用。」
「圖片難以維護，因為我們的系統是自助式，因此很難新增控制項，除非系統能自動執行，且不會影響解析度。此外，我們發現圖片在行動裝置和電腦上顯示的效果不一致。」
「我協助使用者將網站 (WordPress) 最佳化。我發現圖片的最大問題是：需要依賴 CDN 或外掛程式才能建立 WebP。主題開發人員必須正確編寫 srcset/picture 程式碼。大多數延遲載入外掛程式載入速度緩慢，使用者體驗不佳。背景圖片很難延遲載入。」

成本/效益

「新做法雖然有效，但會增加網站的開發時間。」
「許多《財富》雜誌前 500 大企業都未遵循 srcset 和 WebP 等新標準，許多公司因此拒絕這項變更，認為這會造成不必要的開發成本，使用者 (使用者體驗) 並未廣泛討論或回報成效提升。反而會讓你更難從網路上儲存圖片。」
「建立及管理多種尺寸和版本的成本高昂。」
「這些檔案會佔用大量伺服器空間。」

SEO

「在可接受的圖片品質和檔案大小之間取得平衡很困難。一方面，我希望網頁能快速載入，以利於 SEO，但另一方面，品質不佳的圖片會影響 UI/UX。」

圖片在網路上的角色

「網路上有太多內容，停止使用無用的圖片，這些圖片無法強化文字內容。」
「還記得網路沒有圖片，我們會以 ASCII 藝術的形式分享自拍照的時代嗎？」

工具、指南、標準和最佳做法：不滿和要求

[一位參與者針對這項調查撰寫了網誌文章]
「這些規定似乎不斷變動。對網頁開發人員來說，這會造成極大的困擾，因為一開始儲存圖片就會耗費許多時間。我們盡可能進行最佳化，並檢查網站，幾個月後，Google 判定圖片可以再壓縮，或需要採用其他格式。這會導致我們無法為客戶提供最合適的解決方案，反而會讓雙方付出高昂的成本。部分中小企業客戶沒有預算讓我們持續修正圖片，並重新儲存符合規定的圖片。我們沒有預算在管理套裝方案中執行這項工作。為不同裝置呼叫不同圖片大小的程式碼編寫程式碼也很耗時。最好能推出一套系統，讓圖片在較長的時間內保持一致。」
「是的，我認為你在 Lighthouse 中誤解了『降低要求數量並減少檔案大小』。如果網站是透過 HTTP1.x 提供服務，那麼確實如此，但如果網站是透過 HTTP2 提供服務，那麼要求數量就沒那麼重要，如果來自相同主機名稱，甚至不成問題。我有一個精簡版網站，但我透過 HTTP2 在相同主機名稱上載了 30 個小型 WebP 檔案，總計約 35 個要求。Lighthouse 將此問題標示為「降低要求數量並減少檔案大小」問題，但實際上速度非常快，而且由於同一個主機名稱上的 HTTP2，要求數量並非問題。檔案大小確實很小 (大多數介於 1 KB 至 2 KB 以下)。我可以載入精靈，但之後需要進行更多 CSS 運算。因此，請更新 Lighthouse 中的「降低要求數量並減少檔案大小」報表，以便考量使用相同主機名稱的 HTTP2。」
「使用者很難記得要壓縮圖片。」
「跨瀏覽器行為仍無法預測，因此最簡單的解決方案通常也是最安全的。」