你有沒有遇過這種情況？滿心期待地打開一個網站，結果畫面卡住不動。明明只是要看一篇文章，卻得等上老半天，看著空白的畫面發呆。或者，你正在用手機瀏覽一個商品頁面，滑到一半突然跳出「圖片載入中」的轉圈圖示，整個版面的位置還因為圖片突然出現而跳動，害你點錯了按鈕。
這些令人沮喪的瞬間，其實都指向同一個問題「網站沒有好好考慮使用者的真實需求」，今天我們要聊的「延遲載入」，正是為了解決這種困境而生的設計思維。它不是什麼高深的技術名詞，而是一個貼心的服務。只有在使用者真正需要的時候，才把東西端出來。
什麼是 Lazy Loading？
讓我們用一個生活中的例子來說明，想像你走進一家餐廳，服務生沒有問你要吃什麼，就直接把菜單上所有菜餚一次全部堆上桌。你會覺得這服務真周到嗎？不，你只會覺得莫名其妙、浪費空間，而且根本不知道該從哪裡下手。
網頁的運作也是同樣的道理，傳統的做法，也就是所謂的「預先載入」，就像那個過度熱情的服務生，不管你看不看得到、用不用得到，一進門就把所有圖片、影片、程式碼全部塞給你，結果呢？瀏覽器忙得焦頭爛額，你的畫面卻空空如也，只能一直等一直等。
Lazy Loading 則換了一個完全不同的思路。先給你眼前看得到的東西，其他的一邊看一邊準備，當你打開一個網頁，瀏覽器只會優先載入你第一眼就能看見的區域，也就是我們常說的「第一屏」的內容，至於頁面下方那些你還沒滑到的圖片、影片、甚至某些互動元件，它們會乖乖等到你快要看到它們的時候，才開始載入。
換句話說，Lazy Loading 是一種「剛剛好」的服務。不預先給太多，也不讓你需要時等太久，它讓網頁的第一印象變得乾淨俐落，也讓你的每一次捲動都感覺流暢自然。
為什麼我們需要 Lazy Loading？
想像你正用手機瀏覽一個旅遊部落格，裡面有五十張高畫質的風景照，如果你還在使用傳統的載入方式，你的手機得一次下載完這五十張照片才能讓你順暢地滑動。這不僅會耗掉你大量的行動數據，還會讓你的手機發燙、電量直線下降。更糟的是，你可能看了前面十張就找到想要的資訊離開了，後面四十張根本沒人看過，但它們已經浪費了你的時間和金錢。
Lazy Loading 的設計，正是為了避免這種「無效的努力」。它帶給使用者的好處非常具體。
更快的開始，更順的過程
因為瀏覽器不需要在一開始處理所有資源，你第一眼看到的畫面會更快出現。那種「點進連結後一片空白」的等待焦慮感會大幅降低。這背後其實對應了網頁效能指標中的「最大內容繪製」( LCP ) 與「首次內容繪製」( FCP )。但對你來說，這些名詞不重要，重要的是你感覺「這個網站跑得好快」。
省下你的流量與裝置續航力
如果你只看了網頁的上半部就離開了（事實上，大多數人都是如此），那麼下半部的圖片和影片根本不需要被下載。這代表你省下了行動數據，手機也不用浪費電去處理那些你根本不會看到的內容。這對於網路不穩定或數據方案有限的使用者來說，格外有意義。
讓老舊裝置也能順暢瀏覽
不是每個人都用最新款的手機，Lazy Loading 可以避免在一瞬間塞給裝置太多任務，減少卡頓、當機的機會。這是一種包容性的設計，它考慮到了不同設備、不同網路環境下的真實使用者。
間接幫助網站被找到
雖然 Lazy Loading 本身不是搜尋引擎排名的直接因素，但它帶來的快速度、低跳出率、良好的互動體驗，都會讓搜尋引擎覺得這個網站值得推薦。換句話說，為使用者著想，最終也會讓網站本身受益。
哪些內容適合「等一下再載」？
判斷一個資源該不該 Lazy Loading，其實只有一個簡單的原則。如果使用者一進網頁沒有立刻需要它，那就可以等。具體來說，以下幾種東西很適合。
畫面下方的圖片：像是長篇文章中間的插圖、商品列表後續的縮圖、瀑布流版面中那些你還沒滑到的部分。
第三方嵌入內容：例如 YouTube 影片、Google 地圖、廣告橫幅。這些東西通常體積不小，而且來自外部伺服器。讓它們乖乖等到你滑到附近再載入，可以避免拖慢整個頁面。
非必要的程式與樣式：比如頁面最底部的留言區、即時聊天視窗、動態跑馬燈。這些功能在你還沒打算使用之前，完全不需要急著載入。
判斷的標準很直覺。問自己一句「使用者現在就需要這個嗎？」如果答案是否定的，就讓它等一等。
三種實作方式，從最簡單到最靈活
實際要讓 Lazy Loading 運作起來，有幾種不同的做法。你可以根據自己的需求與技術能力來選擇。
第一種：最簡單也最安全，直接用瀏覽器內建的功能
現在的主流瀏覽器都已經原生支援延遲載入。你只需要在圖片或內嵌框架的標籤裡加上 loading = “lazy” 這個屬性，瀏覽器就會自動幫你處理好一切。不需要寫任何複雜的程式碼，也不用擔心會出什麼差錯。對搜尋引擎來說，這種做法也是最友善的，因為 Google 完全看得懂這個屬性的意義。
第二種：更精細的控制，用 JavaScript 的 Intersection Observer API
如果你需要更精準地控制觸發時機，或者要 Lazy Loading 的對象不是圖片或框架（例如動態載入的 API 資料），那麼可以使用這個 API 。它能在不影響網頁效能的狀況下，穩定監測某個元素是否即將進入畫面。這種方式給了設計者更大的彈性，但也需要多寫一些程式碼，而且必須小心處理，確保搜尋引擎仍然能夠抓到內容。
第三種：偷懶一點，用現成的第三方工具
市面上有許多現成的函式庫（例如 lazysizes ）或內容管理系統的外掛（例如 WordPress 的效能優化外掛），可以幫你快速實作延遲載入。適合不想從頭打造的人。
這三種方式各有優缺。原生屬性最省心、對 SEO 最安全； JavaScript API 最靈活；第三方工具最方便。你可以根據專案規模和你的熟悉程度來決定。
哪些內容絕對不能 Lazy Loading？設計的底線
Lazy Loading 雖然好用，但它不是萬靈丹。有些東西如果讓它們「等一下」，反而會讓使用者體驗一落千丈。這裡面有一個核心的判斷標準。凡是使用者一進網頁就必須立刻看到的內容，絕對不能 Lazy Loading 。
具體來說，以下這些東西請千萬不要加上 Lazy Loading 的設定。
第一眼的主視覺圖片：也就是網頁最上方那張大大的橫幅圖、文章的第一張重點圖片、或是你的網站 Logo 。這些元素往往是整個頁面中最重要、最需要第一時間出現的東西，如果你讓它們 Lazy Loading ，瀏覽器反而會先去處理其他次要資源，結果就是最重要的畫面最後才「彈」出來。使用者會明顯感覺到「這個網站怎麼慢半拍」。
標題與導覽列：使用者需要知道自己在哪個網站、這篇文章在講什麼、以及怎麼前往其他頁面。這些文字與按鈕必須在第一時間就位。
首頁的行動呼籲按鈕：例如「立即購買」、「免費試用」、「註冊會員」。如果你延遲了這些按鈕的載入，可能會讓使用者錯過互動時機，甚至直接離開。
一進頁面就自動播放的影片：如果你刻意設計了自動播放的開場影片，卻又讓它延遲載入，那麼畫面一開始會是空白的，完全失去設計的意義。
為什麼這些內容不能等？讓我們從使用者的認知角度來理解。當一個人進入一個新網頁，他的大腦會快速掃描畫面，試圖回答三個問題：「這是哪裡？」「我在這裡可以做什麼？」「我該從哪裡開始？」如果最重要的視覺線索和導航資訊被延遲了，他就會感到困惑、不確定，甚至失去耐心離開。這就是為什麼第一屏的內容必須「即時呈現」。這是對使用者最基本的尊重。
一個常見的失誤：畫面跳動的煩躁感
你應該有過這種經驗。正在閱讀一段文字，突然畫面一晃，一張圖片「砰」地出現在你眼前，把原本看到的段落往下擠。你瞬間找不到剛剛讀到哪裡，甚至不小心點到別的東西。這就是所謂的「累計版面配置轉移」( CLS )，一種非常惱人的使用者體驗問題。
這個問題的根源很簡單。你沒有為將要載入的圖片預留空間。當你使用 Lazy Loading 時，如果沒有事先設定圖片的寬度和高度，瀏覽器一開始不知道那個位置會有一張圖片，等到圖片真正載入時，只好把周圍的內容推開。就像你在一個已經坐滿人的餐桌旁突然再塞一張椅子，所有人都得移動。
解決方法非常簡單。永遠在圖片標籤中明確寫出寬度與高度的數值。這樣瀏覽器一開始就能保留正確的空間，圖片載入時就不會造成任何位移。這是一個小動作，但對使用者的感受影響巨大。
Lazy Loading 與搜尋引擎：一個需要小心處理的關係
很多網站經營者會擔心。如果我把圖片或內容 Lazy Loading ， Google 會不會看不到它們？這個擔心是有道理的，但答案取決於你怎麼做。
好的一面：如果實作得當，延遲載入會因為提升網站速度、改善核心指標、降低跳出率，而間接幫助你的 SEO 排名。 Google 喜歡對使用者友善的網站，而延遲載入正是打造友善體驗的有效工具。
危險的一面：如果你的 Lazy Loading 方式過於複雜，必須依賴使用者的捲動或點擊才能觸發內容載入，那麼 Google 的機器人可能永遠不會執行這些動作，因為它們不會模擬真正的使用者行為。結果就是，那些被你精心延遲的圖片和文字，根本不會出現在搜尋索引中。
此外，有些舊式的 JavaScript 函式庫會把真正的圖片網址藏在一個叫做 data – src 的非標準屬性裡，而不是標準的 src 屬性。 Google 的爬蟲看不懂 data – src ，於是就忽略那張圖片。這會讓你損失來自圖片搜尋的流量。
安全作法三原則
優先使用原生的 loading = “lazy” 屬性，這是對搜尋引擎最友善的方式。
即使圖片被延遲載入，依然要加上 alt 替代文字，讓 Google 理解圖片的內容。
設定完成後，務必用 Google Search Console 的「網址檢查工具」實際看一下轉譯後的 HTML 。如果你能看到圖片出現在標準的 img 標籤中，代表一切正常。
無限捲動：看似流暢，實則暗藏風險
現在很多網站喜歡採用「無限捲動」。你一直往下滑，內容就一直載入，沒有盡頭。這種互動方式在某些情境下很迷人（例如社群媒體的動態牆），但它同時也帶來了兩個嚴重的設計問題。
對搜尋引擎的風險： Google 的爬蟲不會自己捲動畫面。如果後續的內容必須透過捲动才能出現，那麼這些內容永遠不會被搜尋引擎發現。等於你親手把網站的後半部藏了起來。
對使用者的風險：想像你已經滑了很長一段時間，點擊其中一則內容進去看，然後按「上一頁」返回。你猜你會在哪裡？通常會回到頁面最頂端，之前滑了半天的位置全部消失。這種迷失方向的感覺，會讓使用者極度挫折，甚至從此不再回來。
比較好的設計方式
如果你真的想用無限捲動，請同時採用以下幾個補救措施。
為每一批載入的內容給予一個獨立的網址（例如 ? page = 2 ）。這樣使用者和搜尋引擎都能直接存取特定區塊。
確保網頁上有明確的連結（例如「下一頁」按鈕），讓搜尋引擎可以循線爬取所有內容。
當使用者捲動載入新內容時，使用瀏覽器的 History API 動態更新網址列。這樣當使用者按「上一頁」時，才能回到正確的位置。
無限捲動本身不是壞設計，但忽略上述配套措施，就是對使用者的不尊重。
如何檢查你的延遲載入設定是否正確？
設計完成後，一定要實際驗證。最簡單也最可靠的方法，是使用 Google Search Console 的「網址檢查工具」。請它顯示轉譯後的 HTML ，檢查那些應該被 Lazy Loading 的圖片是否確實出現在標準的 img 標籤中，如果答案是肯定的，恭喜你，你的設計兼顧了速度與可發現性。
此外，你也可以打開瀏覽器的開發者工具，模擬慢速網路環境，實際滑動頁面，觀察圖片是否在正確的時機出現，版面有沒有發生跳動。一個好的設計，應該讓使用者完全感受不到「延遲」的存在。一切都順順地、剛剛好地發生。
設計的本質是理解使用者的真實處境
回顧整篇文章，我們討論了很多技術細節和注意事項。但歸根結柢， Lazy Loading 的設計哲學只有一句話。不要在別人不需要的時候強迫給，也不要在別人需要的時候讓人等。
當你準備為網站加上 Lazy Loading 時，請先把自己想像成一位使用者，你用的是什麼裝置？網路速度快不快？你今天的心情是悠閒還是急躁？你為什麼來到這個頁面？這些問題的答案，會引導你做出正確的設計決策。
記住，第一屏的內容永遠不要延遲，那是你對使用者的承諾，圖片一定要預留空間，那是你對使用者的體貼，優先使用原生的方式，那是你對搜尋引擎的友善。而無限捲動，請務必搭配分頁與網址更新，那是你對使用者時間的尊重。
好的設計不會讓人注意到設計的存在，只會讓人感到「一切都很順」， Lazy Loading 就是這樣一個默默在背後付出的角色。希望這篇文章能幫助你在追求速度與體驗的路上，少走一些彎路，多一份對使用者的理解。
