Lottie 動畫指南：為網站注入輕量動態特效

設計師交來一支精美的首頁動畫，你打開原始檔，要嘛是 8MB 的 GIF、要嘛是更大的 MP4。放上去，畫面是動起來了，網站卻跟著慢到像在拖重物。Lottie 就是為了解決這件事而生的。它用一份純文字的向量描述檔，取代整段影片，體積常常僅有 GIF 的十分之一不到，而且不管放到多大都不會失真。

這篇會把 Lottie 從運作原理、檔案格式選擇、設計到上線的完整工作流、WordPress 主流編輯器的整合方式，到效能地雷一次講清楚。不管你是用 Divi、Elementor 還是手刻網站的設計師或行銷人，看完都能判斷「這個畫面該不該用 Lottie，以及怎麼用才不會反過來拖垮你的 Core Web Vitals」。如果你正在重看網站的UI/UX 設計基礎，這會是動態層次很重要的一塊拼圖。

快速重點整理：

• Lottie 是 Airbnb 於 2017 年開源的動畫函式庫與生態系，常用 JSON 描述動畫資料，再由播放器即時渲染（見 開源專案頁）。
• 同一段動畫，Lottie 檔案大小通常是 GIF 的數分之一，且可無限縮放不失真。
• 它不是萬靈丹。太複雜的特效、大量同時播放、缺少降級機制，都會反過來吃掉 CPU、拖慢互動。
• 在 WordPress 裡，Divi、Elementor、Bricks 都有成熟的接法，Divi Supreme Pro 甚至內建專屬 Lottie 模組（見 官方功能頁）。
• 選對情境用，它會是提升質感的利器；選錯情境，它就是另一個效能負擔。

Lottie 到底是什麼：一段向量描述為什麼能取代影片

要真正用好 Lottie，你得先搞懂它跟 GIF、影片在「本質」上的差異，不然僅會把它當成「比較小的 GIF」來用，那會錯過它最有價值的部分。

Lottie 最初是 Airbnb 工程團隊在 2017 年開源的專案，目標很單純：讓 After Effects 做好的動畫，能夠直接在 iOS、Android、網頁上以原生方式播放，而不必匯出成影片或逐幀圖片（Lottie 專案與 LottieFiles）。它的核心是一套渲染引擎加上一份開放的資料格式，原始碼至今仍託管在 GitHub 上的 Lottie 儲存庫 持續維護。

運作原理是這樣的：動畫師在 After Effects 裡完成動畫，透過一套叫做 Bodymovin 的外掛，把每一個圖層的形狀路徑、變形、旋轉、透明度、關鍵影格，全部轉譯成一份 JSON 文字檔。這份檔案記錄的不是像素，而是「怎麼畫」的指令。當使用者打開網頁，播放器讀進這份 JSON，再用 SVG 或 Canvas 即時把動畫重新畫出來。

GIF 像是一卷拍好的底片，每一格都已經是固定的像素，放大就糊、縮小就浪費。Lottie 則像是一份樂譜，瀏覽器是演奏者，每次播放都重新演奏一遍。樂譜本身很輕，演奏出來的畫面卻很豐富，而且不管你換到多大的螢幕，演奏出來的音質都不會變差，因為它本來就不是錄音，是現場演奏。這就是向量本質帶來的優勢。

也因為它是向量描述，所以同一份檔案，你可以今天當作手機載入動畫、明天放大成活動主視覺的背景，完全不必重新出圖。這種「一次製作、處處可用」的特性，是 GIF 永遠做不到的。

為什麼 2026 年你該認真考慮把 GIF 換掉

GIF 在短暫趣味循環、社群貼文等情境仍有用途，但放在網站主視覺時，檔案體積與色彩限制通常較不利。頁面速度與 Core Web Vitals 是眾多搜尋訊號中的一部分，相關性與內容品質仍更重要；選擇格式時，首要考量應是實際載入與使用體驗，相關背景可見 Google Search Central Blog 上 2018 年 1 月的〈Using page speed in mobile search〉與 2020 年 5 月的〈Evaluating page experience〉。

web.dev 的說明很直白：當頁面載入時間從 1 秒拉長到 3 秒，跳出率會大幅上升，使用者根本沒耐心等你那支「很可愛」的動畫載完（見 web.dev 的速度研究）。這不是感覺問題，是真金白銀的流量問題。

