A motion budget is a pre-agreed cap on how much animation a single page may spend — counted in animated moments, main-thread time, and layout stability — so that motion never pushes Core Web Vitals out of their pass thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1. In practice, a marketing landing page might afford 4–6 well-chosen animated moments (hero entrance, one scroll reveal, button micro-interactions, a nav transition), while a blog post might afford only 2–3 (link hover states, one reveal). You decide the budget on paper before a single tween is written; designers and developers then allocate within it the way an engineer allocates bytes in a performance budget. Motion without a budget is how sites end up with a hero video, twelve scroll-triggered fades, a page-transition overlay, and a slider that all look great in isolation and tank LCP, INP, and CLS together.
This guide explains what a motion budget contains, how to allocate by page type, the Core Web Vitals thresholds that define “affordable,” how to count animated moments, a prioritization matrix for choosing what earns animation, worked budget examples for a hero-heavy agency site, and how to enforce the budget in code review. It connects to broader practice in motion web development and to production systems documented in GSAP motion systems in production.
What a motion budget actually is
A motion budget answers one question: on this page, what is animation allowed to cost? Like a performance budget in bytes, it has three layers:
- Moment budget — how many distinct animated elements or transitions the page may contain.
- Main-thread budget — how much JavaScript-driven animation work (tweens, ScrollTriggers, parallax) the page can schedule without harming INP.
- Stability budget — which elements are allowed to move space around (layout-triggering animations), keeping CLS under 0.1.
LCP gets its own constraint: the Largest Contentful Paint element (hero image, headline block) must paint fast, which usually means it must not wait behind a complex entrance timeline. The budget makes that trade-off explicit instead of accidental.
Core Web Vitals thresholds your budget must respect
Field thresholds (good range) per web.dev on Core Web Vitals:
| Metric | Good | What breaks it with motion |
|---|---|---|
| LCP | < 2.5s | Hero entrance delays paint; lazy hero video; fonts blocking headline |
| INP | < 200ms | Long JS timelines on interaction; scroll handlers; heavy GSAP setups |
| CLS | < 0.1 | Elements animating layout (height, margin, top) rather than transform/opacity |
Read the thresholds as hard walls, not aspirations. If your animation plan needs the hero headline to fade in over 800ms after a 400ms delay, you have already spent LCP time on decoration. The budget forces that conversation before design lock.
Counting animated moments
Define a moment as one user-perceivable animation event on a page view:
- A hero entrance sequence = 1 moment (even if it has 8 tweens).
- A scroll-revealed section = 1 moment per section revealed.
- A page transition overlay = 1 moment (but it taxes every navigation).
- Button hover micro-interaction = 1 moment (usually CSS, cheap).
- An autoplaying carousel slide = recurring moments — count conservatively.
Count what a typical session actually triggers, not what exists in the codebase. A section below the fold that 10% of visitors scroll to still costs main-thread setup for everyone if ScrollTrigger initializes eagerly — so budget for initialization cost too, not only perceived motion.
Allocating budget by page type
Landing pages (hero-heavy)
Landing pages sell with one big impression. Spend the budget on the hero and one or two supporting moments; keep everything else still. Typical budget: 4–6 moments, transform/opacity only, LCP element painted before or independent of the entrance timeline.
Product and solution pages
More sections, more evidence, more scroll. Allow 5–8 moments, but stagger reveal thresholds so only one section animates at a time, and prefer CSS for anything below the fold that can be one-shot.
Blog and resource pages
Content is the product. Budget 2–3 moments: nav behavior, one optional TOC/reveal, link and button micro-interactions. No scroll-jacking, no parallax, no transition overlay on long-form reading. If you add a page transition, read the constraints in page transitions, INP, and Core Web Vitals first.
Interactive tools and pricing calculators
INP is the binding constraint. Reserve the main-thread budget for the tool itself; motion here should be nearly zero beyond focus states and result transitions under 200ms.
Prioritization matrix: what earns a moment
When requests exceed the budget, score each candidate:
| Candidate | User value (1–5) | Perf cost (1–5) | Decision |
|---|---|---|---|
| Hero entrance tied to brand | 5 | 2 | Fund first |
| Primary CTA micro-interaction | 4 | 1 | CSS, always fund |
| Scroll reveal on evidence sections | 3 | 2 | Fund if budget remains |
| Full-screen page transition | 2 | 5 | Cut or gate to same-origin, cached |
| Parallax background | 2 | 4 | Cut on content pages |
| Autoplay logo marquee | 1 | 3 | CSS-only or cut |
Rule of thumb: fund moments with value ≥ cost + 2. Anything else needs a sponsor willing to trade a CWV point.
Example budgets: hero-heavy agency site
Homepage (conversion-focused agency site):
- Hero: 1 moment — headline + subcopy stagger using transform/opacity only; hero image eager, high priority, not gated behind JS.
- Primary CTA: 1 moment — CSS hover/active, under 150ms.
- Logo/proof strip: 1 moment — CSS marquee, paused for reduced motion.
- Two feature sections: 2 moments — one-shot reveals via IntersectionObserver or lightweight ScrollTrigger.
- Case study cards: 1 moment — hover lift (transform only).
- Total: 6 moments · LCP element unpromoted by timeline · CLS-safe transforms only · main-thread animation work under ~50ms per interaction region.
Blog template: nav + progress indicator (1) + in-article optional reveal (1) + link states (CSS, 0 JS) = 2 JS moments. Template page templates should encode these caps as defaults, not per-article decisions.
How to enforce the budget in code review
A budget nobody checks is a wish. Enforcement mechanisms that work:
- Document the budget in the page template (design file annotation + ticket acceptance criteria): “Homepage motion budget: 6 moments, LCP < 2.5s, no layout-animating properties.”
- PR checklist items: Does this PR add a new animated moment? If yes, which moment did it displace? Are animated properties transform/opacity only? Is reduced-motion handled?
- Trace review: open DevTools performance panel, interact with the page, confirm no animation-related long tasks near input; confirm scroll doesn’t jank.
- Lab + field check: Lighthouse for LCP/CLS sanity; CrUX or Search Console CWV for field truth before and after launch.
- Accessibility gate: every moment must respect prefers-reduced-motion — see prefers-reduced-motion accessibility guide. If reduced-motion handling is missing, the PR does not merge.
For teams formalizing this across clients, the production patterns in GSAP motion systems in production show how to structure timelines so budgets are visible in code (named moments, centralized config) rather than scattered tween calls.
Common budget mistakes
- Budgeting only visible motion, not setup cost. Ten ScrollTriggers that never fire still cost initialization.
- Animating layout.
height,margin, andtopanimations move space and burn CLS; prefertransformandopacity(see MDN on CSS transforms). - Gating LCP on a timeline. The hero must be paintable without waiting for JS choreography.
- One budget for every page. Blog, landing, and app screens have different jobs; give them different caps.
- No reduced-motion path. The budget’s twin is the reduced-motion budget — usually zero JS moments, CSS fallback only.
From budget to system
Treat the motion budget like any other engineering constraint: write it down per template, allocate explicitly, reject overruns in review, and measure after ship. Agencies that do this ship sites that feel alive without trading away the metrics Google reports and clients notice. If you are building motion into client work at scale, start from the budget, then choose techniques — motion web development services organized this way keep creative ambition and Core Web Vitals on the same roadmap.
Frequently asked questions
How many animated moments should a typical marketing landing page have?
Four to six perceived moments is a practical cap: one hero entrance, one primary CTA micro-interaction, one or two scroll reveals, and optional proof/logo motion. Stay under that when the page also loads media-heavy assets, and fund transform/opacity-only animations first.
Does animation always hurt Core Web Vitals?
No. Animations using transform and opacity, applied after the LCP element is painted, with no layout reflows and minimal main-thread work, can coexist with good LCP (<2.5s), INP (<200ms), and CLS (<0.1). Problems come from delaying paint, blocking input, or animating layout.
What is the fastest way to reduce motion-related INP issues?
Remove or defer heavy JS animation setup from interaction paths: avoid initializing long timelines on load, prefer CSS for micro-interactions, throttle scroll-linked work, and ensure event handlers yielding to the browser. Audit in the performance panel around real input events.
Should page transitions be part of the budget?
Yes — count them as a high-cost moment and gate them carefully. They run on every navigation, can delay paint of the next page, and interact badly with browser history and INP if implemented naively. Read page transitions, INP, and Core Web Vitals before funding one.
How do I document the budget for designers and developers together?
Put moment caps, allowed properties, LCP/INP/CLS targets, and reduced-motion rules in the page template spec and in PR acceptance criteria. A short motion spec shared at handoff keeps design intent and performance limits aligned — see guidance on documenting motion before development.
Read next: white-label web development for agencies · pixel-perfect Figma to WordPress development · GSAP motion and page transitions