Loading UI 該用轉圈、進度條還是骨架屏？各家秒數門檻不一樣

Nielsen Norman Group（NN/g）在談進度指示的文章裡，引述了內布拉斯加大學林肯分校的一項研究，受測者點下連結後，一組看到持續移動的進度條，對照組什麼都沒有。結果看到進度條的那一組滿意度比較高，願意等待的時間平均約是對照組的 3 倍。這個差距，正是 Loading UI 存在的理由。

同樣是等 5 秒，畫面一片空白的人會懷疑自己有沒有點到，看得到狀態的人則會繼續等。實務上最常見的做壞方式也很固定：載入期間整頁空白、放一個永遠在轉的圖示、每個請求都閃一下轉圈，或是同一個畫面裡到處都在轉。

Loading UI 是系統處理期間，介面對使用者顯示的狀態回饋，而轉圈、進度條與骨架屏只是三種不同的回報方式。形式選對，等待才會被理解成「系統正在做事」，選錯了，使用者就會把等待讀成故障。要選對，得先弄清楚這段等待大概多長、載入的是什麼。

Loading UI 是什麼？

Loading UI 指的是使用者送出動作或開啟頁面之後，系統在處理期間顯示的回饋畫面。它有三種主要形式，各自回答不同的問題：

• 轉圈：只告訴使用者系統還在做事，不說要多久。
• 進度條：告訴使用者做到哪裡、還剩多少。
• 骨架屏：先用灰色線框擺出頁面最終的版面，讓人預先看到內容會出現在哪裡。

Loading UI 之所以非做不可，是因為沒有回饋的時候，使用者無從判斷狀況。NN/g 把系統狀態可見性列為 10 項可用性原則之一，並指出許多網站在完全處理完之前不給任何回饋，使用者不確定指令有沒有送出、系統是不是當機，結果就是多餘的點擊，甚至重複下單。

假設龐果設計的客戶後台有個「匯出報表」按鈕，按下去之後畫面沒有任何變化。王小明多半會再按一次、兩次，後台於是收到三份一模一樣的匯出請求。這種重複送出的成因不在使用者，而在介面沒有回報「已收到」。

NN/g 整理的進度指示有四個好處：讓使用者安心；給使用者東西看，讓等待比較容易忍受；提供等待的理由；以及降低對時間長短的感受。換句話說，Loading UI 的任務是回報狀態，而不是裝飾畫面。後面每一種形式要不要用、什麼時候用，都從這個判準出發。

等待時間的長短，決定載入指示的種類

選擇載入指示形式的第一個依據是等待時間。等待短到一定程度，什麼都不放反而最好；等到一定長度，轉圈就不夠用，得換成能顯示進度的形式。

只是「一定程度」指的是幾秒，各家說法並不一致。四個國際來源給的門檻雖然不同，依據卻都是使用者如何感知延遲；另外最容易被忽略的一點是，很快的等待根本不需要指示。

使用者感受延遲的 0.1 秒、1 秒、10 秒界線

NN/g 的 Jakob Nielsen 在談回應時間的文章裡，把使用者對延遲的感受分成三條界線。0.1 秒是使用者覺得系統「即時反應」的上限，這個範圍內除了顯示結果之外，不需要任何特別回饋。1 秒是思緒不被打斷的上限，使用者會察覺到延遲，但 0.1 秒到 1 秒之間通常仍不需要特別回饋。

超過 1 秒，就要讓使用者知道電腦正在處理。到了 10 秒，使用者已經很難持續專注在這件事上，Nielsen 的經驗法則是這類操作要使用百分比完成的進度指示，並提供一個清楚標示、可以中斷的方式。

這三條界線換成設計上的說法，就是 1 秒以內不用指示，1 秒以上要有明確回饋，10 秒以上要讓人看得到進度並且能離開。後面各設計系統給的數字，大致都是在這個框架上做出各自的切分。

各家的秒數門檻並不一致，數字只是起點