以下列出 GIF 在現代網站上的幾個致命傷：

• 體積膨脹。GIF 最多僅支援 256 色，為了模擬漸層會產生大量雜訊，壓縮效率極差。一支三秒鐘的複雜動畫，GIF 動輒 2 到 8MB 是常態，同樣內容的 Lottie JSON 通常僅有幾十 KB。
• 畫質上限低。256 色在現代的 Retina 螢幕上看起來就是會有顆粒感和色階斷層，尤其是漸層和陰影部位特別明顯。你的品牌色如果不在那 256 色裡，還會被強制近似，等於變色。
• 無法縮放不失真。GIF 是點陣格式，放大就糊。你為首頁做的動畫，拿到產品頁要用就糊掉，僅好再出一版更大的檔案。
• 沒有透明度的平滑支援。GIF 的透明是「全有或全無」的二值透明，邊緣會有明顯的鋸齒光圈。Lottie 用向量，邊緣是數學曲線，天然平滑。
• 無法被程式控制。GIF 播就是播，你不能讓它在滑鼠靠近時暫停、在捲動到視窗時才開始、在使用者開啟減動偏好時自動關掉。Lottie 全做得到。

換句話說，GIF 是一個為 1990 年代設計的格式，它的天限在現代的高畫質、講究效能的網站上會被放大檢視。如果你還在用它承載主要的品牌動畫，真的該重新考慮了。想更全面理解各種圖片格式的取捨，可以回頭看這篇WebP、JPG、PNG 圖片格式深度比較，把靜態和動態的選擇邏輯一起想清楚。

dotLottie 登場：.json 與 .lottie 兩種檔案格式怎麼選

很多人以為 Lottie 就是一種檔案，其實它有兩種主流格式，選錯會直接影響載入速度和管理成本。這是大部分教學文會跳過、卻很實用的決策點。

第一種是.json，也就是 Lottie 最原始的格式。它就是一份純文字的 JSON，任何人用文字編輯器都打得開。好處是相容性最廣，幾乎所有播放器都支援；壞處是它沒有壓縮，動畫稍微複雜一點，檔案就會膨脹到幾百 KB 甚至破 MB，而且一份動畫就是一個獨立檔案，要打包多支動畫時很零散。

第二種是.lottie，也就是 dotLottie 格式。它是開放的封裝格式，以 ZIP 壓縮打包動畫、資產與設定，也能在單一檔案中容納多個動畫（見 dotLottie 官方格式說明）；實際縮減幅度取決於動畫內容與資產，不能用固定比例保證（dotLottie 官方文件）

兩者的選擇邏輯整理如下：

面向	.json（原始 Lottie）	.lottie（dotLottie）
壓縮	無壓縮純文字	壓縮打包，實際幅度依動畫內容而定
單檔多動畫	一檔一動畫	可包多支動畫與設定
播放器相容	幾乎全部支援	需用 dotLottie 播放器或相容函式庫
可讀性	文字編輯器直接看	需解壓縮才能檢視內容
適合場景	開發階段、需要直接修改參數	正式上線、多動畫管理、追求最小體積

實務上的習慣是：開發和溝通階段用 .json，因為透明、好檢查、好改參數；要交付上線、尤其是一個專案裡同時用好幾支動畫的時候，就打包成 .lottie，一次載入、一次管理。如果你的網站有大量重複使用的微互動動畫，dotLottie 的單檔多動畫特性會讓你的資產管理清爽很多。

不僅是 GIF 替代品：五種動態呈現方式全面比較

把 Lottie 僅跟 GIF 比是不夠的。網站上能呈現動態的方式至少有五種，每一種的適用場景和成本結構都不同。選錯工具，再好的設計也會被技術拖累。

方式	體積	畫質/縮放	製作門檻	可控性	適合場景
GIF	大（MB 級）	256 色、放大糊	低	幾乎無	社群貼文、簡單趣味循環
MP4/WebM 影片	中大	高、但點陣	中	播放控制為主	實拍影片、複雜光影動畫
CSS 動畫	極小（內嵌）	向量、平滑	中（要寫程式）	高	UI 轉場、按鈕回饋、載入旋轉圖
SVG SMIL / 動畫	小	向量	中高	中	圖示等級的細微動態
Lottie	小（KB 級）	向量、無限縮放	中高（需 AE）	高（可程式控制）	插畫級品牌動畫、複雜向量動態

