看看漸進式圖像和用戶感知的狀態

“漸進式影像”是近來的熱門話題。 我們經常會看到一些文章，這些文章解釋瞭如何避免在加載圖像時顯示空白區域。 Medium 和 Facebook 是應用這種模式的網站和移動應用程序的示例。

我最近寫了關於使用 SVG 作為佔位符的不同方法，今年 PerfPlanet 的性能日曆包括兩篇進一步描述 SQIP 的文章，這是一種基於模糊 SVG 的技術：使用 Intersection Observer 和 SQIP 和 SQIP 進行漸進式圖像加載 - 用於性能預覽的模糊向量。

當我第一次記錄 Medium 的圖像加載技術時，我最感興趣的是對他們的技術進行逆向工程。 我已經看到了在緩慢的飛行連接上瀏覽 Medium 的效果。 我認為儘早渲染小圖像，延遲加載並過渡到最終版本是個好主意。

我們假設這些技術提高了用戶的感知性能。 快速渲染勝過慢速渲染。 儘早將某些內容放在用戶的屏幕上，即使它不是最終內容。

我們確定嗎？

通過對 Reddit 的一些評論，我發現了很多有見地（和負面）的意見。 這是其中的兩個：

“我討厭在最後一張圖片加載之前顯示圖像模糊版本的網站。 它玩弄我的眼睛。 在我繼續閱讀之前，我必須將目光移開並偷看是否完成。 我希望有辦法禁用此功能。”
—rocky1138，黑客新聞

“人們如何得出這樣的結論，即顯示要加載的圖像的低信息版本作為佔位符會導致更快的感知加載？ 對我來說，所有這些效果看起來都是垃圾和分散注意力，根本沒有任何好處——當然不是對速度的感知。 無論如何，在沒有花哨的佔位符的情況下，無論如何，在圖像完全加載之前，我都無法理解圖像的真正含義。”
— dwb，黑客新聞

試圖找到關於用戶感知的研究

我想找到一些科學研究來支持​​這些加載圖像的技術是（或不是）有益的。 這被證明是一個挑戰。 我找不到任何研究證明在圖像加載之前顯示模糊縮略圖之類的東西可以改善用戶的感知。 然後我想到了漸進式 JPEG。

回到基礎：漸進式 JPEG

從某種意義上說，我們長期以來一直將類似的“漸進式圖像加載技術”備份到圖像中。 漸進式 JPEG 就是一個很好的例子。

漸進式 JPEG 已被提議作為圖像的一種良好做法，特別是對於在慢速網絡中使用的站點。 五年前，Ann Robson 寫了一篇鼓勵漸進式 JPEG 的帖子，她總結了它們為何優越的原因：

“漸進式 JPEG 更好，因為它們更快。 看起來更快就是更快，感知速度比實際速度更重要。 即使我們對我們試圖提供的東西很貪婪，漸進式 JPEG 也會盡快為我們提供盡可能多的東西。”

漸進式 JPEG 將圖像編碼為多次掃描。 第一次掃描以低質量渲染整個圖像，並隨著更多掃描的渲染而得到細化。 另一種方法是 JPEG 的基線模式，其中圖像從上到下進行解碼。

附帶說明一下，可以使用不同的掃描腳本自定義 JPEG 編碼。 這可用於創建以基線和漸進之間的混合模式編碼的圖像。

從用戶的感知角度來看，像 Blur-up、SQIP 等漸進式技術類似於漸進式 JPEG。 瀏覽器首先渲染一個低質量的圖像，並在加載時將其替換為最終圖像。

有趣的是，絕大多數 JPEG 圖像都使用基線模式。 根據一些消息來源，漸進式 JPEG 最多佔所有 JPEG 的 7%。 如果我們似乎同意這些技術提高了用戶的感知性能，為什麼漸進式 JPEG 沒有比基線 JPEG 更廣泛地使用？

研究

我只能找到一個名為“漸進式圖像渲染 - 好還是壞？”的研究，試圖闡明這個主題。

“當與漸進式 JPEG 方法一樣，圖像再現是一個兩階段的過程，在該過程中，最初的粗糙圖像捕捉到清晰的焦點，認知流暢性受到抑制，大腦必須稍微更加努力地工作才能理解所顯示的內容。”

根據這項研究，用戶發現處理漸進式 JPEG 更加困難，儘管乍一看我們會認為體驗更好。

我最近在一次關於 LQIP（低質量圖像佔位符）的對話中提到了這項研究。 很快，我收到了一些質疑研究嚴謹性的回复：

不過，許多人質疑這項研究的有效性。 這與我們對漸進式渲染的好處所假設的一切相反，目前還沒有人提出具有類似發現的第二次研究。 我們需要更多數據。

— Tobias Baldauf (@tbaldauf) 2017 年 12 月 9 日

這項研究非常有限且有爭議。 大規模數據來證明或反駁任何結論都是必不可少的