NN/g、Google 的 Material Design 3、Microsoft 的 Fluent 2 與 Apple 的設計指南都談到了等待時間，但切點各不相同：

同一段 4 秒的等待，照 NN/g 與 Material 3 的標準都還屬於轉圈類指示，照 Fluent 2 就該換成進度條或顯示說明文字。這個落差本身就說明了業界沒有唯一標準，這些秒數是起點，不是死規定。

實務上的取用方式很單純。產品如果已經採用某套設計系統，就跟著它的門檻走，讓整個產品的行為一致；沒有設計系統的話，以 NN/g 的 1 秒與 10 秒當保守起點，再依自己的實際載入時間分佈調整。NN/g 也提醒，估計的時間難免有誤差，當預估落差很大時，可以把改用進度條的門檻往下調。

極短的等待不需要任何載入指示

每個請求都閃一下轉圈或骨架，是很常見的問題。等待很短的時候，閃現的畫面讓使用者來不及理解剛剛看到了什麼。Fluent 2 指出短暫閃過的指示會讓人困惑，NN/g 的兩篇文章也都提到，不到 1 秒的載入不需要轉圈或骨架屏，快速閃過的畫面反而讓人分心、跟不上。

三個來源的門檻不同，NN/g 與 Fluent 2 定在 1 秒，Material 3 定在 200 毫秒，但門檻以內的建議一致，都是直接顯示結果、不放任何指示。如果某個動作偶爾快、偶爾慢，指示出現的時機就應該依這些門檻來決定，而不是一送出就先閃一下。

轉圈適合短暫又無法預估的等待

轉圈在 Apple 的指南裡稱為不確定型指示器，也叫 activity indicator，用來表示「還在處理」，卻說不出還要多久，所以適合無法量化的任務，例如載入或同步複雜的資料。它的優點是小巧、不占版面，缺點是資訊量低，使用範圍因此需要限制。

NN/g 的建議是把轉圈留給單一模組，像是儀表板上的影片區塊或資訊區塊。整頁載入的話，骨架屏比較合適，因為線框能降低使用者的認知負擔。按鈕送出後的處理中狀態、單一區塊內的資料更新，也都是轉圈的典型位置。Apple 在 macOS 的指引裡同樣提到，轉圈適合放在小範圍內或某個控制項旁邊，例如文字欄位內或按鈕旁。

轉圈旁邊要寫明正在載入的內容

只有一個轉圈或一行固定不動的「Loading…」，傳達的資訊都太少。NN/g 建議在旁邊加上說明為什麼在等的文字，例如「Loading comments…」，同時指出靜態的「Loading…」或「Please wait while we process your request」不建議使用，因為系統一旦當掉，使用者完全沒辦法分辨，也就不知道該重來。

Fluent 2 對標籤的寫法講得更具體，要用進行式動詞加上對象，像「Uploading photo …」「Loading dashboard …」，並避免「File is being uploaded」這種被動句，因為讀起來既疏遠又不清楚。Apple 的指南提醒，說明文字要準確簡短，避免 loading、authenticating 這類很少增加資訊的空泛詞。

三個來源說法略有差異，歸結成同一個重點，就是標籤要寫出正在處理的對象，別只寫「載入中」。另外，Apple 針對 macOS 桌面程式的建議是轉圈通常不加標籤，不過這屬於桌面軟體的情境，網頁介面照 NN/g 與 Fluent 2 的做法比較貼近使用者需求。

超過 10 秒的轉圈會讓人懷疑畫面當掉

轉圈不告訴使用者進度。NN/g 指出，轉圈無限旋轉的時候，使用者無法確定系統是仍在運作還是已經停止，很可能直接放棄任務。因此轉圈不建議用在超過 10 秒的等待，使用者在這麼長的時間裡感覺不到任何進展，很快就會不耐煩。