從這張表可以歸納出一個判斷原則：越簡單、越結構化的動態，越該用 CSS 或 SVG 解決；越需要插畫感、多圖層、有節奏設計的品牌動畫，才是 Lottie 的主場。

舉個具體例子。一個按鈕被點擊時的輕微彈跳，用 CSS transform 加幾行 keyframes 就搞定，根本不需要動用 After Effects 匯出 Lottie，那是殺雞用牛刀。但如果你的CTA 設計需要在按鈕裡放一個會律動的吉祥物、或品牌 Logo 上線時有一段精心設計的進場動畫，那 Lottie 就是對的工具，因為那種複雜度用 CSS 寫起來會非常痛苦且難以維護。

影片（MP4/WebM）則佔據另一個極端：實拍內容、有真實光影和粒子特效的動畫，Lottie 渲染不出來，這時還是得用影片。記住，Lottie 強項是「向量插畫動起來」，不是「取代所有動態」。如果你的素材是照片而非向量插畫，想做出立體動態則有另一條路，可參考把 2D 照片轉成 3D 動畫的做法，再決定最終的呈現方式。

實務上，一個成熟的網站很少僅用單一方式，而是混合搭配。首頁 hero 區用一支精心製作的 Lottie 品牌動畫當門面，產品卡片上的 hover 效果用 CSS 處理，使用者上傳檔案時用 MP4 影片做背景。把每一種工具放在它最擅長的位置，整個網站的動態層次才會豐富又不笨重。最怕的是那種「學了新工具就到處用」的衝動，把所有動態一律換成 Lottie，結果簡單的按鈕回饋也走 AE 匯出流程，團隊效率反而被拖垮。工具是來服務你的判斷，不是來取代你的判斷。

從 After Effects 到上線：Lottie 完整工作流拆解

知道為什麼用之後，接著是怎麼做。一條完整的 Lottie 生產線可拆成五個階段，不管你是設計師還是接手設計師檔案的工程師，都能照著走。

階段一：在 After Effects 裡設計動畫

這是一切的起點。動畫師在 After Effects 裡用形狀圖層、路徑、變形來做動畫。這裡有個關鍵認知：不是 After Effects 做得出來的特效，Lottie 都吃得到。Lottie 僅支援向量屬性的動畫，像是形狀路徑、位置、縮放、旋轉、透明度。它不支援某些複雜效果，例如粒子系統、某些混合模式、3D 圖層、部分文字動畫。所以在設計階段就要有意識地避開這些地雷，否則匯出後會發現動畫在瀏覽器裡跟你在 AE 裡看到的不一樣，那就是悲劇的開始。

階段二：用 Bodymovin 匯出 JSON

設計好之後，安裝 Bodymovin（現在也整合進 AE 的 Extensions 面板），把合成匯出成 .json。匯出時有幾個設定要注意：勾選適當的壓縮選項可以縮小檔案，但過度壓縮有時會犧牲精度；如果動畫有用到點陣圖素材，記得確認它們被正確嵌入或獨立存放。

階段三：挑選播放器

有了 JSON 或 dotLottie 檔案，接著要選播放器把它渲染出來。網頁常用 lottie-web，支援 SVG、Canvas 與 HTML 渲染；.lottie 則可搭配 dotLottie 的 web 播放器（見 LottieFiles 文件）。SVG 便於操作 DOM，Canvas 可避免大量 SVG 節點，但何者較快仍取決於動畫與裝置，應實測決定。

階段四：嵌入網頁

嵌入方式取決於你的技術棧。純手刻網站，引入播放器腳本後用幾行 JavaScript 載入動畫即可。用框架的話，lottie-web 有對應的 React、Vue 包裝。重點是要掌控動畫的觸發時機：不要一股腦讓所有動畫在頁面載入時就全部開跑，那會讓首屏的 CPU 瞬間滿載。更好的做法是讓動畫在使用者捲動到該區塊時才啟動，這牽涉到延遲載入的觀念，跟Lazy Loading 延遲載入的思路是一致的。

階段五：測試與優化

上線前一定要在中階手機（不是你的旗艦機）上實測。桌面開發機的效能太好，會給你一種「很順」的錯覺，等到真實使用者的中階安卓機上場，卡頓才會現形。這也是後面「效能地雷」那段特別強調的點。

