Lottie & Web Motion

Use Lottie for anything illustrated or vector-based: icons, loaders, empty states, UI micro-interactions, and simple hero animations. It stays sharp at any size because it renders vectors at runtime, supports true alpha transparency, and can be paused, scrubbed, or recoloured from your own code. GIF is the worst of the three for this job — it is capped at 256 colours, has only on/off transparency so edges fringe against your background, and is typically far larger than the equivalent Lottie. Video is the right answer when the content is photographic, uses heavy blur, film grain, or particle simulation, or is long enough that a vector file would be doing an unreasonable amount of per-frame work.

A Lottie is JSON, so its size tracks the number of layers, path points, and keyframes rather than the animation's duration or pixel dimensions — a five-second loop and a twenty-second loop of the same complexity are close to the same weight. The things that make files heavy are embedded raster images (base64 PNGs inside the JSON), high path point counts from traced artwork, per-frame baked keyframes, and unused precomps left in the composition. The optimisation pass targets exactly those. Shipping the dotLottie bundle instead of raw JSON adds compression on top, which is why we deliver both.

dotLottie (`.lottie`) is a zipped container that holds the animation JSON plus any images, fonts, and even multiple animations in a single compressed file. Because it is compressed, it is usually meaningfully smaller than the equivalent raw JSON, and because assets travel inside it, you avoid the broken-image problem where a JSON references files that never made it to the server. Use it when your player supports it — the dotLottie web component and React player do natively. Keep the plain JSON when you are on an older lottie-web setup, a platform whose Lottie element expects a JSON URL, or a build pipeline that wants to inline the animation. We ship both so the choice stays yours.

The SVG renderer creates real DOM elements for every shape, which gives you perfectly crisp scaling and lets CSS reach into the animation, but it means the browser is doing layout and paint across potentially hundreds of nodes each frame. The canvas renderer draws to a single element, so node count stops mattering and complex artwork gets much cheaper, at the cost of rasterising at the size it is drawn — you have to handle device pixel ratio, and you lose CSS access to the internals. Our rule of thumb: SVG for small, simple UI animations and anything that needs to scale arbitrarily; canvas for busy illustrations, many simultaneous instances, or anything that must run smoothly on low-end mobile. We test both and tell you which one this file wants.

Most effects do not: blurs, glows, distortions, and third-party plugins are simply absent from the exported JSON, because Lottie describes vector shapes and transforms rather than a render pipeline. 3D layers, layer styles, motion blur, and several blend modes are unsupported or approximated, inverted and complex track mattes are unreliable, and merge paths generally does not survive. Expression support depends on the build you ship — the lighter lottie-web build drops the expression engine entirely to save weight, so anything expression-driven has to be baked into keyframes at export. This is why we scope the design against the supported feature set at the brief stage rather than discovering it the day the file is due.

In React, install `lottie-react` or the dotLottie React player, import the JSON or point at the hosted `.lottie`, and render it inside a container with a fixed aspect ratio so nothing shifts while it loads. In Webflow, the built-in Lottie element takes a hosted JSON URL and exposes loop, trigger, and scroll-scrub settings directly in the designer, and it can be driven by Webflow Interactions without any code. In WordPress, the usual routes are a Lottie block or a small enqueue of the dotLottie web component, then a shortcode or block wrapper around it. Every animation we deliver includes the specific snippet for your stack, plus where to lazy-load it so it does not compete with your largest contentful paint.

Nearly always one of four things. The file is too complex for the SVG renderer, so the browser is recalculating layout across hundreds of DOM nodes every frame — switching to canvas usually fixes it outright. Several animations are playing at once, including ones scrolled far off screen, when they should be paused with an IntersectionObserver. The animation is fighting the main thread during a scroll or a hydration pass, so it should be delayed until after first interaction. Or the artwork itself has path point counts that came from auto-traced imagery and needs simplifying at source. Send us the file and the page and we will tell you which one it is — this is a diagnosis we do often.