NN/g 也點出轉圈常被濫用的原因，在於對開發者來說，轉圈不用估計動作會花多久，所以每種延遲都用轉圈最方便。但這是在遷就開發流程，而不是遷就使用者。比較合理的做法，是先用不確定型指示表示處理中，等流程能算出進度了，再換成同一種形狀的確定型指示，不要直接把圓形轉圈換成長條進度條。

進度條用在可預估、超過 10 秒的等待

進度條屬於確定型指示器，傳達的是做到哪裡、還剩多少。NN/g 認為百分比完成型指示器是資訊量最大的等待動畫，使用者可以據此決定要不要繼續等，也降低了對時間長短的不確定感，一般用於 10 秒以上的流程。

適用的對象是有明確完成度的流程，像上傳、下載、轉檔、批次處理。NN/g 在骨架屏的文章裡也指出，這類流程出現骨架屏沒有意義，甚至會造成混淆。Material 3 的用法類似，列舉的情境包括載入應用程式、送出表單與儲存更新。

有兩個共識值得先記住。第一，確定型指示器必須精準反映它所測量事項的進度，Material 3 與 Apple 都這樣要求。第二，多項內容同時載入時，用單一進度條表示整體進度，不要每個項目各放一條；Material 3 明確寫了「Don’t add progress indicators to every activity」。

進度推進的節奏與停在最後一格的風險

進度條最傷信任的情況，是很快衝到九成，然後在最後一段停很久。兩個來源在「進度該怎麼走」上的建議略有不同。NN/g 建議進度動畫先慢後快，避免建立系統無法維持的速度期待，因為超出期待比低於期待更讓人滿意；Apple 則建議盡量讓進展的速度平均，幫助使用者對完成時間有把握。

Apple 舉的反例很直接，5 秒內顯示完成 90%，剩下的 10% 卻要 5 分鐘，會讓人懷疑 app 是否還在運作，甚至覺得自己被騙。NN/g 也指出，進度條如果快速衝刺卻停在最後一格，使用者會感到挫折，進度條的好處就歸零。

兩個建議在節奏上各有主張，共同的底線卻很明確，進度條不能停在最後一格。另外，進度條要持續移動，Apple 提到使用者容易把靜止的指示器聯想成流程停滯或 app 凍結，如果流程真的停住了，就要提供回饋，說明問題出在哪裡、使用者可以做什麼。

進度條要附上標籤、剩餘時間與取消按鈕

一個資訊完整的進度條有三個要素：標籤說明正在做什麼、剩餘時間或步驟讓人知道大概多久、退出方式讓人能取消或暫停。Fluent 2 的版面示範是標籤放在進度條上方，狀態文字放在下方，例如「30% complete – about 20 seconds remaining」；如果使用者不等待會有後果，還要附上復原說明。

時間部分，NN/g 建議給大略值就好，例如「About 3 minutes remaining」，估計時要留餘裕，提早結束對使用者是驚喜。如果不容易估計時間，改用步驟數也可以，像「Updating address 3 of 50」。處理較久的動作，則要提供停止選項。

取消與暫停的設計，Apple 的判斷方式很清楚，中斷不會產生副作用，就放 Cancel 按鈕；中斷會有副作用，例如丟掉已經下載的部分，除了 Cancel 之外再加上 Pause。取消會讓進度歸零時，要先跳出確認，讓使用者決定要取消還是繼續。

從不確定型換成確定型的時機和形狀限制

有些流程一開始無法估計，做到一半才算得出剩餘量。Apple 與 Material 3 的共同建議是，能量化的時候，就把不確定型換成確定型，因為使用者通常比較喜歡確定型的指示器，比較能衡量目前的狀況與還要等多久。

換的時候有一個限制，形狀不要中途改變。Apple 明確建議不要從圓形的轉圈切換成長條進度條，兩者形狀與尺寸不同，轉換會擾亂介面並造成困惑。Material 3 也有類似的規則，loading indicator 不要直接轉成確定型的進度指示器，要換的話，應該是從不確定型進度指示器換成確定型進度指示器。