LottieFiles 生態系：動畫素材從哪裡來、要不要付費

不是每個團隊都有動畫師，也不是每支動畫都值得從零做起。LottieFiles 提供素材、編輯與協作工具，是常見的 Lottie 平台之一。使用前應依專案需求與授權條款判斷自製或採購。

免費素材庫：快速驗證概念的起點

LottieFiles 上有一個龐大的免費素材庫，涵蓋載入動畫、成功提示、按鈕微互動、節慶主題等常見類型。對剛起步、還在驗證「動畫到底能不能提升轉換」的團隊來說，這是成本最低的切入點。你不必先投資動畫製作的人力，就能把幾支現成動畫放進頁面，用數據看看使用者到底反應如何。若你需要的不是動畫而是靜態的照片、向量圖與 Icon，可以同時參考我們整理的商用免費圖庫清單。

免費素材有幾個使用上的注意事項，不能裝作沒看到。第一是授權條款，多數免費素材允許商用，但有些會要求署名或禁止單獨轉售，下載前務必讀清楚。第二是品牌一致性，現成素材是給所有人用的，你的競爭對手也可能用同一支動畫，所以它適合放在功能性位置（例如表單送出後的打勾回饋），不適合放在需要強烈品牌識別的地方（例如首頁 hero 區的 Logo 動畫）。第三是檔案品質參差，有些免費動畫的關鍵影格設計不夠細緻，循環時會有明顯的跳接，上線前要逐幀檢查。

付費方案：當免費不夠用的時候

當你對動畫品質的要求提高、或需要更高級的編輯工具，LottieFiles 提供 付費方案，涵蓋進階素材、線上編輯器、團隊協作等功能。它的定價是訂閱制，對個人創作者和小團隊來說門檻不高，但對預算敏感的專案，你要算清楚「一個月的訂閱費，換來的素材和工具，能不能真的幫你省下等值的設計時數」。

付費方案的價值可能來自素材，也可能來自線上編輯、測試與協作工具。若團隊經常調整速度、顏色或迴圈行為，可把節省的作業時間與訂閱成本一起評估（工具細節見 LottieFiles 文件）。

自製還是採購：一個簡單的判斷框架

到底該自己用 After Effects 做，還是從平台買？可用一個判斷框架來決定，供你參考。問自己三個問題：這支動畫是否承載品牌核心識別？它會不會被長期、反覆使用？它的設計是否有業界標準可循？

如果三個答案都是「是」，那值得自己做或找動畫師客製，因為品牌識別和長期價值值得這筆投資。如果都是「否」，例如僅是一個通用的載入旋轉圖，那直接從免費或付費庫裡挑一支就好，別把團隊精力花在重複造輪子上。混合策略最常見：品牌動畫自己畫，功能性微互動用現成素材，兩邊各取所長。

不過別忘了這個資產管理原則：不管素材是自製還是買的，最終檔案都要下載到你自己控管的空間，不要長期依賴平台的外連。平台會改規則、會調整連結結構，你今天能連到的動畫，不代表明年還連得到。把素材當成網站資產的一部分來管理，跟你的圖片、影片放在同一個資料夾結構裡，這才是可維護的做法。

WordPress 三大主流編輯器怎麼接 Lottie

WordPress 站長通常不會想為了放一支動畫就手寫 JavaScript，主流頁面編輯器也各有現成的整合方式。以下整理 Divi、Elementor 與 Bricks 的做法；主要使用 Divi 的讀者，可參考Divi 主題與 Builder 設定，再依需求串接動畫。

Divi：用 Divi Supreme Pro 的 Lottie 模組

Divi 本身沒有原生 Lottie 模組，但透過 Divi Supreme Pro 這套擴充外掛，你可以直接拿到一個專屬的 Lottie 模組，把 JSON 或 dotLottie 檔案餵進去就能顯示，還能設定迴圈、速度、對齊（見 Divi Supreme Pro 官方頁面）。對不想碰程式的 Divi 使用者來說，這是最省事的路。這套外掛的其他模組在先前的評測中整體功能密度也很高，值得一看Divi Supreme 模塊擴充評價。如果你還在比較 WordPress 的編輯器陣營，7 款最佳視覺化頁面編輯器深度評測能幫你定位。

Elementor：使用原生 Lottie widget

