Lottie animations are one of the best things to happen to web design. They bring After Effects quality motion to the browser at a fraction of what video would cost. A well-crafted Lottie makes a page feel alive, polished, and distinctly premium.
They are also one of the most common performance problems I find on slow sites. Not because Lottie is bad technology. Because it is easy to use without understanding the cost.
The performance reality
A Lottie animation runs on JavaScript. The Lottie web player (lottie-web) is a JS library that parses a JSON file and renders it frame by frame, either to SVG or Canvas. Every frame is computed and drawn by the browser's main thread.
This means:
- The Lottie player library itself adds 50-150 KB of JavaScript to your bundle.
- Each animation JSON file adds its own weight: 10 KB for a simple icon animation, 500 KB to 2 MB for a complex illustration.
- Rendering competes with everything else on the main thread: layout, paint, event handling, and other scripts.
On a page with one small Lottie icon that triggers on scroll, the cost is negligible. On a page with three complex Lotties in the hero section, all set to play on page load, you are adding 1-5 MB of JS-driven rendering that fires before the user sees any content.
When the cost is not worth it
Above the fold, on page load. Any Lottie in the hero section that plays on load competes directly with your LCP element. If the animation is the LCP element, it takes significantly longer to render than a static image would. If it is alongside the LCP element, it steals main thread time from rendering the image or text that LCP measures.
Multiple animations on the same page. Each additional Lottie multiplies the rendering cost. Three Lotties on a page can keep the main thread busy for several seconds, which tanks INP (Interaction to Next Paint) because the browser cannot respond to user input while rendering animations.
On mobile devices. Mobile CPUs are 3-5x slower than desktop CPUs. A Lottie that plays smoothly on your MacBook Pro can stutter and drop frames on a mid-range Android phone. The experience degrades exactly where your audience is most likely browsing.
When the animation is decorative. If removing the animation would not change the user's understanding or decision, it is decorative. Decorative elements should not cost performance. Use CSS for subtle motion instead.
Want a website that turns visitors into customers, not just compliments?
Book a 15-min introWhen the cost is worth it
Explaining a concept visually. A Lottie that shows how a product works, a process flow, or a before/after transformation adds genuine value. It communicates something that text and static images cannot. In this case, the animation earns its weight.
Below the fold, triggered on scroll. When a Lottie only loads and plays when the user scrolls to it, it has zero cost on initial page load. The LCP is unaffected. The hero renders fast. Then, as the user scrolls, the animation provides a moment of delight without compromising speed.
Micro-interactions on user action. A small Lottie that plays when the user clicks a button, submits a form, or hovers over an element is lightweight and enhances the experience. These are typically small files (under 50 KB) and only render on demand.
One-time impact pages. A landing page designed to convert first-time visitors might justify a heavier animation budget if the visual storytelling meaningfully improves conversion rate. But measure it, do not assume.
How to use Lottie without killing speed
Defer loading. Do not load the Lottie player or animation files on initial page load. Use Intersection Observer to detect when the animation container enters the viewport, then dynamically load the player and the JSON file. This ensures zero performance cost until the user scrolls to the animation.
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
loadLottie(entry.target);
observer.unobserve(entry.target);
}
});
});
document.querySelectorAll('.lottie-container').forEach(el => {
observer.observe(el);
});
Cap file complexity. Before exporting from After Effects, simplify the animation. Reduce the number of layers, avoid raster images embedded in the JSON, and remove unnecessary keyframes. A well-optimized Lottie can be 50-100 KB. A sloppy export of the same visual concept can be 1 MB.
Use a static fallback above the fold. Export a single frame from the animation as a WebP image. Display that image immediately. Then lazy-load the Lottie and swap it in once the page is interactive. The user sees a fast-loading static version of the animation, followed by the motion a moment later.
Consider the canvas renderer. Lottie-web offers SVG and Canvas renderers. SVG is better for simple animations with few elements. Canvas is better for complex animations with many moving parts because it offloads rendering from the DOM. For performance-critical uses, test both and pick the one that runs smoother on your target devices.
Set a performance budget. Decide upfront how much total animation weight your page can support. A reasonable budget for most pages is 200-300 KB of Lottie JSON files total. If a single animation exceeds that, simplify it or replace it with a lighter alternative.
Lighter alternatives to Lottie
Not every animation needs Lottie. For simpler motion, lighter alternatives exist:
- CSS animations. Fades, slides, rotations, scale effects, and gradient transitions are nearly zero-cost in CSS. They run on the compositor thread, not the main thread, so they do not affect INP.
- SVG animations. For path drawing, morphing, and simple movement, CSS-animated SVG is lighter than Lottie and does not require a JavaScript library.
- GIF or WebP animation. For very short loops where the visual is more important than interactivity, an animated WebP can be lighter than Lottie while providing the same visual result.
The decision framework is straightforward: if CSS can do it, use CSS. If the animation is too complex for CSS but could work as animated SVG, use that. Only reach for Lottie when the animation genuinely requires After Effects-level complexity.
The audit question
Look at every Lottie on your site and ask: would a static image or CSS animation deliver 80% of this visual impact at 5% of the performance cost? If the answer is yes, make the swap. Save Lottie for the moments where the full animation genuinely earns its weight in user engagement or comprehension.
If your site has heavy animations competing with critical content and your speed scores reflect it, that is part of the performance optimization work I do. The goal is never to strip out everything that looks good. It is to make every byte earn its place on the page.