骨架屏適合版面已知的內容載入

骨架屏用線框式的灰色區塊模擬頁面最終的版面，讓使用者預先看到內容會出現在哪裡。NN/g 把它定位為專用於整頁載入的進度指示，也就是說，它處理的是「內容載入」，而不是上傳、轉檔這類流程。

NN/g 列出的好處有三個：避免使用者以為網站壞了、營造等待比較短的感覺、降低認知負擔。它適合 10 秒以內的等待，在整頁載入的情境中優於轉圈。Apple 的指南也提醒，讓使用者等到全部載完才顯示任何東西，使用者會把沒有內容視為產品的問題，比較好的做法是先放佔位的文字、圖形或動畫，內容到了再替換。Fluent 2 同樣把骨架屏用於內容渲染的延遲，並可搭配微光動態。

不過骨架屏有它的邊界。NN/g 的結論是，骨架屏不能取代效能優化，只是多一項改善等待體驗的工具。另外，骨架屏能不能讓人覺得等待變短，現有研究的結果也不是一面倒。

骨架屏分成 3 種型態，框架型不建議使用

NN/g 把骨架屏分成三種型態。第一種是靜態內容與圖片骨架，用固定的灰色區塊標出文字與圖片的位置；第二種是動態骨架，以漸層或元素淡入淡出的脈動呈現，也就是常見的微光效果；第三種是框架型，只顯示頁首、頁尾與空白背景。

三種裡面，NN/g 只明確不建議框架型。原因是它沒有內容線框，使用者如果等得夠久，就會認定頁面沒有在運作。

動態骨架的微光能降低等待感，但 NN/g 也提醒，動畫有可能令人分心、惱人，甚至對部分使用者造成無障礙問題。

骨架屏的尺寸要貼近最終版面，避免版面位移

骨架屏做得好不好，關鍵看它跟最終畫面像不像，以及替換的瞬間畫面會不會跳動。骨架的區塊尺寸應該對應真實內容，圖片區塊用接近實際的比例，文字區塊用接近實際的行數。尺寸差太多，內容載入後會把版面往下推，使用者剛讀到的位置就會被擠走。

這件事也連到 Core Web Vitals 的版面位移（CLS）。web.dev 在談 CLS 優化時，把預先保留空間列為正式做法。延後出現的 UI 要先在檢視區塊中留好足夠空間，例如使用預留位置或骨架 UI，載入時網頁中的內容才不會意外移動。CLS 的良好標準是 0.1 以下，以第 75 個百分位數衡量，行動與電腦分開評估。

預留空間的技術做法，web.dev 提到可以用 CSS 的 min-height 或 aspect-ratio，內容高度不固定時尤其適用。另一個容易忽略的地方是，移除原本為元素預留的空間，造成的位移可能跟插入內容一樣多，所以載入失敗或沒有內容時，也不該把預留空間整塊收掉。

骨架屏未必讓人覺得等待變短

骨架屏常被當成改善「感覺速度」的標準答案，實際證據卻沒有那麼一致。Viget 在 2017 年發表過一項小型測試，共有 136 位受測者分成骨架屏組 39 人、轉圈組 39 人、空白畫面組 58 人，用動畫 GIF 模擬三種載入畫面，再詢問載入有多快。

結果是骨架屏組的感知等待時間平均 2.82 秒，轉圈組 2.41 秒，空白畫面組 2.29 秒；同意「載入很快」的比例，骨架屏組 59%、轉圈組 74%、空白畫面組 66%。骨架屏反而是三組裡表現最差的一組。

這項研究有明顯的限制，樣本只有 136 人，用 GIF 模擬而不是真實網站，是代理商自己做的輕量測試，受測者估計的等待時間平均也只有 2 到 3 秒。Viget 的團隊提出三個可能的原因，分別是骨架屏比較新奇、反而更引人注意，在不熟悉的介面裡會讓人摸不著頭緒，以及它可能只在非常短的等待中才有效，並明說需要更多測試才能確定。他們的結論是，骨架屏不是提升感知效能的萬靈丹，要用得謹慎。