Elementor 已提供原生 Lottie widget，可上傳 JSON 或使用外部來源，並設定觸發、循環、渲染器與延遲載入；這個元件需要 Elementor Pro，還沒購買的話，用 HTML 或 shortcode 小工具貼上播放器代碼，同樣能把動畫放進頁面（見 Elementor 的 Lottie widget 說明）。若原生控制不敷需求，再評估第三方外掛或自訂程式碼。若網站仍在打底階段，可先看Elementor 完整教學建立基礎觀念。

Bricks Builder：用自訂 HTML 或框架整合

Bricks 是近年竄起的視覺化編輯器，走的是更貼近開發者的路線。在 Bricks 裡接 Lottie，最直接的方式是用它的 HTML 元素載入播放器腳本，或搭配它對動態資料的支援，把 Lottie 檔案當作一個欄位來管理。Bricks 的程式碼輸出比 Divi、Elementor 乾淨，如果你的網站對效能很敏感，這會是個加分點。

不管你用哪一套，有一個共通原則：動畫檔案要放在你控管的空間，不要長期依賴第三方的外連 CDN。理由很實際，第三方服務一旦變更連結規則或下線，你的動畫就消失了。把檔案放進自己的媒體庫或主機，搭配你既有的網站速度優化策略一起管理，比較可靠。

Lottie 不是免費的：效能與 SEO 的真實代價

Lottie 雖然常有較小的傳輸檔案，但執行階段仍需即時渲染，複雜動畫或同時播放多支動畫可能占用 CPU，並影響互動流暢度。影響程度取決於動畫節點、播放器、裝置與頁面其他工作，應以實機與 Core Web Vitals 測試判斷；可對照 Google Search Central Blog 在 2020 年 5 月的〈Evaluating page experience〉。

以一個美妝保養品牌的形象網站為例，常見的做法是在首頁疊四支 Lottie 當產品氛圍點綴，全部設成自動無限迴圈；桌面上漂亮得很，一到中階安卓機，互動就開始卡頓。問題不在單一支動畫，而在「四支同時無限迴圈」這個組合。每一支動畫都在背景持續運算，CPU 從沒有喘息的時候，使用者在按鈕、表單上感受到的回應就變遲鈍了。

這件事跟 Core Web Vitals 裡的 INP（Interaction to Next Paint）直接相關。INP 衡量的是使用者操作後到畫面更新之間的延遲，而背景裡狂跑的 Lottie 動畫，正是會把這個數字拉高的兇手之一。如果你的網站正在為Core Web Vitals 分數奮鬥，Lottie 的使用一定要納入管理。

以下列出幾個會吃掉效能的常見做法，這些都是實務上常見的坑：

• 無腦設成無限迴圈。一支沒完沒了跑的動畫，等於讓 CPU 永遠不休息。能設成播放一次或限定次數的，就別用無限。
• 同時啟用太多支。同時播放的動畫越多，渲染負擔通常越高；實際上限應以目標裝置測試，不能用固定支數判定。
• 用 SVG 模式渲染大量動畫。SVG 模式會在 DOM 裡產生大量節點，動畫一複雜，DOM 操作成本就暴增。這種情境改用 Canvas 模式會穩得多。
• 不暫停視窗外的動畫。使用者已經捲到頁面下方了，首頁那支動畫還在背景繼續跑，純粹浪費運算。
• 沒有延遲載入。首屏之外的動畫，沒必要在頁面一打開就跟著載入，會拖慢 LCP（Largest Contentful Paint）。

對應的解法其實不難，而且跟你已經在做的事是同一套邏輯：視窗外暫停、非首屏延遲載入、控制同時播放數量、能用 CSS 解的就別上 Lottie。這些觀念跟圖片最佳化、快取設定是相通的，差別僅在對象從「檔案體積」換成「執行成本」。如果你對整體效能調校還沒有完整地圖，這篇網站慢到爆的診斷與解法可以當作配套閱讀。

上線前必看的常見渲染問題與除錯

就算工作流都走對了，Lottie 在從 After Effects 搬到瀏覽器的過程裡，還是會出現幾類典型的「怎麼跟設計稿長得不一樣」的狀況。這些問題多半源自 Lottie 的格式支援範圍跟 After Effects 完整功能之間的落差，跟工具本身的穩定度無關。知道落差在哪，你才不會在交付前夕手忙腳亂。

特效不支援：最常見也最致命

