MotionScore Code Audit

MotionScore Code Audit is an AI skill that grades every Motion & CSS animation in your codebase (or selected files) S-F, right in your editor, and generates a report with a scorecard and specific fixes.

/motion-audit

It's the static, in-editor half of MotionScore. The skill reads your source code and predicts how each animation will perform, so you catch jank before you ship. MotionScore is the other half: it measures how your animations actually perform at runtime in a real browser, and tracks regressions over time. Same S-F grading system, two stages of one workflow.

Your LLM can then follow this report to fix slow animations in your codebase.

Without exceptionally deep knowledge about the rendering pipeline, it's difficult to know how all the various methods of animating, and the CSS values that can be animated, are going to perform.

The Web Animation Performance Tier List covers the theory, but performance gotchas are everywhere and tends to slip as codebases and team sizes grow. This audit catches what manual review misses.

Install

MotionScore Code Audit is available to Motion+ and MotionScore members. Install it by running the following command in your terminal: it will auto-detect and configure all supported editors.

curl -sL "https://api.motion.dev/registry/skills/motion-audit?token=YOUR_TOKEN" | bash

Supported editors:

• Cursor

• Claude Code

• Windsurf

• Amp

• OpenCode

• Gemini CLI

Usage

Run the audit inside a project using the /motion-audit command:

/motion-audit

By default, this will run a broad search of CSS, Motion, GSAP and Anime.js APIs in your codebase.

It's possible to limit the scope by passing a directory or filename:

/motion-audit @components/Button

Additionally, you can request to scope the audit to specific types of animations, or specific APIs:

Can you perform a /motion-audit of all scroll animations

Overall rank

The report starts with an easily-scannable letter ranking. This represents an average ranking of all discovered animations.

## Rank

:'██████::
'██... ██:
.██:::..::
. ██████::
:..... ██:
'██::: ██:
. ██████::
:......:::

Breakdown

Next, you'll receive a full breakdown describing the absolute number of animations for each tier, and the percentage of animations that this tier represents. The idea is for this graph to be top-heavy (more S, A and B tier animations than below).

## Breakdown

S █████████████████░░░░░░░░░  2 · 68%
A ░░░░░░░░░░░░░░░░░░░░░░░░░░  0 ·  0%
B ░░░░░░░░░░░░░░░░░░░░░░░░░░  0 ·  0%
C ████████░░░░░░░░░░░░░░░░░░  1 · 32%
D ░░░░░░░░░░░░░░░░░░░░░░░░░░  0 ·  0%
F ░░░░░░░░░░░░░░░░░░░░░░░░░░  0 ·  0%

Findings

In findings, there's an entry for every actionable animation that explains:

• What: Filename, line numbers and tier

• Why: The values being animated, what parts of the render pipeline they trigger

• Impact: Is it worth fixing/changing?

• Improvements: How to improve performance (where possible)

For instance, an animation like this:

<motion.div
  animate={{
    scale: [1, 2, 2, 1, 1],
    rotate: [0, 0, 180, 180, 0],
    borderRadius: ["0%", "0%", "50%", "50%", "0%"],
  }}
  transition={{ repeat: Infinity }}
/>

Will flag that as these scale and rotate values are always animating together, we can animate transform directly to run this entirely on the GPU:

<motion.div
  animate={{
    transform: [
      "scale(1) rotate(0deg)",
      "scale(2) rotate(0deg)",
      "scale(2) rotate(180deg)",
      "scale(2) rotate(180deg)",
      "scale(1) rotate(0deg)",
    ],
    borderRadius: ["0%", "0%", "50%", "50%", "0%"],
  }}
  transition={{ repeat: Infinity }}
/>

Anti-patterns

This lists general patterns that can affect animation performance, like detecting filter: blur(>10px), long running off-screen animations, excessive use of will-change etc.

For example, the animation from before is repeat: Infinity, so this part of the report will suggest that performance could be improved by swapping animate to whileInView, thereby only running the animation while inside the viewport.

<motion.div
  whileInView={keyframes}
  transition={{ repeat: Infinity }}
/>

Accessibility

This part of the report looks for things like support for prefers-reduced-motion or rapidly flashing animations and suggest ways to fix.

Top 3 Recommendations

The report concludes with the top 3 priority fixes. This is a summary of the worst offenders, so you can ask your LLM to "fix the top 3 issues", or simply "fix" to fix everything in the report.

Tiers

The broad tier list used for grading animations is as follows:

Tier	Cost	Animated properties
S	Compositor only	transform, opacity, filter, clip-path, ScrollTimeline
A	JS → Compositor	Same properties, but set from JavaScript each frame
B	One-time layout read → S/A	layout, layoutId
C	Repaint each frame	background-color, color, border-radius, box-shadow, CSS variables, SVG attributes, View Transitions
D	Layout + repaint each frame	width, height, margin, padding, top/left, font-size, gap
F	Forced sync layout per cycle	Interleaved DOM reads/writes, :root CSS variable animation

The full explanation of these can be found in the Web Animation Performance Tier List.

Code Audit vs MotionScore

The Code Audit is prevention: it reads your source statically, in your editor, so jank never ships. It can't measure what it can't run, so it predicts cost from the properties and methods you animate.

MotionScore is proof: it loads your live site in a real browser and measures what animations, scroll animations, GPU pressure and style/layout thrashing actually cost at runtime, tracks regressions over time, and can gate your CI. It's a subscription because performance is something you monitor, not check once.

Use both. Catch it in the editor with the Code Audit, then verify and keep it honest in production with MotionScore. Same S-F grading system across both, so the grades mean the same thing.