與 Addy Osmani 合作的 Smashing Podcast 第 39 集：圖像優化
已發表: 2022-03-10本集得到了 Storyblok 親愛的朋友的大力支持，他們幫助人們在任何平台上提供強大的內容體驗：企業網站、電子商務網站、移動應用程序和屏幕顯示。 謝謝！
在今天的 Smashing Podcast 中，我們談論的是圖像優化。 對於 2021 年的高性能圖像，我們應該遵循哪些步驟？ 我與專家 Addy Osmani 進行了交談以找出答案。
顯示註釋
- “圖像優化”，Addy Osmani
- 艾迪在推特上
- 阿迪的個人網站
每週更新
- 認識 :has，一個原生 CSS 父選擇器（以及更多）
由阿德里安·貝斯撰寫 - 我最近發現的三個前端審計工具
由 Stefan Judis 撰寫 - 有用的前端樣板和入門套件
由科西瑪·米爾克撰寫 - 網頁設計做得很好：利用音頻
弗雷德里克·奧布萊恩 (Frederick O'Brien) 撰寫 - 當 CSS 不夠用時：可訪問組件的 JavaScript 要求
斯蒂芬妮·埃克斯寫的
成績單
Drew McLellan：他是一名工程經理，負責 Google Chrome，他的團隊專注於速度，幫助保持網絡快速。 致力於開源社區，他過去的貢獻包括 Lighthouse、Workbox、Yeoman、Critical 和做 NVC。 所以我們知道他知道如何優化網絡性能。 但是你知道他因為筆誤而想要獲得奧斯卡最佳女配角獎嗎？ 我的粉碎朋友，請歡迎 Addy Osmani。 嗨，艾迪。 你好嗎？
Addy Osmani：我太棒了。
德魯麥克萊倫：很高興聽到。 我今天想和你談談網絡上的圖像。 在過去的幾年裡，這個領域發生了驚人的變化和創新，而您剛剛寫了一本非常全面的書，內容涉及 Smashing 的圖像優化。 這個時候想“現在是出一本關於圖像優化的書的時候了”的動機是什麼？
Addy Osmani：這是一個很好的問題。 我想我們知道，幾十年來圖像一直是網絡的一個非常關鍵的部分，我們的大腦能夠比文本更快地解釋圖像。 但隨著時間的推移，這個整體主題會變得越來越有趣和微妙。 我總是告訴人們這可能是我的第三或第四本書。 我從來沒有刻意去寫一本書。
Addy Osmani：我開始這本書時寫了一篇關於圖像優化的文章，然後隨著時間的推移，我發現我不小心寫了一整本關於它的書。 我們在這個項目上工作了大約兩年。 即使在那個時候，該行業一直在發展瀏覽器，圍繞圖像和圖像格式的工具也在不斷發展。
Addy Osmani：所以我寫這本書是因為我發現自己很難掌握所有這些變化。 我想，“我將成為一名優秀的網絡公民，並嘗試在一個地方跟踪我學到的所有內容，以便其他人可以利用它。”
Drew McLellan：我認為這是其中之一，在瀏覽器中進行了大量性能優化，這是一個快速變化的領域，不是嗎？ 當你學到的一種技術是最新的和最佳實踐時，就會發生一些技術轉變，然後你會發現它實際上是一種反模式，你不應該這樣做。 並且試圖保持你的知識並確保你正在閱讀正確的文章並學習正確的東西並且你沒有閱讀兩年前的東西是非常困難的。
Drew McLellan：因此，從權威來源將所有內容收集在一本經過充分研究的書中真是太棒了。
阿迪奧斯馬尼：是的。 即使從作者的角度來看，最有趣的事情之一，也許是我們編輯團隊壓力最大的事情之一就是我會交出一章並說它已經完成。 然後兩週後，瀏覽器會發生一些變化，我會說，“哦，等等。 我必須在最後一刻再做出改變。”
Addy Osmani：但圖像景觀已經發生了很大變化，即使在去年也是如此。 我們已經看到 WebP 支持終於在大多數現代瀏覽器中越過了終點線。 AVIF 圖像支持在 Chrome、Firefox、JPEG XL、延遲加載。 總的來說，我們已經看到瞭如何在瀏覽器中非常具體地使用網絡上的圖像的增強功能。 但同樣，人們需要掌握很多東西。
Drew McLellan：有些人可能會認為圖像優化是一個非常老套的話題。 在我們職業生涯的某個階段，我們都學會瞭如何從我們的圖形軟件中導出網頁。 我們中的一些人可能習慣於獲取這些導出的圖像並通過 ImageOptim 之類的工具運行它們。
Drew McLellan：所以我們可能知道當它是照片圖像時我們應該選擇 JPEG，而當它是基於圖形的圖像時我們應該選擇 PNG，然後認為，“好吧，就是這樣。 我知道圖像優化，我已經完成了。” 但實際上，這些事情只是賭注，不是嗎？
Addy Osmani：是的，他們是。 我認為，隨著時間的推移，我們即使在不同的環境中也能顯示更詳細、更清晰的圖像和圖像，這取決於你是否關心藝術指導。 我認為需要弄清楚如何讓這些圖像看起來像最終用戶想要的那樣漂亮，同時牢記他們的環境、設備限制、網絡限制是一個難題，而且我知道很多人仍然知道這一點與之鬥爭。
Addy Osmani：因此，在考慮圖像並對其進行更精細的處理時，不僅僅是“嘿，讓我們使用 JPEG”或“讓我們使用 PNG”，我認為這有幾個方面的價值牢記。 第一個只是一般的壓縮。 您提到了 ImageOptim，我們中的很多人都習慣於將圖像拖到一個地方，然後從它的後面得到一些更小的東西。
Addy Osmani：現在，談到壓縮，我們通常談論不同的編解碼器。 編解碼器是一種壓縮技術，通常具有用於編碼文件的編碼器組件和用於解碼和解壓縮它們的解碼器組件。 當您決定是否使用某些東西時，您通常需要考慮您使用的照片或圖像是否適合您使用有損壓縮方法或無損壓縮方法。
Addy Osmani：以防萬一人們對這些概念不太熟悉，無損方法是在解壓縮的最後重現完全相同的文件。 因此，您在質量方面並沒有真正失去太多。 無損是更多地將您的圖像通過傳真機。 你得到一份原件的傳真，它不會是原始文件。 那裡可能有一些不同的工件。 它可能看起來略有不同。 但總的來說，你壓縮的越多，你通常損失的質量就越多。
Addy Osmani：因此，對於所有這些現代圖像編解碼器，他們試圖了解您可以擠出多少質量，同時仍保持相對不錯的文件大小，具體取決於用例。
Drew McLellan：所以說真的，從技術的角度來看，你有一個源圖像，然後你就有了目標文件格式。 但是將一個變成另一個的過程是有爭議的。 只要你有一個符合要求的文件，你怎麼做取決於一個可以有很多不同實現的編解碼器，有些會比其他的更好。
Addy Osmani：當然。 絕對地。 而且我認為，再次回到我們從 JPEG 和 PNG 開始的地方，人們可能知道 JPEG 是為有損壓縮照片而創建的。 您通常會從它的背面得到一個較小的文件，它有時可能會有不同的條帶偽影。 PNG 最初是為無損壓縮而創建的，在非攝影圖像上效果很好。
Addy Osmani：但從那以後，事情發生了變化。 大約在 2010 年左右，我們開始獲得對 WebP 的支持，它本應取代 JPEG 和 PNG，並在壓縮方面略勝一籌。 但從那時起，桌面上的圖像格式和選項的數量就猛增了。 我認為事情總體上朝著一個好的方向發展，特別是對於像 AVIF 和 JPEG XL 這樣的現代格式。 但我們花了一段時間才到這裡。 即使在所有瀏覽器上獲得 WebP 支持也需要相當長的時間。
Addy Osmani：我認為最終影響它的是確保開發人員一直在要求它，他們渴望能夠從這些現代格式中獲得更好的壓縮，並且渴望在瀏覽器之間具有良好的兼容性對於這些事情，也是。
德魯麥克萊倫：是的。 WebP 對我來說似乎真的很有趣，因為除了在格式中提供無損和有損壓縮之外，我們顯然還可以大大減少文件大小。 並且有很好的瀏覽器支持，我們看到谷歌和 Netflix 等大公司以及各種大公司的採用。
Drew McLellan：但我對行業的看法是，我們在基層看不到同樣的吸收。 WebP 還在等待它的到來嗎？
Addy Osmani：我想我會說 WebP 即將到來。 很多人一直在等待 Safari 和 WebKit 支持實現，而我們終於有了。 但是當我們考慮新的圖像格式時，理解支持的真正含義是非常重要的。 瀏覽器支持解碼這些圖像。 我們還需要非常好的工具支持，以便無論您是在節點環境、圖像 CDN 中，還是在 CMS 中，您都可以使用這些圖像格式。
Addy Osmani：我記得很多年前 WebP 第一次問世的時候。 早期採用者會遇到這樣一個問題，即您將 WebP 文件保存到桌面，然後突然，“哦，等等。 我需要把它拖到我的瀏覽器中查看嗎？”或者，“如果我的用戶正在下載 WebP，他們會卡住並想知道發生了什麼嗎？”
Addy Osmani：因此，我認為，確保在操作系統級別以及其他環境中對圖像格式提供相當全面的支持對於圖像格式的起飛非常重要。 對於提供圖像的人來說，稍微考慮一下這些用例也很重要，這樣，如果我正在保存或下載文件，您就會嘗試將其轉換為人們通常可以輕鬆共享的便攜式格式。 我認為這就是至少在 iOS 上，iOS 支持加息和連字符的地方。 並在必要時將內容轉換為 JPEG，以便人們共享它們。
Addy Osmani：因此，我認為，考慮這些類型的用例，我們可以確保用戶在我們提供更好的壓縮效果的同時不會丟失，這一點很重要。
Drew McLellan：我運行了一個幻燈片共享服務，你可以想像，它處理數十萬張圖像。 當我研究 WebP 時，可能是三年前，我主要是在尋找一種降低 CDN 帶寬成本的方法，因為如果您提供較小的文件，則提供服務的費用會減少。 但是，雖然我仍然需要一個完整的圖像，一種傳統的圖像格式，但我的計算表明，存儲整個其他圖像集的成本超過了提供較小文件的好處。 所以我們到了 2021 年。我現在應該重新考慮這個決定嗎？
Addy Osmani：我認為這是一個非常重要的考慮因素。 有時，當我們談論你應該如何接近你的形象策略時，很容易給人們一個高層次的回答，“嘿，是的。 只需生成五種不同的格式，就可以無限擴展。” 並非總是如此。
Addy Osmani：我認為，當您必須牢記存儲時，有時要牢記什麼是最好的、最常見的服務於您的用戶的分母。 這些天來，我實際上會說 WebP 是值得考慮的共同點。 對於習慣於使用圖片標籤有條件地為人們提供不同格式的人，通常您會使用 JPEG 作為主要的後備。 也許這些天實際上使用 WebP 作為大多數用戶的後備是可以的，除非你有使用非常非常舊的瀏覽器的人。 而且我認為這些天我們看到的要少得多。 但是你肯定有一些靈活性。
Addy Osmani：現在，如果你想要面向前方，我會說選擇一種你認為非常有效的格式。 如果您可以以可擴展且靈活滿足您需求的方式處理存儲，我想說人們應該做的是考慮 JPEG XL。 從技術上講，它還沒有在瀏覽器中發布。 當它這樣做時，JPEG XL 對於有損或無損用例中的許多照片或非照片用例來說應該是一個非常好的選擇。 它可能會比 WebP V1 好得多。 所以這是一個地方。
Addy Osmani：我認為如果你需要達到非常低的比特率，AVIF 可能會更好。 也許您非常關心帶寬。 也許您不太關心圖像保真度。 在這些比特率下，我可以想像它看起來比一些替代品更清晰。 在我們擁有 JPEG XL 之前，我會嘗試查看您的分析並了解您是否可以提供 AVIF。 否則，我會專注於那個 WebP。 如果您是分析人員，我想大多數人都可以使用 WebP，並且您不太關心廣域或文本覆蓋，在 WebP 中染色體採樣可能不完美的地方。 這當然是值得牢記的。
Addy Osmani：所以我會盡量記住，不會有一種適合所有人的尺寸。 就我個人而言，這些天來，我不太擔心存儲、出口和帶寬成本，只是因為我使用了圖像 CDN。 我很高興地說我個人使用 Cloudinary。 我們在我工作的地方使用了許多不同的圖像 CDN。 但我發現不必擔心處理圖像管道的維護成本，處理我將如何支持的問題，“哦，嘿，這是另一種圖像格式或新類型的後備或新的 Web API ，”這對投資於只為我照顧它的東西來說是一個很好的好處。
Addy Osmani：然後我的用例的總體成本還可以。 但我完全可以想像，如果您以這種規模運行幻燈片服務，那也不一定是一種選擇。
德魯麥克萊倫：是的。 所以我想回到這些即將到來的未來格式中。 但我認為這值得深入研究，因為使用任何類型的性能工具、Lighthouse 或 WebPageTests，如果我們中的任何人通過它運行我們的網站，它會建議的關鍵之一是我們使用 CDN 來存儲圖像。 對於非常大的公司來說，這是一件非常現實的事情。 它是現實的並且在人們構建小型網站和應用程序的範圍內，還是真的像聽起來那麼容易？
Addy Osmani：我認為人們應該問的問題是，“你用圖像做什麼？” 如果你只有幾張圖片，如果你正在構建一個博客並且你添加的圖片相對簡單，你沒有成百上千張圖片，你可能只需要接近這個就可以了在構建時，以非常靜態的方式安裝幾個 NPM 包。 也許你只是在使用夏普。 這在很大程度上照顧了你。
Addy Osmani：有一些工具可以幫助您生成多種格式。 它確實會稍微增加你的構建時間，但這對很多人來說實際上可能沒問題。 然後對於那些確實希望能夠利用多個 -
Addy Osmani：對於那些確實希望能夠利用多種格式的人來說，他們不想處理太多的工具細節，並且希望能夠獲得一個非常豐富的響應式圖像或故事，我會說嘗試圖像 CDN。 出於成本考慮，我個人最初對將其用於個人項目非常謹慎，然後隨著時間的推移，當我查看我的賬單時，我實際上意識到這可以節省我的時間，否則我會自己投資解決這些問題。 我不知道過去您必須編寫多少自定義腳本來處理您的圖像，但我意識到如果我可以每月通過這些不同的 npm 包為自己節省至少幾天的調試時間，那麼成本有點照顧我節省的時間，所以沒關係。
Addy Osmani：但是，如果您要擴展到 100 個或 1000 個或數百萬個圖像，並且這不是您的收入必然涵蓋的東西，或者您不准備支付的東西，您確實需要考慮替代策略。 而且我認為我們很幸運，我們今天可用的工具有足夠的靈活性，可以朝這兩個方向發展，我們做一些更多的定制，我們自己解決或滾動我們自己的圖像 CDN 或者我們投資一些稍微商業化的東西。 而且我們處於一個我會說對於某些用例的地方，是的，您可以使用圖像 CDN，而且價格實惠。
Drew McLellan：我想，其中一種指導原則就是始終保持敏捷並為變化做好準備。 您可能會開始使用圖像 CDN 來根據請求為您動態轉換圖像，如果這到了在成本方面不可持續的地步，您可以查看另一種解決方案並讓您的代碼庫處於某種狀態用一種解決方案替換另一種解決方案很容易。 我認為一般和任何你依賴第三方服務的地方，這是一個很好的原則，不是嗎？ 所以這些即將到來的圖像格式，你提到了JPEG XL。 什麼是 JPEG XL？ 它來自哪裡？ 它對我們有什麼作用？
Addy Osmani：這是一個很好的問題。 所以 JPEG XL 是下一代圖像格式，它應該是通用的，它是來自 JPEG 委員會的編解碼器。 它起源於谷歌的圖片格式，然後是 Cloudinary 的 FUIF 格式。 多年來，這種努力已經包含了很多格式，但它已經不僅僅是其各個部分的總和，JPEG XL 的一些好處是它非常適合高保真度圖像，非常適合無損，它支持漸進式解碼，無損JPEG轉碼，而且它也有點大驚小怪和免版稅，這絕對是一個好處。 我認為 JPEG XL 可能是一個非常強大的候選者。 我們之前討論過，如果你只選擇一個，你會用什麼？ 我認為 JPEG XL 有潛力成為那個。
Addy Osmani：我也不想過度承諾，我們還處於瀏覽器支持的早期階段。 所以我認為我們真的應該拭目以待，試驗和評估它在實踐中的表現如何，並滿足人們的期望，但我認為 JPEG XL 在有損和無損情況下都有很大的潛力。 現在，我相信 Chrome 可能在支持方面是最先進的，但我也看到 Mozilla 和其他瀏覽器對此肯定感興趣，所以我對 JPEG XL 的未來感到興奮。 如果我們要說，人們感興趣的更短期限是什麼？ 當然還有AVIF。
Drew McLellan：告訴我們關於 AVIF，這是我不熟悉的另一個。
阿迪·奧斯馬尼：好的。 因此，我們前面提到過，如果您需要低比特率並且您更關心帶寬而不是圖像保真度，那麼 AVIF 可能是一個更好的選擇，作為一般原則，AVIF 確實在低保真高吸引力壓縮方面處於領先地位。 和 JPEG XL，它應該在中高保真度方面表現出色，但它們本身的格式略有不同。 我們正處於 AVIF 獲得越來越好的瀏覽器支持的地方，但讓我退後一步，多談談格式。 所以 AVIF 本身是基於開放媒體聯盟標準化的 AV1 視頻編解碼器，它試圖讓人們在我們之前討論的 JPEG 和 WebP 上獲得顯著的壓縮增益。 雖然您可以從 AVIF 獲得的確切節省取決於內容和您的質量目標，但我們已經看到很多情況下，與 JPEG 相比，它可以提供超過 50% 的節省。
Addy Osmani：它有很多很好的功能，它能夠為您提供容器支持，以支持高動態範圍和寬色域、膠片顆粒合成等新功能。 再次，類似於談論面向前方，圖片標籤的好處之一是您可以立即為用戶提供 AVIF 文件，並且在不一定支持的情況下，它仍會退回到您的 WebP 或 JPEG . 但是回到您關於 Photoshop Save For Web 的示例，您可以使用 500 KB 大小的 JPEG，嘗試拍攝與 Photoshop Save For Web 和使用 AVIF 相似的質量，我會說您可能能夠獲得該文件大小約為 90 KB，100 KB，因此節省了很多，而質量沒有明顯的損失。
Addy Osmani：其中一件好事是，理想情況下，您不會在任何具有豐富細節的圖像中看到太多的紋理損失。 因此，如果您有森林或露營或任何此類事物的照片，它們應該仍然看起來非常豐富 AVIF。 所以我對 AVIF 的發展方向感到非常興奮。 我確實認為在工具支持方面需要做更多的工作。 所以我前幾天發布了一條關於這個的推文，我們現在有很多使用 AVIF 的選項，對於單個圖像，我們有 Squoosh，squoosh.app，它是由另一個團隊在 Chrome 中編寫的，所以喊感謝 Surma 和 Jake 在 Squoosh 上的工作。 Avif.io 為今天嘗試使用 AVIF 的人們提供了許多不錯的選擇，無論他們關注什麼技術堆棧，Sharp 也支持 AVIF。
Addy Osmani：但通常你會想到我們處理圖像的其他地方，無論是在 Figma、Sketch、Photoshop 還是其他地方，我想說我們仍然需要在以下方面做一些工作AVIF 支持在那裡，因為它需要無處不在，讓開發人員和用戶真正感覺到它已經著陸並回家了。 這是我們目前在 Chrome 中開發 AVIF 的團隊關注的領域之一，試圖確保我們可以將工具帶到一個非常好的地方。
Drew McLellan：所以我們現在有了 HTML，即圖片元素，它為我們提供了比傳統圖像標籤更大的靈活性。 雖然圖像標籤也有很長的路要走，不是嗎？ 但是我們看到圖片被添加了，它與原生視頻標籤大約在同一時間，我認為是在原始的一批 HTML5 更改中。 這使我們能夠指定多個來源，對嗎？
Addy Osmani：是的，沒錯。
Drew McLellan：因此，您可以列出不同格式的圖像，瀏覽器會選擇它支持的一種，這使我們能夠立即進行相當多的實驗，而無需過多擔心會破壞舊瀏覽器的用戶。
Addy Osmani：當然。 我認為這是在我們考慮方向的用例之外使用圖片標籤的最大好處之一，只是能夠為人們提供圖像並讓瀏覽器瀏覽潛在來源列表並查看，好吧，好吧，我將使用該列表中我理解的第一個，否則我會退回，這對人們來說是一個非常強大的功能。 我想同時，我也聽到一些人表達了一些擔憂或擔憂，當我們嘗試支持多種格式時，我們正在重新生成非常大的標記塊，並且您考慮到這些格式的不同大小和突然它變得有點笨重。
Addy Osmani：那麼我們還有其他方法可以解決這些問題嗎？ 我不想在圖像 CDN 上向人們推銷太多，我希望他們獨立存在。 但這是一個名為內容協商的想法實際上可以為您提供有趣路徑的地方之一。 所以，我們已經討論了一些關於圖片標籤的內容，您必須在其中生成一堆不同的資源並決定優先順序，正確的，額外的 HTML。 對於內容協商，它說的是讓我們在服務器上完成所有這些工作。 因此，客戶端可以通過接受 HTTP 標頭通過 MIME 類型列表預先告訴服務器它支持哪些格式。 然後服務器可以完成所有繁重的工作，生成和管理最終資源，並決定將哪些資源發送給客戶端。 這裡的強大功能之一是，如果您使用的是圖像 CDN，則可以指向單個資源。
Addy Osmani：所以也許如果我們有一個像puppy.JPEG 這樣的小狗圖像，我們可以給人們一個puppy.JPEG 的URL，如果他們的瀏覽器支持WebP 或者它支持AVIF，那麼服務器就可以非常聰明地提供正確的服務根據他們的支持情況向這些用戶提供圖像，但在其他情況下無需您自己做大量額外工作即可退回。 現在，我認為這是一個強有力的想法。 您可以在服務器上做很多事情，我們有時會談論不是每個人都能獲得真正強大的網絡質量，您的有效連接類型可能會因您所在的位置而異。
Addy Osmani：即使住在矽谷，我也可能從咖啡店步行到酒店，或者我可能在車裡，我的 wifi 質量或信號可能不是那麼好。 因此，在這裡您可以訪問其他 API，如果用戶選擇了數據節省，其他想法（如 Save-Data 客戶端提示）可能能夠為人們提供更小的資源。 所以我們可以在服務器端做很多有趣的事情，我確實認為我們應該繼續推動這些想法，找到一個很好的平衡，讓那些習慣於做市場路徑的人得到所有的靈活性。想要更神奇的解決方案的人也有一些選擇。
Drew McLellan：這種數據保護方法的概念是我首先從您的書中了解到的。 我的意思是，讓我們再深入一點，因為這很有趣。 因此，您說的是瀏覽器能夠發出信號，表示希望減少數據體驗，因為它可能處於計量連接或電池電量不足之類的情況下。
阿迪·奧斯馬尼：沒錯。 確切地。 我一直在正常旅行或之前旅行，那時我們會旅行更多，我經歷過世界上很多地方或我的網絡質量可能非常差或非常不穩定的情況，甚至開放啟動網頁可能是令人沮喪或困難的經歷。 我可能正在查找菜單，如果我看不到他們提供的美味食物的圖片，我可能會去我可以去的地方，或者我可能會，我不知道，給自己做點食物。 但我認為數據保護程序的一個有趣之處在於它可以讓您了解用戶的偏好。 因此，如果作為用戶，我知道我的網絡連接很困難。 我可以說：“好吧，我將在瀏覽器中選擇進入數據保護模式。”
Addy Osmani：然後作為開發人員，你可以用它作為一個信號，說：“好吧，好吧，用戶有點受限，也許我們會在他們瀏覽小得多的圖像或質量低得多的圖像時瀏覽他們。” 但是他們仍然可以看到一些圖像，這比他們等待很長時間才能提供更豐富的東西要好。 這些類型的信號的其他好處是您可以將它們用於有條件地提供媒體。 因此，也許在某些情況下，文本是該頁面中最重要的內容，如果您發現用戶處於某種受限環境中，也許您可以關閉這些圖像。 我只會花 30 秒在這上面，但你真的可以把這個想法推向極端。 使用 Save-Data 可以做的一些有趣的事情甚至可能是關閉在 JavaScript 中實現的非常昂貴的功能。
Addy Osmani：如果您有某些組件被認為是可選的，那麼如果它們只是增強體驗，則不一定需要將它們發送給所有用戶。 您仍然可以為每個人提供非常核心、小型、快速的體驗，然後為擁有更快連接或設備的人添加一些漂亮的糖霜。
Drew McLellan：潛在地，我猜它可能會影響分頁，你可以在一頁上返回 10 個結果而不是 100 個以及類似的東西。 那裡有很多有趣的功能。 我認為我們都熟悉準備新網站、優化所有圖像、將其交給客戶、給他們一個 CMS 來管理內容並發現他們只是用圖像優化不佳。 我的意思是，我想，圖像 CDN 將是一個非常方便的解決方案，但是還有其他解決方案嗎，CMS 可以在服務器上做些什麼來幫助解決這個問題，或者圖像 CDN 可能只是怎麼走？
Addy Osmani：我認為，在嘗試讓每個人優化他們的圖像至少六七年之後，我們發現這是一個難題，其中一些參與圖片的人可能在技術上稍微更精通並且可能更舒適的設置建立自己的工具或運行 Lighthouse 或嘗試其他工具，讓他們知道是否有改進的機會。 如果您有機會進一步優化或提供合適尺寸的圖像，我希望看到人們一直使用 Lighthouse 之類的東西來捕捉，但除此之外，有時我們會遇到上傳圖像的人可能不會的用例甚至必須了解他們上傳的資源的成本。 這通常是我們遇到的問題，我會道歉，我不會過多地大聲疾呼，但即使是在 Google 博客上，我們也會遇到這種情況。
Addy Osmani：每隔幾週在 Google 博客上，我們就會有人上傳一個非常大的 20 或 30 兆字節的動畫 GIF。 而且我不希望他們知道這不是一個好主意，他們試圖讓文章看起來很酷，非常吸引人和互動，但這些觀眾不一定會知道去運行工具或使用 ImageOptim或者使用這些其他工具中的任何一個，並為他們記錄，以便他們檢查它們，當然是一種選擇。 但是，能夠自動解決問題，我認為非常引人注目，並幫助我們始終如一地達到我們希望平衡所有 CMS 用戶的需求的地方，無論他們是技術性的還是非技術性的，以及作為我們用戶的需求。
Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.
Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? 我們可以做什麼？
Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.
Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.
Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.
Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.
Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.
Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.
Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?
Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.
Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.
Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.
Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.
Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.
Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.
Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?
Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.
Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?
Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.
Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.
Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?
Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.
Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.
Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.
Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.
Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?
Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?
Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?
Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.
Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.
Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.
Addy Osmani：所以如果我想訪問一個食譜網站，我可能會關心那個食譜的外觀，所以我們關心的是確保我可以看到這個食譜的大英雄形象。 現在，LCP 元素可以隨著時間而改變。 很有可能在加載的早期，最大的東西可能是標題，但隨著頁面的繼續加載，它實際上可能最終成為更大的圖像或某種海報。
Addy Osmani：因此，當您嘗試優化最大內容的繪畫時，您可以做四件事。 第一件事是確保您儘早請求您的關鍵英雄形象。 通常，我們在頁面中有許多重要的東西。 我們要確保我們可以渲染主頁面的內容和佈局。
Addy Osmani：對於佈局，通常我們談論的是 CSS。 因此，您可能在頁面中使用關鍵 CSS、內聯 CSS，希望避免出現渲染阻塞的情況，但是當涉及到您的圖像時，理想情況下您應該儘早請求該圖像。 考慮到我們現在很多人都依賴於框架，也許這只是確保瀏覽器可以儘早在頁面中發現該圖像。
Addy Osmani：如果你不一定要使用 SSR，服務器端渲染，如果你正在等待瀏覽器發現你的一些 JavaScript 包，你的組件的包，無論你有一個用於你的英雄圖像或產品圖像的組件，如果瀏覽器必須等待獲取、解析、執行、編譯和執行所有這些不同的文件才能發現圖像，這可能意味著您最大的內容圖像需要一些時間才能被發現。
Addy Osmani：現在，如果是這種情況，如果您發現自己在一個請求圖像的地方很晚，您可以利用稱為鏈接 rel preload 的瀏覽器功能來確保瀏覽器可以儘早發現該圖像盡可能。 現在，預加載是一項非常強大的功能。 這也是你需要非常小心的一個。 這些天來，很容易到達一個地方，也許你聽說我們建議為你的鑰匙預裝——
Addy Osmani：也許您聽說我們建議為您的關鍵英雄圖像、關鍵腳本和關鍵字體進行預加載。 它變得非常龐大，試圖確保您以正確的順序對事物進行排序。 因此，LCP 圖像絕對是值得牢記的一個關鍵位置。
Addy Osmani：另一件事，正如我提到的四件事，另一件事是確保您使用源集和高效的現代圖像格式。 我認為源集真的很強大。 我還看到有時人們在使用它時，他們會嘗試過度補償，並且可能會為每種可能的分辨率提供 10 個不同版本的圖像。 至少在一些研究中，我們傾向於發現，除了三幅圖像之外，用戶很難分辨出圖像質量、清晰度和細節方面的差異。 所以DPR capping，device pixel ratio capping，當然是一個值得牢記的想法。
Addy Osmani：對於現代圖像格式，我們之前討論過格式，但請考慮您的 WebP、AVIF、JPEG XL。 避免浪費像素。 制定良好的質量策略非常重要。 而且我認為在很多情況下，即使是默認質量有時也可能太多了。 所以我會嘗試降低你的比特率，降低你的質量設置，看看你可以在保持清晰度的同時為你的用戶做多遠。
Addy Osmani：然後當我們談論加載時，圖像標籤在過去幾年中已經發展到支持的其他事情之一就是延遲加載。 因此，通過加載等於延遲，您不再需要使用 JavaScript 庫來為您的圖像添加延遲加載。 你只要把它放到你的圖像上。 在 chromium 瀏覽器和 Firefox 中，您將能夠延遲加載這些圖像，而無需使用任何第三方依賴項。 這也很好。
Addy Osmani：所以，我們已經有了延遲加載。 我們已經獲得了對同步解碼等其他功能的支持，但我將繼續進行下去，并快速討論其他兩個核心生命體徵指標。
德魯麥克萊倫：去吧，是的。
Addy Osmani：所以，擺脫佈局變化。 沒有人喜歡在他們的頁面上跳躍的東西。 我覺得，我最大的挫折之一是我打開了一個網頁。 我將手指懸停在我想點擊的按鈕上，然後突然出現一堆沒有尺寸設置或其他東西的廣告或圖像。這會導致非常不愉快的體驗。
Addy Osmani：所以累積佈局轉變試圖衡量內容的不穩定性。 很多時候，推動佈局轉變的常見因素是頁面上沒有設置尺寸的圖像或其他元素。 我認為這是人們通常可以直接設置圖像尺寸的地方之一。 也許這不是我們歷史上做過的事情，但肯定值得花時間去做。 在燈塔之類的工具中會嘗試幫助您收集，例如您頁面上需要尺寸的圖像列表是什麼？ 所以你可以去，你可以設置它們。
Drew McLellan：我想說，這是一個非常有趣的觀點，因為當響應式網頁設計成為一件事時，我們都瀏覽了我們的網站並剝離了圖像尺寸，因為我們可以使用的工具來完成這項工作需要我們沒有我們的圖像沒有高度和寬度屬性。 但現在這是個壞主意，不是嗎？
Addy Osmani：舊的又是新的。 我會說絕對值得在您的圖像上設置尺寸。 為您的廣告、您的眼睛框架以及任何可能改變尺寸的動態內容設置尺寸都值得設置尺寸。
Addy Osmani：對於那些正在構建真正有趣的體驗的人來說，那裡是錯誤的短語，真正有趣的佈局體驗，也許你需要在響應卡等方面做更多的工作； 我會考慮使用 CSS 縱橫比或縱橫比框來保留您的空間。 這也可以補充這些圖像的尺寸設置，以確保在您嘗試避免佈局變化時盡可能固定。
Addy Osmani：最後，最後一個 Core Web Vital 是第一個輸入延遲。 這是人們在談到圖像時不一定總是想到的事情。 因此，圖像實際上有可能在頁面加載時阻塞用戶的帶寬和 CPU。 它們可能會妨礙其他關鍵資源的加載方式，特別是在連接速度非常慢或可能導致帶寬飽和的低端移動設備上。
Addy Osmani：所以第一次輸入延遲是一個核心 Web Vital 指標，它捕捉用戶對網站交互性和響應能力的第一印象。 因此，通過減少主線程 CPU 使用率，您的第一次輸入延遲也可以最小化。 所以一般來說，只要避免可能導致網絡爭用的圖像。 他們沒有渲染阻塞。 但它們仍然會間接影響您的渲染性能。
Drew McLellan：我們可以對圖像做些什麼來阻止它們的渲染阻塞？ 我們能否在初始階段以某種方式減輕瀏覽器的負載，以使我們能夠更快地進行交互？
Addy Osmani：我認為現在越來越重要的是要很好地理解正確的最佳圖像序列以在首屏顯示某些東西。 我知道首屏是一個重載的術語，但就像在用戶的第一個視口中一樣。 很多時候，我們最終可能會嘗試請求大量資源，其中一些是圖像，對於用戶立即看到的內容來說並不是真正必要的。 這些往往是在頁面生命週期後期加載的絕佳候選者，適合延遲加載的好東西。 但是，如果您要請求大量圖像，例如很早之前的整個隊列，則可能會產生影響。
德魯麥克萊倫：是的。 所以，我的意思是，你提到了延遲加載圖像，我們在歷史上需要一個 JavaScript 庫來完成，我認為這有其自身的挫折，因為瀏覽器優化加載圖像的歷史方式，幾乎不可能阻止它們加載圖像，除非你只是不給它一個來源。 如果你不給它一個源，然後嘗試用 JavaScript 更正它，如果那個 JavaScript 沒有運行，你就沒有圖像。 所以延遲加載，本機延遲加載是所有這些的答案。
Addy Osmani：是的，當然。 而且我認為這是我們嘗試改進跨瀏覽器的地方，即去年的原生延遲加載體驗。 如您所知，這是我們早期發布的功能之一，我們能夠利用與行業思想領袖的對話來了解，“哦，嘿，您實際上手動設置的閾值是多少如果您正在使用延遲大小，或者您正在使用其他 JavaScript 的延遲加載庫？” 然後我們調整了我們的閾值，以嘗試接近您期望它們的位置。
Addy Osmani：所以在很多情況下，您可以只使用本機延遲加載。 如果您需要更精細的東西，如果您需要更多地控制能夠設置交叉點觀察者閾值，瀏覽器何時請求事物的時間點，我們通常建議，在這些情況下使用庫，只是因為我們試圖解決 90% 的用例。 但是 10% 仍然有效。 可能有些人還需要更多的東西。 因此，對於大多數人來說，我希望原生延遲加載在可預見的未來足夠好。
Drew McLellan：最重要的是，它是免費的。 添加一個簡單的屬性，您就可以免費獲得所有這些功能，這很棒。 如果我們的聽眾可以做一件事，可以離開並在他們的網站上做以改善他們的圖像優化，那會是什麼？ 他們應該從哪裡開始？
Addy Osmani：一個好的起點是了解這對您的網站有多大的問題。 我會去看看燈塔或支付速度見解。 在一些最受歡迎的頁面上運行它，看看會出現什麼。 如果看起來你只有一兩件小事要做，那就太好了。 也許你可以花一些時間在那裡。
Addy Osmani：如果你要做一長串事情，不妨看看你在其中擁有的最高機會，上面寫著：“哦，嘿，如果你要做這件事，你可以節省幾秒鐘事物。” 並從一開始就集中精力。
Addy Osmani：正如我們在這裡所討論的，現代圖像格式的工具隨著時間的推移變得越來越好。 圖像 CDN 絕對值得考慮。 但除此之外，您還可以採取許多小步驟。 有時，如果它是一個足夠小的站點，即使只是打開並打開 Squoosh，將您的一些圖像通過那裡也可能是一個很好的起點。
德魯麥克萊倫：這是可靠的建議。 現在我知道這是一本轟動一時的出版物，但我真的必須祝賀你出版了這本書。 它是如此全面，非常容易消化。 我認為這是一本非常有價值的讀物。
Drew McLellan：所以我一直在學習圖像優化。 你最近在學習什麼，艾迪？
Addy Osmani：我最近學到了什麼？ 實際上，在一個稍微不同的主題上仍然與圖像有關，所以當我在大學攻讀碩士學位時，我非常深入地研究計算機視覺並試圖理解，我們如何檢測圖像的不同部分並進行狂野和有趣的事情？
Addy Osmani：我最近一直在研究的一個具體問題是，我一直在看自己小時候的照片。 那時，我父母帶的很多食物不一定是在數碼相機上。 他們是寶麗來。 它們通常是分辨率較低的圖像。 我想要一種能夠擴大規模的方法。 所以我最近又開始研究這個問題。 它讓我更多地了解了我可以在瀏覽器中做什麼。
Addy Osmani：所以我一直在構建一些小工具，讓你使用機器學習、TensorFlow、現有技術，拍攝分辨率相對較低的圖像或插圖，然後將它們升級到更高質量的東西。 所以這比簡單地拉伸圖像要好。 這就像實際填寫詳細信息一樣。
Addy Osmani：這很有趣。 我一直在學習很多關於 Web 程序集現在跨瀏覽器的穩定性，以及您可以如何將其中一些想法用於桌面應用程序用例。 這真的很有趣。 所以我最近一直在研究很多 Web 程序集。 這很酷。
德魯麥克萊倫：這很有趣，不是嗎？ 當一項技術出現時，它會顛覆你所知道的一切。 我們一直說，在網絡上，我們可以將圖像變小。 但是，如果我們只有一個小圖像，我們就無法將其放大。 這是不可能的。 但現在我們擁有的技術，在很多情況下，都可能使之成為可能。 這真的很迷人。
Drew McLellan：親愛的聽眾，如果您想了解更多關於 Addie 的信息，您可以在 Twitter 上找到他的@AddieOsmani，並在 AddyOsmani.com 上找到他的所有項目鏈接。 Smashing 現在可以在 smashingmagazine.com 上獲得“圖像優化”一書的實體版和數字版。 感謝您今天加入我們，艾迪。 你有什麼離別詞嗎？
Addy Osmani：有什麼離別詞嗎？ 我有一點歷史上的怪癖，我將與人們分享。 Tim Berners-Lee 於 1992 年將第一張圖片上傳到互聯網。我不確定你是否能猜出它是什麼，但你可能會感到驚訝。 德魯，你有什麼猜測嗎？
德魯麥克萊倫：我猜是一隻貓。
Addy Osmani：一隻貓。 這是一個很好的猜測，但不是。 這是在歐洲核子研究中心。 這張照片實際上是一支名為 Les Horribles Cernettes 的樂隊，這是一支由一群 CERN 員工組成的模仿流行樂隊。 他們會做的音樂就像doo-wop音樂。 他們會唱關於對撞機、怪癖、液氮和反物質的情歌，他們穿著六十年代的服裝，我覺得這很美妙而且很隨意。