Bodymovin 匯出時，遇到它不支援的特效，有時會直接忽略、有時會匯出但播放器渲染不出來，結果就是動畫在瀏覽器裡「少了一塊」。最常踩到的不支援項目包括：粒子系統、部分混合模式、3D 圖層的真正三維深度、某些路徑修剪的進階設定、以及複雜的文字動畫。設計師如果習慣在 AE 裡大量使用這些效果，匯出前一定要用 LottieFiles 的線上預覽工具先跑一次，確認哪些效果掉了，再決定是要改用替代做法，還是退回去用影片。

顏色與漸層偏差

有時候你會發現動畫的顏色在瀏覽器裡比 AE 裡淡一點或飽和度不同。這通常是色彩空間的問題。After Effects 預設的工作色彩空間跟瀏覽器渲染的色彩空間不見得一致，漸層尤其敏感。除錯的方法是匯出後在目標瀏覽器裡跟設計稿並排比對，一旦發現偏差就得回到 AE 裡微調，別指望播放器替你做色彩校正。把這個比對動作排進交付流程，能省下無數次的「怎麼又跑掉了」往返。

檔案匯出後動畫變形或跳針

另一個常見問題是動畫看起來「卡卡的」或在迴圈接縫處有明顯跳動。原因通常是關鍵影格的設定不夠乾淨，例如第一幀和最終一幀的狀態沒有對齊，迴圈接起來就會有一次頓挫。修正方式是回到 AE 確保迴圈的首尾狀態一致，或在匯出時啟用對應的迴圈選項。這類問題在「無限迴圈」的動畫上特別明顯，因為它會被放大、反覆看到。

跨播放器與跨瀏覽器差異

lottie-web 的 SVG 模式和 Canvas 模式在某些邊緣案例下會有細微差異，不同瀏覽器對 Canvas 和 SVG 的處理也略有不同。實務上，建議至少在 Chrome、Safari、Firefox 三個桌面瀏覽器加上 iOS Safari 和一個安卓瀏覽器上各跑一次，特別是當你的動畫有用到遮罩或複雜路徑時。這個跨平台驗證的習慣，跟你在做響應式設計時的測試邏輯是一致的，差別僅在對象從版面變成動畫。

把這些除錯動作當成工作流階段五（測試與優化）的一部分，視為常規流程而非額外負擔。一次把這些問題在交付前清掉，比你上線後才收到客戶反映「動畫怪怪的」再回頭修，成本要低得多。設計師和工程師如果在這一關有共同的檢查清單，整個交付流程會順很多，也減少彼此來回踢皮球的機會。

什麼情境下不建議使用 Lottie

這一節是反過來說的。Lottie 再好，也有它不該上場的時候。誠實地講出這些，比一味推銷它更有價值，因為選錯工具的成本，最終是你要承擔的。

第一種情境：你需要的是實拍影片的質感。Lottie 是向量動畫，它渲染不出真實的光影、攝影機景深、煙霧粒子這類效果。如果你的首頁 hero 區需要的是一段電影質感的實拍畫面，硬要用 Lottie 去模擬，結果僅會是「看起來很努力但很假」。這時候該用 MP4 或 WebM，然後做好影片壓縮。

第二種情境：動畫簡單到用 CSS 就能解決。一個 hover 時旋轉個 15 度的圖示、一個載入中的轉圈圈，這種等級的動態，CSS transform 配 transition 或 keyframes 三兩行就寫完，檔案幾乎是零成本。為這種小事去走 After Effects 匯出 Lottie 的流程，是把自己和團隊的工作流複雜化，沒有任何回報。

第三種情境：團隊沒有合適的動畫製作流程。客製 Lottie 常以 After Effects 與 Bodymovin 製作，但也可使用其他相容工具或現成素材。若團隊不打算建立製作與測試能力，可從素材平台挑選並核對授權（如 LottieFiles）；現成素材仍要評估品牌一致性與方案成本（可對照 LottieFiles 的定價）。

第四種情境：你的網站效能已經在懸崖邊。如果你的 Core Web Vitals 分數本來就很勉強，主機也普通，這時候再疊幾支 Lottie 上去，等於是壓垮駱駝的最終一根稻草。先把你既有的效能債還一還（圖片壓縮、快取、移除沒用的外掛），等分數站穩了，再回來談要不要加動態。這就像裝潢房子，地基還沒補好就先掛水晶燈，順序不對。

