Motion with Restraint, Revisited: The 2026 Motion Budget for Fast Sites
Two years on from our original motion philosophy piece. Here is the updated budget: what changed, what stayed the same, and why restraint still wins.
Two Years On
In 2024 we published Motion with Restraint, arguing that most animation on portfolio and brand sites is decorative noise. The thesis was simple: animate only to communicate state changes, guide attention, or provide feedback. Everything else is a frame-rate tax.
Two years later, the fundamentals have not changed. But the ecosystem has. Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital. CSS-native scroll-driven animations shipped in every major browser. View Transitions entered the mainstream vocabulary if not the mainstream implementation. The tooling moved forward. The principles did not.
This article revisits the motion budget for 2026: how to measure it, where to spend it, and what to cut.
What Changed Since 2024
INP made animation cost visible
The shift from First Input Delay to INP as a Core Web Vital changed how we measure interactivity. FID only measured the first interaction. INP measures every interaction across the entire page lifecycle. This means that janky scroll animations, slow transition callbacks, and heavy event handlers during animated sequences now directly affect your search ranking.
A site that performs well on FID but poorly on INP is a site where the first click feels snappy but scrolling through an animated hero feels sluggish. We covered the INP implications in detail in our INP optimisation article.
CSS scroll-driven animations shipped everywhere
The Web Animations API combined with animation-timeline: scroll() and animation-timeline: view() now has baseline support across Chrome, Edge, Firefox, and Safari. This is significant because scroll-driven animation no longer requires JavaScript libraries like GSAP's ScrollTrigger or Framer Motion's useScroll.
CSS-only scroll animations run on the compositor thread. They do not block the main thread. They do not affect INP. They are, on paper, free.
In practice, they are only free if the animated properties are compositor-friendly: transform and opacity. Animate anything that triggers layout (width, height, padding, margin) or paint (background-color, border-color, box-shadow) and the performance advantage disappears.
View Transitions API matured
The View Transitions API allows animated transitions between page navigations or DOM states. For multi-page applications (like statically exported Next.js sites), the cross-document variant (@view-transition) provides page-to-page animations without a single line of JavaScript.
The potential is real. The risk is also real: poorly implemented view transitions can introduce visual glitches, increase perceived load time, and break back-button expectations. We have seen exactly one production portfolio site implement cross-document view transitions well. The others looked like PowerPoint slides.
The 2026 Motion Budget
A motion budget is not a performance budget, though they overlap. The performance budget measures bytes and milliseconds. The motion budget measures animation count, duration, and purpose.
Rules of the budget
Rule 1: Every animation must have a job. The job must be one of four things: communicate a state change (menu opening, modal appearing), guide attention to new content (notification badge, scroll cue), provide feedback (button press, form submission), or establish spatial relationships (page transitions showing where content came from).
If the animation does not serve one of those four purposes, cut it.
Rule 2: Cap total animation duration per page load. On initial page load, the sum of all animation durations visible in the viewport should not exceed 800ms. That includes hero reveals, navigation fades, and any ambient effects. 800ms is enough to communicate "this page is alive" without making the visitor wait.
Rule 3: Scroll-triggered animations fire once. An element that fades in when scrolled into view should fade in once and stay visible. Repeating the animation when the element scrolls out and back in is distracting and serves no communication purpose.
Rule 4: Duration follows content importance. A page-level transition gets 300 to 500ms. A component state change (hover, active) gets 150 to 200ms. A micro-interaction (checkbox, toggle) gets 100 to 150ms. Nothing exceeds 500ms. Human perception research consistently shows that animations over 500ms feel sluggish.
Rule 5: Use CSS, not JavaScript. If the animation can be achieved with CSS transitions, CSS animations, or CSS scroll-driven animations, do not use JavaScript. JavaScript animations run on the main thread and affect INP. CSS animations on compositor-friendly properties do not.
What to animate
- Page transitions (fade or slide, 200 to 400ms)
- Mobile navigation open/close (slide or fade, 250ms)
- Hover states on interactive elements (150ms)
- Focus indicators (instant show, 150ms hide)
- Image loading placeholders dissolving to loaded state (300ms)
- Accordion or disclosure widget open/close (200ms)
What to cut
- Parallax scrolling on hero sections
- Scroll-triggered text reveal letter by letter
- Mouse-follow cursor effects
- Background gradient animations
- Counter animations (numbers counting up)
- Staggered card entrances where each card delays 100ms more than the last
- Infinite ambient looping animations
Every item on the "cut" list is something we have seen on portfolio sites this year. Every one adds zero communication value and measurable performance cost.
The prefers-reduced-motion Escape Hatch
The prefers-reduced-motion media query is not optional. It is an accessibility requirement. When the user has requested reduced motion, your animations must either be removed entirely or replaced with non-motion alternatives (opacity fades are generally acceptable to users who prefer reduced motion).
We covered implementation patterns in detail in our reduced motion article. The core pattern is straightforward:
```
@media (prefers-reduced-motion: reduce) {
, ::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
```
This is a nuclear option that kills all motion. A more refined approach is to replace motion-based animations with opacity-only transitions:
```
.card-enter {
animation: slide-up 300ms ease-out;
}
@media (prefers-reduced-motion: reduce) {
.card-enter {
animation: fade-in 150ms ease-out;
}
}
```
Measuring the Budget
Chrome DevTools animation inspector
The Animations panel in Chrome DevTools shows every running animation with its duration, delay, and easing. Open it, load the page, and count the animations. If there are more than five animations running in the initial viewport, the page is over-budget.
Lighthouse INP simulation
Lighthouse now includes INP simulation in its performance audit. Run Lighthouse, interact with the page during the audit, and check the INP score. If INP exceeds 200ms, investigate which interactions coincide with running animations.
Manual audit
Walk through the page on a 4G-throttled connection with CPU throttling at 4x slowdown. If any animation feels stuttery or delayed, it is a problem on real devices. The $1200 development machine hides performance issues that a $300 phone reveals.
Case Study: Stripping a Portfolio Hero
One recent project had a hero section with the following animations on load:
- Background image scale-down from 1.1 to 1.0 (600ms)
- Headline text slide up with stagger per word (1200ms total)
- Subtitle fade in (400ms, delayed 800ms)
- CTA button bounce in (500ms, delayed 1200ms)
- Scroll indicator pulse loop (infinite)
Total animation time before the page was "settled": 1700ms. The visitor had to wait nearly two seconds for the page to stop moving.
We replaced this with:
- Background image: no animation, loaded immediately
- Headline: opacity 0 to 1 over 200ms
- Subtitle: opacity 0 to 1 over 200ms, delayed 100ms
- CTA: no animation
- Scroll indicator: removed entirely
Total animation time: 300ms. The page felt instantly present. The Lighthouse performance score went from 78 to 94. INP dropped from 340ms to 120ms. And subjectively, the page felt more confident. It did not need to announce itself.
The Philosophical Argument
Animation in web design has the same problem as exclamation marks in writing. Used sparingly, they add emphasis. Used frequently, they signal insecurity.
A site that needs twelve scroll-triggered animations to feel impressive is a site that does not trust its content. A site that loads cleanly, presents its work clearly, and responds instantly to interaction communicates confidence through restraint.
The motion budget enforces that restraint mechanically. It converts a vague design instinct ("this feels like too much") into a measurable constraint ("the total animation duration exceeds the budget"). Constraints are liberating. They end the debate about whether the parallax effect is "worth it" by making the cost explicit.
Checklist
- Every animation has a documented purpose (state, attention, feedback, spatial)
- Total initial-viewport animation duration is under 800ms
- No single animation exceeds 500ms
- Scroll-triggered animations fire once, not on re-entry
- All animations use compositor-friendly properties (transform, opacity)
prefers-reduced-motionis respected with appropriate fallbacks- INP stays below 200ms across all page interactions
- Motion budget is reviewed at each design review, not just at launch