Skeleton Screen

骨架屏是什麼，跟一般的載入動畫（例如旋轉圈圈）有什麼不同？

骨架屏是一種用模仿最終頁面結構的視覺佔位符（通常是帶有淺灰色的矩形色塊、圓形頭像框、橫條標題等形狀）來呈現載入中狀態的技術，這些佔位符會出現在真實內容最終會顯示的相同位置。跟旋轉圈圈或進度條這類傳統載入動畫最大的不同，在於骨架屏傳遞的資訊量遠遠更多——旋轉圈圈只告訴使用者「系統正在處理」，但沒有透露任何關於「等一下會看到什麼」的線索；骨架屏則讓使用者提前看到頁面的大致輪廓，例如這是一則貼文列表、還是一個商品清單，這種空間上的預期感能降低使用者在內容真正出現時的認知負荷。

這個差異背後有明確的心理學依據：使用者的感知等待時間跟實際等待時間並不完全對應，當使用者對接下來會發生什麼有心理準備，即使兩者的實際等待秒數一樣，骨架屏帶來的等待感受通常會比較短。

骨架屏為什麼會出現，它解決了什麼具體問題？

骨架屏要解決的核心問題是「感知效能」跟「實際效能」之間的落差——一個 400 毫秒就載入完成、但過程中畫面完全空白的頁面，跟一個要花 800 毫秒才載入完成、但立刻顯示骨架佔位的頁面比起來，前者反而會讓使用者覺得比較慢，即使實際載入時間更短。這是因為空白畫面沒有給使用者任何視覺線索，使用者不確定系統是不是當機了、還是真的在處理，這種不確定感本身就會放大等待的焦慮。

這個技術最早在 2013 年由 Facebook 引入，後來透過 React 生態系（例如 react-content-loader 這類函式庫）被廣泛採用，逐漸成為圖片密集、資料密集頁面（社群動態牆、儀表板、電商商品列表）的標準做法。它出現的時間點，剛好對應行動裝置網路速度不穩定、頁面內容越來越豐富的階段——當「完全沒有延遲」變得不切實際，設計上能做的就是想辦法讓不可避免的延遲，感覺起來比較短。

骨架屏實際上是怎麼被設計出來，做得不好的骨架屏會有什麼問題？

設計骨架屏比較穩妥的做法，是從「已載入的版面」往回推，而不是從「載入中的空白狀態」往前想——先確定真實內容最終呈現的結構長什麼樣子，再用尺寸完全對應的灰色矩形去填滿相同的位置，確保骨架版跟真實版之間沒有版面尺寸落差（也就是要做到零版面偏移，Cumulative Layout Shift 為零），這樣從骨架切換到真實內容的那一刻，畫面不會突然跳動，使用者的視線也不需要重新定位。

做得不好的骨架屏常見有兩種問題：第一種是「幾何錯位」，骨架屏顯示的是三個垂直堆疊的矩形，但真實內容載入後卻變成橫向排列的網格，使用者的眼睛得重新適應完全不同的版面配置，這種落差感反而比沒有骨架屏更突兀；第二種是「閃爍」，如果內容其實載入得很快（例如 80 毫秒內就完成），骨架屏一閃即逝反而會被使用者感知成一個不必要的視覺干擾，而不是有幫助的載入提示。針對這個問題，業界的做法通常是先等待兩百毫秒左右，如果到那個時間點內容還沒真正出現，才顯示骨架屏，避免短暫延遲也觸發整套骨架動畫。

如果我用 AI 設計工具生成畫面，該怎麼確保骨架屏被正確設計出來，而不是隨便套一個通用範本？

最容易出問題的地方，是 AI 生成骨架屏時，沒有真正對照這個畫面最終要呈現的實際版面結構，而是套用一個通用、跟內容無關的骨架樣式——例如不管實際內容是商品卡片還是社群貼文，都套用同一套「三個矩形加一個圓形」的固定樣板，這樣一來骨架屏就沒辦法達到「零版面偏移」的效果，因為它的尺寸跟結構本來就沒有真的對應到真實內容。

實務上，比較穩妥的 prompt 寫法，是先明確描述這個畫面載入完成後的真實版面結構（例如「這是一個包含頭像、使用者名稱、三行文字內容、一張附圖的貼文卡片」），再要求 AI 依照這個結構去設計對應尺寸的骨架佔位符，而不是先要求「做一個骨架屏」再讓 AI 自己猜測內容形狀。另外值得留意的是，骨架屏只是解決「感知等待」的問題，不會讓實際載入速度變快，如果實際等待時間本來就長達十秒以上，單靠骨架屏是不夠的，需要搭配進度提示（例如顯示具體正在處理第幾筆資料）才能維持使用者的信任感。