無障礙與降級：讓動畫對每個人都友善

這一段是很多動畫教學完全沒提，但不能少的。動畫是體驗加分，但它不該成為某些使用者接觸你內容的障礙。

有一部分使用者對動態特別敏感，持續的動畫會讓他們感到不適，甚至引發前庭功能的症狀。作業系統和瀏覽器早就提供了 prefers-reduced-motion 這個媒體查詢，讓使用者表達「我希望少一點動態」。一個負責任的網站，應該要讀取這個偏好，在它被開啟時，把 Lottie 動畫暫停、降成靜態首幀，或乾脆不顯示。lottie-web 的播放器有提供對應的 API 可以做到這件事，關鍵是你有沒有意識要去處理。

除了減動偏好，還有兩個基本的無障礙動作：

• 給動畫一個暫停的控制。對會自動播放、尤其是無限迴圈的動畫，提供一個明顯的暫停按鈕或鍵盤捷徑，讓使用者可以主動喊停。
• 不要用動畫傳達關鍵資訊。動畫是輔助、是氣氛，不是資訊本身。一個「上傳成功」的狀態，不能僅靠一支打勾動畫來表達，要同時有文字狀態，這樣使用輔助技術的人才讀得到。

把動畫做好，不僅是讓它好看、讓它順，還包括讓它在該退場的時候安靜地退場。這三者缺一個，都算不上完整的動態設計。如果你在規劃整體的設計趨勢，最新的網頁設計趨勢也值得一起參考，把動態放進更大的設計脈絡裡想。

把它放進你的設計決策裡：三個關鍵判斷

講到這裡，先把核心的決策邏輯濃縮成三個問題，讓你下次面對一個「要不要用 Lottie」的抉擇時，能快速定位。

問題一：這個動態是向量插畫等級，還是 UI 微互動等級？前者是 Lottie 的主場，後者用 CSS 就好。把工具跟複雜度對上，才不會浪費。

問題二：同一個頁面會同時跑幾支動畫？如果超過兩支還都無限迴圈，請重新設計觸發邏輯。視窗外暫停、按需播放，是基本動作。

問題三：減動偏好和無障礙你處理了嗎？這不是加分題，是及格線。一支沒有降級機制的動畫，再漂亮也是不及格的設計。

現在就能動手的行動清單

如果你讀到這裡，心裡已經在想自己網站上那幾支動畫到底用對了沒，那就對了。下面是建議的下一步，從今天就能開始做。

1. 盤點現有動畫。把你網站上所有 GIF、自動播放影片、Lottie 動畫列出來，標記每一支的用途和所在的頁面。很多人做完這一步才發現，原來自己首頁上塞了那麼多動態。
2. 把 GIF 換成 Lottie 或 CSS。凡是品牌動畫等級的 GIF，規畫用 Lottie 取代；凡是 UI 微互動等級的，用 CSS 重寫。這一步直接改善體積和畫質。
3. 檢查播放策略。把無限迴圈改成有意義的次數或事件觸發；把視窗外的動畫接上暫停邏輯。這兩個動作對 INP 的改善最直接。
4. 加上 prefers-reduced-motion 降級。全域讀取這個偏好，在它開啟時讓所有 Lottie 動畫靜止。這是無障礙的基本功，也顯示你的專業度。
5. 上中階手機實測。不要僅在你的旗艦機和開發機上驗收。找一台中階安卓機，打開你的網站，實際操作按鈕、表單、捲動，感受一下互動回應。真實使用者的體驗，僅會在這台機器上現形。

動畫是網站質感的放大器，用對了，它讓品牌更有溫度、讓互動更有人味、讓訪客停留久一點；用錯了，它僅是另一個讓網站變慢、讓使用者煩躁的負擔。差別就在你有沒有把「為什麼用」和「怎麼用得節制」想清楚。載入動畫的設計觀念是相通的，這篇Figma 載入動畫教學可以當延伸閱讀，把「等待」這件事也設計得更體貼。

Lottie 不是銀彈，沒有任何單一技術是。但在對的情境裡，它確實是目前把向量動畫放進網站最輕盈、最可控的選擇。關鍵永遠不在於你用了多酷的技術，而在於你為什麼用它、用它用得多節制。想清楚這兩件事，你的網站動態就會是加分，不是負債。