60fps Animations
60fps Animations
60fps animations deliver smooth motion by rendering 60 frames per second, the standard refresh rate for most displays. Achieving 60fps requires completing all frame work within 16.67 milliseconds. Design systems must ensure component animations meet this performance target to provide polished, professional user experiences.
What Is 60fps Animation
60fps (frames per second) means the screen updates 60 times every second. Each frame has approximately 16.67ms for all work including animation calculations, layout, and rendering. Missing this deadline causes dropped frames visible as stuttering or jank.
Modern devices may support higher refresh rates (90Hz, 120Hz Pro Motion displays), requiring even faster frame completion. 120Hz displays need frames every 8.33ms. Animation systems should scale appropriately to display capabilities.
Smooth animation significantly affects perceived application quality. Users notice stuttering even without consciously recognizing the cause. Consistent 60fps animation creates polished experiences that feel responsive and well-crafted.
How to Achieve 60fps Animations
Compositor-accelerated properties animate most efficiently. Transform (translate, scale, rotate) and opacity changes can run on the GPU compositor without main thread involvement. These properties are the foundation of performant animation.
60fps Animation Techniques:
Preferred Properties (Compositor):
- transform: translateX(), translateY(), scale(), rotate()
- opacity
- filter (in supported contexts)
Avoid During Animation:
- width, height (triggers layout)
- margin, padding (triggers layout)
- position properties (triggers layout)
- Anything requiring paint or layout
Frame Budget:
60fps = 16.67ms per frame
120fps = 8.33ms per frame
Budget breakdown (approximate):
- JavaScript/Animation logic: ~3ms
- Style calculation: ~2ms
- Layout: ~4ms
- Paint: ~4ms
- Composite: ~2ms
iOS Techniques:
- Use UIView.animate with .allowUserInteraction
- Leverage Core Animation implicit animations
- Use CADisplayLink for precise frame control
Android Techniques:
- Use ObjectAnimator with hardware acceleration
- Leverage Compose animation APIs
- Use View.setLayerType for complex views
Avoiding layout during animation preserves performance. Animating size or position properties triggers layout recalculation, consuming frame budget. Transform-based animations achieve visual effects without layout cost.
Precomputation reduces per-frame work. Calculate values before animation starts rather than every frame. Cache expensive operations. Prepare resources (images, views) before animation begins.
Hardware layer usage helps with complex views. Setting a hardware layer before animating and removing it after reduces per-frame rendering cost for views with complex content.
Key Considerations
- Profile animations on actual target devices
- Lower-end devices need special attention
- Battery impact increases with animation complexity
- Reduce overdraw (overlapping animated elements)
- Consider reduced motion preferences
- Test at various device refresh rates
Common Questions
How do teams identify animation performance problems?
Platform profiling tools reveal frame timing. iOS Instruments with Core Animation template shows frame rate and compositor activity. Android GPU Profiler and frame timing tools show when frames exceed budgets.
Visual indicators help during development. Android developer options include GPU rendering profile bars. iOS can display frame rate with debugging tools.
Real device testing catches issues emulators miss. Emulators run on development machine hardware, which typically exceeds mobile device capabilities.
User reports indicate production issues. Monitoring for animation-related complaints helps identify problems that testing missed.
What causes common 60fps failures?
Layout during animation is a frequent cause. Animating width, height, or position properties triggers expensive layout recalculation. Using transform instead solves this.
JavaScript/main thread blocking prevents frame completion. Long-running operations on the main thread delay animation frames. Moving work to background threads or web workers helps.
Complex layer composition with many overlapping animated elements creates overdraw. Reducing layer count and simplifying animation structure improves performance.
Large image or bitmap operations during animation consume frame budget. Preloading and caching images before animation prevents this.
How do 120Hz displays affect animation development?
Frame budget halves from 16.67ms to 8.33ms. Animations that barely achieved 60fps may struggle at 120fps. Optimization becomes more important.
Users of 120Hz displays notice stuttering more easily. Higher baseline smoothness makes dropped frames more jarring.
Adaptive frame rate can help. Some animations might run at 60fps on 120Hz displays to conserve battery, accepting reduced smoothness for efficiency.
Testing should include 120Hz devices. ProMotion iPhones and iPads, and high refresh rate Android devices, reveal performance issues not visible at 60Hz.
Summary
60fps animations require completing frame work within 16.67ms, primarily achieved by animating compositor-accelerated properties like transform and opacity. Avoiding layout during animation, precomputing values, and using hardware layers help meet frame budgets. Design systems should specify 60fps as a performance target and require testing on actual devices to validate animation smoothness.
Buoy scans your codebase for design system inconsistencies before they ship
Detect Design Drift Free