說到圖片加載速度，這真是網站優化裡一個讓人又愛又恨的課題。愛的是，當你搞定它之後，那種流暢的用戶體驗帶來的滿足感；恨的是，過程中的各種技術細節和測試有時真讓人頭大。就像你分享的那套瀑布流源碼，強調了「加載極快不卡頓」，這背後絕對不僅僅是寫了「滾動節流」那麼簡單。圖片本身，才是那個最吃資源、也最需要被「馴服」的傢伙。一張未經處理的高清大圖，分分鐘就能讓再好的程式碼優化功虧一簣。所以，與其只關注程式邏輯，不如我們把鏡頭對準圖片本身，聊聊幾個真正能讓用戶「感覺」到速度提升的實用策略。
別讓圖片「裸奔」上線：格式與壓縮是基本功
你知道嗎？很多時候網站慢，不是伺服器不行，而是我們直接把手機拍出來好幾MB的照片扔上去了。這就像開著一輛載滿貨物的卡車去跑賽道，怎麼可能快得起來？第一步永遠是選擇對的格式。現在主流的 WebP 格式，在同等畫質下，體積通常比傳統的 JPEG 小 25-35%，而且支援透明通道。如果你的用戶群瀏覽器比較新（現在絕大多數都支援了），果斷用 WebP 吧。對於那些必須照顧到的舊瀏覽器，別擔心，可以用 <picture> 元素提供後備方案，這已經是現代前端開發的標準做法了。
選好格式後，壓縮是下一關。這裡有個迷思：壓縮不是無腦把品質調到最低。我們要在肉眼幾乎無法察覺的畫質損耗和檔案大小之間找到甜蜜點。像 TinyPNG、Squoosh 這些線上工具，或者建置流程中整合的 imagemin 外掛，它們用的智慧壓縮演算法真的很厲害，能剃掉很多對螢幕顯示無用的元資料。我曾經把一張 1.2MB 的宣傳圖壓到 180KB 左右，放在網頁上根本看不出差別，但加載時間從好幾秒變成了瞬間——這種提升是實實在在能被用戶感知的。
「按需加載」才是聰明之道：懶加載與響應式圖片
再來聊聊你源碼裡提到的「無限滾動」。這功能很棒，但它必須和「懶加載」搭配，才能發揮最大效益。想想看，如果用戶一點進頁面，瀑布流裡所有圖片（哪怕是在螢幕最底下的）都同時開始加載，那瞬間的請求和頻寬佔用會多可怕？懶加載的原理很直覺：只有當圖片即將滾動進入用戶的可視區域時，才去加載它。這在行動裝置上尤其重要，能為用戶省下可觀的流量和電力。現在 HTML 已經有原生的 loading="lazy" 屬性了，實現起來非常方便。
另一個常被忽略的點是「響應式圖片」。我們的網站會在手機、平板、電腦上被瀏覽，難道都用同一張 2000px 寬的大圖嗎？這太浪費了。正確的做法是使用 srcset 和 sizes 屬性，為不同螢幕尺寸提供最合適的圖片版本。比如，在手機螢幕上，一張 400px 寬的圖片就足夠清晰了，它的檔案大小可能只有桌面版大圖的四分之一甚至更小。這種「看人下菜碟」的方式，能確保無論用戶用什麼設備訪問，都能獲得最快、最合適的圖片加載體驗。這比你源碼中提到的「全端自適應顯示」在圖片層面更進一步，是真正的精細化運營。
把圖片「寄放」在更快的地方：CDN 與快取策略
最後，我們來談談「最後一哩路」的加速。圖片檔案最終要從某台伺服器傳到用戶的瀏覽器，這段距離的長短直接影響速度。如果你的用戶遍布各地，那麼使用 CDN 就是必選項了。CDN 會把你的圖片分發到全球各地的邊緣節點，用戶加載圖片時，是從離他最近的那個節點獲取，速度自然飛快。這對於你那種以圖片展示為主的瀑布流網站，效果是立竿見影的。
配合 CDN，良好的快取策略是另一把利器。可以為圖片這類靜態資源設定較長的快取時間（比如一個月），並在檔名或路徑上加入版本號或雜湊值。這樣一來，用戶第一次訪問後，圖片就會儲存在本地，再次訪問或瀏覽其他頁面時根本無需重新下載。而當你更新了圖片時，只需要改變檔名，就能讓用戶自動獲取新版本，同時不影響其他已快取資源的效率。這套組合拳打下來，網站的圖片加載速度想慢都難。說到底，圖片優化是個系統工程，從生產、處理到分發，每個環節摳一點點細節，累積起來就是巨大的體驗差距。你的瀑布流程式碼提供了優秀的骨架，而這些圖片優化技巧，就是讓它血肉豐滿、行動如飛的關鍵。
評論（13）
WebP真的香，換完首屏快好多
loading=”lazy”救我狗命，之前全載差點崩了
手機上看大圖根本吃不消，響應式太必要了
這篇說到痛點了，我上次壓圖壓到懷疑人生😭
CDN真不是玄學，加了之後海外用戶回饋快超多
求問srcset跟picture到底怎麼搭配用啊？
之前搞過這個，確實折騰了好久才調好壓縮參數
又是標題黨？講一堆不就是叫人壓圖+懶載嗎🤔
感覺還行，至少比我看過的那些水文強
那如果是動圖呢？GIF轉WebP會卡嗎？
太貴了吧這也，小站哪負擔得起CDN…
hhh 看完默默回去改自己部落格的圖片
肉眼無感但體積砍一半？有這麼神？