回到實務上，骨架屏要看情境與介面熟悉度來用，版面固定、使用者熟悉的內容區塊比較適合，而不是以為把骨架套上去，等待就會變快。

網站常見載入情境與對應的做法

把前面的判準放進實際情境，可以整理成下面這張對照表：

表中有幾列需要補充。長時間的背景處理，Fluent 2 提供的是 progress toast，適合會影響目前內容、又要跑很久的後台流程，使用者可以離開目前的檢視，仍能掌握進度。Material 3 則建議等待很長時，考慮讓使用者離開頁面。Apple 也建議在背景載入內容，讓使用者先做別的事。

如果載入很久又無法避免，Apple 的指南建議給使用者一些有意思的內容，例如操作提示或新功能介紹。AI 對話的情境則有點特殊，Fluent 2 指出回應指示要立刻出現，才能維持對話的流暢感。

取捨的順序可以簡化成兩步。先看載入的是整頁內容還是單一動作，前者偏向骨架屏，後者偏向轉圈或進度條；再看預期的等待時長，用前面的門檻決定轉圈該不該換成進度條，或是乾脆不放指示。

載入畫面常見的錯誤與替代做法

選對形式之後，載入畫面還是有幾種很常見的做壞方式。每一種都有自己的成因，也有對應的替代做法。

空白畫面與靜態字樣讓人以為網站壞了

什麼都不顯示，或者只放一行不會動的「載入中」，使用者無從分辨系統是在處理還是已經停止。前面提過 Apple 的提醒，等到載入完成才顯示內容，使用者會把空白當成產品本身出了問題。NN/g 也指出，空白頁面會讓使用者認為出了問題而離開，靜態指示則應該被取代。Fluent 2 同樣主張避免空白畫面與靜態載入畫面。

解法是至少給一個會動、並且有對象說明的指示，或是先顯示佔位內容。轉圈旁邊寫上正在載入的對象，內容區塊先擺出骨架，都比一片空白或一行固定字樣好得多。

多個轉圈同時出現，使用者分不出整體進度

同一個畫面到處都在轉，使用者不知道該看哪一個，也分不出整體進度。Fluent 2 指出多個指示器不該互相爭奪注意力，回饋應該綁在最相關的內容或動作上。Material 3 則建議多項內容同時載入時，用單一指示表示整體，不要為每項活動都加一個。

落實到做法上，整個頁面在載入，就放一個整體指示；只有某個區塊在載入，就把指示綁在那個區塊上；各區塊獨立啟動的情況，才各自放指示。

小遊戲或花俏動畫填補等待，容易蓋過進度資訊

很多人想把載入畫面做得有趣。NN/g 對兒童使用者的觀察給了一個提醒，許多網站在載入時嵌入影片或小遊戲，結果讓孩子更困惑，分不出哪個才是真正的遊戲。NN/g 的建議是對耗時的活動一律使用百分比進度條、給足夠的顯眼度，載入期間的輔助動畫不得遮蓋進度指示，動畫也要簡單並與主活動相關。

遊戲類產品的情況不太一樣。Apple 的指南認為標準的進度指示器有時在遊戲中顯得格格不入，可以設計符合遊戲風格的客製載入畫面。這類客製畫面仍然得先把進度交代清楚，動畫再談風格。至於動畫該不該做、做到什麼程度，是另一個層級的判斷，值得獨立看待。

載入停住時，畫面缺少說明與下一步

載入失敗、超時或停住的時候，只剩一個永遠在轉的圖示，是最糟的結果。NN/g 指出，轉圈無限旋轉時，使用者無法確認系統是否已經停止，可能因此放棄任務。Nielsen 的回應時間文章也提到，超過 10 秒的操作需要明確可中斷的方式。

