Best Practices
Rive plays interactive graphics efficiently, but poorly optimized files can use too much memory or CPU — especially on older devices. This guide covers the most important things to keep in mind.
Test your animations on your target devices early and often.
Design-Time Tips
Keep Assets Small
Images, audio, and fonts are usually the biggest cause of large file sizes.
Only assets used in artboards are included in the exported .riv file. Unused assets in the Assets panel don't add to file size.
Fonts — Font files often contain thousands of characters you don't need. Choose only the glyphs (the individual character shapes in a font) required for your text to reduce export size.
Images — Match image dimensions to how they'll actually appear on screen. Don't use an 8192×7022 image in a 100×100 slot. Large images use memory even when compressed.
Compression — Compress images directly in the Rive editor. Use WebP format for the best balance of quality and file size.
Vector art — Use only as many path points (vertices) as needed. AI-generated or raster-converted (traced from a pixel image into vector format) vectors often have too many points.
Importing from Lottie
Recreating animations directly in Rive produces smaller files than converting from Lottie. If you import Lottie files, convert PNG images to WebP and export only the glyphs you need.
Blend Modes on Web
Blend modes (ways of mixing overlapping colors, like "multiply" or "screen") are expensive on web because they require extra processing steps behind the scenes. Use them sparingly in web projects.
Artboard Tips
- Clipping: Remove the clip from the main artboard when nothing outside the Rive instance renders at runtime (when your app is actually running for a user). Apply clips to specific objects instead.
- Unused artboards: Unused artboards still load into memory. Remove any artboards not actively used.
Idle Animations
For states where nothing moves, use a one-shot animation (an animation that plays once and stops). When no looping animations are playing, the Rive runtime can pause itself and cut CPU usage significantly. This helps for icons and buttons that only animate on interaction.
Solos
A Solo hides sibling objects when one is active — useful for toggling between states. For complex skins (visual style sets that change how a character or object looks) that don't need bone binding (attaching mesh parts to a skeleton so they move together), use Data Binding (a system that connects your data directly to visual properties) instead. Data Binding is more performant because it only renders what's needed.
Blend States
Make sure blend states transition to another state or an exit state when done. Think of it like a revolving door — if it never stops, it keeps consuming energy. An active blend state keeps the runtime running even when it's no longer needed. Giving it a clear exit reduces unnecessary CPU usage.
Runtime Tips
The tips below are for developers who integrate Rive in code.
Load Assets Separately (Out-of-Band)
Load images, fonts, and audio separately at runtime instead of embedding them in the .riv file. This gives you:
- Smaller
.rivfile size - Assets that can be shared across multiple Rive files
- Assets that can be preloaded and cached before display
- Assets that can be swapped based on screen resolution
Cache Your .riv File
If the same Rive file appears in multiple places on a page or in an app, cache the file. Parse the file once and reuse the result — this is much faster than decoding it each time a new instance starts.
Pause When Offscreen
Pausing a Rive instance drops its CPU usage to near zero. Good times to pause:
- Offscreen — Pause when the graphic scrolls out of view. Resume when it returns.
- Reduced motion — Check the user's
prefers-reduced-motion(the browser setting some users turn on to reduce animations) setting and pause or setautoplay: false(a code option to stop autoplay) accordingly. - Idle state — Pause while waiting for user interaction, like a state machine at rest.
Low-End Devices
Test on lower-end hardware if your audience includes older devices. Consider creating an alternate artboard with reduced animation, and swap to it at runtime when the device is less powerful.