— Yoav Weiss (@yoavweiss) 2017 年 12 月 9 日

到目前為止，我們有一項研究受到懷疑。 我們還有什麼？ 我們可以使用現有工具來衡量感知性能作為代理嗎？

測量感知加載時間

想像一下從一個站點記錄的這兩個假設的幻燈片：

普遍的共識是，用戶會感覺到版本 B 的加載速度比版本 A 快。這是因為頁面的某些部分比版本 A 更早呈現。

在某種程度上，這種情況類似於漸進式圖像，但規模更大。 盡可能早的部分內容，即使它不是最終的。

1.2 秒的頁面加載時間告訴我們故事的一部分，但沒有描述用戶在此期間看到的內容。 如今，我們使用速度指數等指標來評估頁面加載的速度。 速度指數衡量頁面中沒有視覺完成的區域。 這是在間隔拍攝的幾個屏幕截圖上完成的。 數字越低越好。

如果我們考慮漸進式圖像加載技術，速度指數將如何隨著圖像加載而變化？ 如果我們使用低質量的佔位符，該區域是否會被視為“視覺完成”？

最初，速度指數測量了比較直方圖距離的進度，每種原色（紅、綠、藍）各一個。 這稱為平均直方圖差異。 目標是防止像重排這樣的更改（頁面上的所有元素都移動幾個像素）對計算產生重大影響。 有關該算法的更多信息，請閱讀 Speed Index 文檔的測量視覺進度部分。

我決定針對顯示低質量佔位符的頁面嘗試 Webpagetest（請參閱 WebPageTest 的報告）：

我們可以注意到圖像在第 8 秒到第 10 秒之間加載。 模糊佔位符將視覺完整性百分比從 75% 提高到 83%。 加載最終圖像會將其從 83% 提高到 93%。

我們看到佔位符有助於頁面的視覺完整性，由速度指數衡量。 我們還可以觀察到佔位符並不能算作一個完全視覺完整的區域。

速度指數並不是我們可以用來衡量頁面呈現速度的唯一指標。 Chrome 開發者工具包括一個執行性能審計的選項。 轉到Audits → Perform an audit → Check 'Performance' → Run audit 。

運行審計會生成如下報告：

報告的指標之一是“感知速度指數”。 在此運行中，值為4,245 。 但是這個詞到底是什麼意思？ 和Webpagetest的“速度指數”一樣嗎？

Speed Index 測量像素相似度的方法，也稱為“平均直方圖差異”，有一些缺點。 MHD 不捕捉形狀、顏色或物體相似性的視覺感知。

在大多數情況下，這在運行視覺完整性評估時不會有很大的不同。 在實踐中，速度指數和感知速度指數具有很高的相關性：

“在我們進行的大規模實證研究中（使用通過 WebPagetest 收集的 500 多個 Alexa 頂級移動網頁視頻），我們發現 SI 和 PSI 呈線性相關（準確地說是 0.91）。” — 用於衡量首屏 Web 性能的感知速度指數 (PSI)

感知速度指數

根據 Google 的 Lighthouse 文檔，感知速度指數是使用名為 Speedline 的節點模塊計算的。 這個包計算感知速度指數，基於與原始速度指數相同的原理，但它使用 SSIM 而不是直方圖距離計算幀之間的視覺進展。

SSIM（結構相似度）用於測量兩幅圖像之間的相似度。 該方法試圖模擬人類如何感知圖像，並確實捕獲形狀、顏色和對象的相似性。 SSIM 還有其他有趣的應用：其中之一是優化圖像壓縮設置，例如 cjpeg-dssim，它選擇最高的 JPEG 壓縮級別並生成具有足夠接近 SSIM 的圖像。

您可以在下面看到使用 Primitive 創建的 SVG 圖像的 Image SSIM JS 分數。 我們使用的形狀越多，它就越接近原始圖像（SSIM = 1）。

SSIM 的最新替代品是 Butteraugli（由 Guetzli 使用，Google 的感知引導 JPEG 編碼器）和 SSIMULACRA（由 Cloudinary 使用）。

結論

沒有簡單的方法來綜合用戶對圖像加載時間的感知。 我們被直覺驅動，即越早顯示越好，即使它不是最終內容，儘管有些用戶會不同意。

作為開發人員，我們需要衡量性能。 這是我們可以設定目標來改進它的唯一方法，並且知道我們什麼時候沒有達到性能預算。 押注漸進式圖像加載的優勢在於，我們可以使用基於用戶感知的工具對其進行衡量。 它們給了我們一個分數，它們是可重複的和可擴展的。 它們適合我們的工作流程和工具，並且會一直存在。

作為 Web 開發者，我們應該更關心我們構建的網站的加載體驗。 很高興我們現在擁有 WebPageTest 和 Lighthouse 等工具，可以幫助我們輕鬆衡量使用漸進式圖像加載技術的效果。 別再找藉口！