The Problem: The "Black Box" of Web Animation
We’ve all been there. You want a high-fidelity animation, so you reach for Lottie or Rive. They look amazing, but they come with a cost:
The Weight: Rive’s runtime starts at 280KB+. Even SVGator sits around 38KB.
The SEO Void: Canvas-based animations are "black boxes." Search engines can't see what's inside.
Accessibility: Screen readers often struggle with non-DOM elements.
As a Senior Developer obsessed with performance, I thought: "Can we have high-end motion without sacrificing the DOM?"
The Solution: Fluv, the Semantic Motion Engine
I spent the last few months building Fluv. It’s not just another library; it’s a Semantic Motion Engine designed to treat animations as native web citizens.
Key Achievement: 20KB Modular Runtime
By building a proprietary modular architecture, I managed to get the runtime down to 20KB.
Selective Loading: It only loads the features your specific animation needs (easing funcs, staggering, etc.).
10KB Lighter: It’s consistently 10KB to 20KB lighter than the nearest competitors.
Why "Semantic"?
Unlike Canvas-based solutions, Fluv manipulates SVG paths directly in the DOM.
SEO-Native: Every element is crawlable.
Stylable: You can still interact with your animations via CSS/JS.
Lightweight: No heavy engine needed to "render" a frame; the browser does what it does best.
Technical Deep Dive
I re-engineered how path data is parsed and interpolated. Instead of massive JSON files, Fluv uses a compressed logic that prioritizes mathematical curves over raw frame data.
Support includes:
Extended animation types (Path morphing, transforms).
Complex staggering for group elements.
Custom easing functions for organic movement.
Check out the Repo
I’m currently refining the engine and would love some feedback from the performance community.
GitHub: https://github.com/Shadoworker/fluv.git
I'm curious: What is your "budget" for animation runtimes in your professional projects? Does 280KB feel like too much for a landing page? Let's discuss in the comments!