Apple 的指南針對停滯的流程給了明確方向，因故停住時，要提供讓人了解問題與可採取行動的回饋；可以中斷的流程則放取消按鈕。落實到介面上，就是超過合理時間之後，畫面要出現說明與下一步，例如重試、取消或回上一頁，讓使用者不必面對一個沒有盡頭的轉圈。

載入動畫也要兼顧輔助科技與動態偏好

載入動畫是持續在動的內容，也是狀態會改變的內容，因此需要照顧兩類使用者。用螢幕閱讀器的人，要能聽到「載入中」與「完成」的狀態變化；對動態敏感的人，要能暫停、略過或減少動畫。

螢幕閱讀器要能讀到載入狀態

轉圈與進度條都是視覺元素，螢幕閱讀器的使用者看不到，需要用標準屬性讓狀態可以被朗讀。Fluent 2 建議用 ARIA 標籤宣告狀態變化，例如在載入或完成的提示區域加上 role="status"，讓螢幕閱讀器在狀態改變時主動朗讀。

進度指示本身也需要一個描述性的名稱。Google 的 Material Web 元件文件建議為進度指示加上 aria-label，例如「Download progress」，螢幕閱讀器才知道這個進度條在回報什麼。沒有名稱的進度條，對只能聽的人來說只是一個沒有意義的元件。

超過 5 秒的動畫和減少動態的偏好設定

W3C 的 WCAG 準則（成功準則 2.2.2）對動態內容的要求是，自動開始、持續超過 5 秒，而且與其他內容並存的移動、閃爍或捲動資訊，要提供暫停、停止或隱藏的機制，除非該動態是活動中不可或缺的一部分。換句話說，「自動開始」「超過 5 秒」與「與其他內容並存」三個條件同時成立，才需要提供這類機制。

載入畫面有一個重要例外。WCAG 的說明文件提到，預載階段的動畫在所有使用者都無法互動、且不顯示進度會讓人以為內容凍結或壞掉的情況下，可以視為不可或缺；範例是大型檔案的預載動畫，它是頁面上唯一的內容，沒有與其他內容並存，即使在慢速連線下超過 5 秒，也不需要提供暫停機制。

動畫骨架的微光屬於非必要動畫，可以讓它跟隨使用者的減少動態設定。做法是用 CSS 的 prefers-reduced-motion 媒體查詢，偵測到使用者開啟了減少動態，就把微光關掉，改成靜態的灰色區塊，載入狀態的資訊仍然完整。

品牌感適合放在形狀、色彩與文案

許多人搜尋 Loading UI 是想找設計靈感。品牌個性確實可以放進載入畫面，前提是形式要選對。個性只能加在外觀、色彩與文案語氣上，不能改變該形式的功能，確定型仍要準確，不確定型仍要說明，文字仍要講清楚。

Material 3 的進度條有平直與波浪兩種外形，它的說明是選擇最符合產品調性的那一種，並指出波浪外形能讓較長的流程不那麼死板，適合風格比較強烈的產品。代價是元件整體的高度會改變，而且尺寸很小的時候，波浪不容易看出來。

Fluent 2 為 AI 助理的場景設計了漸層微光，以及摩斯電碼與脈動圓點兩種專屬的等待動畫，用來呼應主題。即使換了外觀，同一套內容原則仍然適用，標籤用進行式、簡短，並替使用者設定好期待。Apple 對遊戲的看法也一樣，客製載入畫面可以配合遊戲風格；外觀換了，該交代的進度資訊仍然不能少。

NN/g 對載入期間動畫的建議是簡單、並與主活動相關。所以選配色與動畫節奏的時候，只要碰到前面談的無障礙需求與時間門檻，就以功能為先。品牌感體現在形狀的圓潤或銳利、色彩的選用，以及「正在整理你的訂單」這種語氣一致的文案，比在動畫上堆花樣更穩定。

載入畫面是使用者等待時盯著看的地方，把它做成「看得出系統在做什麼、還要多久」，再於這個基礎上加上品牌個性，Loading UI 才算真正完成。