Communitygithub.com

動畫分析

測量動畫密集型網頁(WebGL、滾動影片、著色器特效、粒子場景)的品質與性能,並與參考基準進行公平比較。

動畫分析 是什麼?

此技能專為需要量化評估動畫網頁性能與視覺品質的開發者與AI代理設計。它提供兩大核心功能:一是性能分析,透過嵌入輕量級腳本(frame-meter.js)測量每秒幀數(p50、p95)、長幀數、頁面重量與Web Vitals指標,並給出可重複的數值報告,幫助定位並修復卡頓、負載過重等問題;二是參考評分,透過比對工具(compare-sheet.mjs)生成並排截圖比較表,由獨立評審員根據四關鍵時刻進行公正評級,以判斷「我們的頁面與參考目標有多接近」。此技能涵蓋幀時間預算、滾動品質階梯、紋理與頁面重量預算、以及基於證據的參考評分方法。支援所有現代瀏覽器與行動裝置,建議在最慢的目標設備上進行測量,確保數據反映真實用戶體驗。輸出結果包含可重複的格式,適合納入CI/CD管線或效能預算審查。

相容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/iboss21/regescore-motioncraft-skills/tree/main/plugins/motioncraft/skills/motion-analytics

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

動畫分析 是做什麼的?

動畫品質是可以量化的。「感覺流暢」和「看起來接近參考」只是主觀說法;這個技能會把它們變成下週還能重複驗證的數字。

兩項任務:

  1. 性能分析: 每幀花費多少時間、頁面有多重、以及裝置速度變慢時頁面如何調整。指南:references/performance.md。工具:scripts/frame-meter.js。
  2. 參考評分: 頁面與參考目標或自身設計目標有多接近,進行公平判斷。指南:references/reference-grading.md。工具:scripts/compare-sheet.mjs。

快速開始

測量任何頁面的幀時間

將計量器嵌入頁面,並透過 ?meter 參數開啟頁面:

<script src="frame-meter.js" defer></script>

一個小型讀取面板會顯示 p50、p95 及建議的品質層級,控制台每五秒會記錄一次摘要。您也可以在控制台中執行:

frameMeter.start();          // 開始一次乾淨的測量
// ...滾動頁面,執行關鍵互動...
frameMeter.report();         // { frames, p50, p95, p99, max, fps, longFrames, jank, suggest }

請在您關心的最慢裝置上進行測量,而不是在工作站上。測量期間請滾動整個頁面並執行主要互動,因為空閒幀會隱藏真正耗時的瞬間。

建立並排對比表

node scripts/compare-sheet.mjs ./shots/ours ./shots/reference ./compare --labels "我們的,參考"

此指令會配對相同檔名的圖片,產生 compare.html(總是產生)及 compare.png(當安裝了 sharp 時)。將對比表交給評審員,依照評分指南中的說明進行。

關鍵數字

指標目標原因
幀時間 p95在目標裝置上 ≤ 16.7 毫秒 (60 Hz)p95 才是使用者實際感受到的;中位數會隱藏卡頓
幀時間 p50遠低於 p95兩者差距大表示有尖峰:上傳、垃圾回收、著色器編譯
長幀(超過 50 毫秒)滾動時為 0每一個長幀都是一次可見的頓挫
首屏頁面重量小於 3 MB行動數據上的第一印象
整頁重量小於 10 MB載入時間、數據用量、電池消耗
最大內容繪製 (LCP)小於 2.5 秒在大型資源到來前顯示一個組合好的靜止畫面
累計版面配置位移 (CLS)小於 0.1Canvas 和影片容器必須預留空間
與下次繪製的互動 (INP)小於 200 毫秒沉重的渲染迴圈不得阻塞輸入

每種資產類型的詳細預算和可運作的品質階梯,請見 references/performance.md。

工作流程

  1. 建立基準線。 透過 ?meter 載入頁面,從上到下滾動兩次,執行主要互動,然後讀取 frameMeter.report()。記錄裝置、瀏覽器、視口及數值。
  2. 找出耗費最高的區段。 針對每個區段重複測量:在區段開始時執行 frameMeter.start(),結束後執行 report()。最差的 p95 就是需要最佳化的地方。
  3. 修復原因。 通常是以下其中之一:裝置像素比過高、全解析度的後處理通道、繪製呼叫過多、在滾動過程中上傳紋理、首次顯示時編譯著色器、或在頁面隱藏時進行渲染。請參考性能指南中的修復表格。
  4. 加入品質階梯。 即使是快速的頁面,在弱手機上也需要降級。使用可滾動的階梯程式碼片段:當 p95 超過 22 毫秒時降低一階,低於 12 毫秒時提升一階。
  5. 以相同方式重新測量。 相同裝置、相同路徑、相同持續時間。報告前後數值。
  6. 與目標進行評分。 當頁面重現一個設計或參考外觀時,建立四時刻對比表,並執行 references/reference-grading.md 中描述的三位評審員方法。

報告格式

頁面:<名稱>   裝置:<型號, 瀏覽器>   視口:<寬 x 高, DPR>
路徑:完整滾動 x2 + 主要互動, 60 秒
之前:p50 9.8 毫秒, p95 31.2 毫秒, 長幀 6, 重量 14.1 MB
之後:p50 7.1 毫秒, p95 15.9 毫秒, 長幀 0, 重量 8.7 MB
變更:手機上 DPR 上限 1.5、光暈半解析度、主角紋理改為 WebP 2048、著色器在載入器中預編譯
品質階梯:階層 0 到 3,桌上型電腦穩定在階層 3,測試手機穩定在階層 2

規則

  • 報告 p95,而非平均 FPS。 平均 58 fps 可能隱藏著每秒一次的卡頓。
  • 每個數字對應一種裝置類別。 絕不將筆電與手機的測量結果混在同一個宣稱中。
  • 每次採用相同路徑。 只有當滾動路徑、互動和持續時間完全一致時,測量結果才具有可比性。
  • 也要測量首次冷載入。 第一次觀看時會編譯著色器並上傳紋理,這就是長幀發生的地方。
  • 基於證據進行評分。 「接近」的結論需要對比在匹配時刻的快照,且評審員不能是參與頁面開發的人員。

相關連結

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

相關技能