239KB。这是Lottie-web的体积，用来在网页上播一段SVG动画。GSAP更"轻"，100KB出头。但如果你只是想画个滑动的图标、让Logo自己描边出现，这个体积相当于用集装箱运一颗草莓。
Hari，一个印度独立开发者，被这个问题烦了很多年。每隔几周做落地页，他都要面临同样的选择：要么忍受手动写CSS关键帧的痛苦，要么给用户塞一个他们根本不需要的JavaScript库。
他选了第三条路——造了个叫CSSVG的工具，把动画体积从239KB压到0KB。
浏览器本来就会，为什么我们还要装轮子？
CSS的@keyframes（关键帧动画）原生支持SVG元素。没有依赖，没有运行时开销，浏览器直接渲染。问题在于：手写关键帧像蒙眼调音——你在改translate()数值，刷新浏览器，不对，再改，再刷新。
Hari算过一笔账。一个常见的入场动画：元素从下方滑入，同时淡入。用GSAP要写timeline，要引库，要担心打包体积。用CSS关键帧？理论上三行代码，但调试过程可能消耗20分钟。
「我想要的是中间态——CSS动画的零开销，加上可视化编辑的顺手。」他在产品介绍里写道。
CSSVG的交互逻辑极简：上传SVG，选中元素，拖拽时间轴设置关键帧，导出代码。输出的是纯SVG+CSS，没有包裹层div，没有data属性，没有运行时类名。粘贴进React、Vue或原生HTML都能直接用。
整个流程从空白画布到导出动画，Hari实测60秒。
对比他过去手动调试translateX的30分钟，这个效率差相当于从算盘跳到计算器。
他主动划清了边界
CSSVG不是万能药。Hari在产品页面上方用加粗字体列出了明确限制：不支持复杂路径动画，不支持物理效果，不支持滚动触发交互。这些功能在路线图里，但他选择先发布一个能用的版本，而非等待完美。
这个决策本身就很产品经理——先解决80%场景，再迭代剩余20%。
GSAP和Lottie依然是好工具，Hari反复强调。如果你要做物理模拟、复杂交互、游戏级动画，它们是对的选项。但对于悬停效果、加载动画、 subtle的入场过渡，给用户塞一个JavaScript库属于技术债。
一个细节：CSSVG的导出代码可读性极高。不是机器生成的乱码，而是人类能看懂、能手动微调的结构。这个设计选择暗示了Hari的目标用户——那些懂CSS、愿意在工具生成的基础上二次加工的前端开发者。
独立开发者的典型叙事，但数据说话
CSSVG是Hari单枪匹马从印度做出来的。没有融资公告，没有团队合影，只有一个X账号@cssvg_和免费开放的编辑器。
这种叙事在开发者社区越来越常见：个人工具解决个人痛点，开源或免费发布，靠口碑传播。但Hari的差异化在于他对"体积焦虑"的精准拿捏。
2024年的前端性能优化，JavaScript体积是核心战场。Core Web Vitals（核心网页指标）把首次内容绘制（FCP）和累积布局偏移（CLS）纳入排名因素，意味着每多一KB都可能影响搜索流量。239KB的动画库在这种语境下，从"有点重"变成"可能致命"。
CSSVG的零运行时策略，本质上是在性能预算（Performance Budget）紧张时的逃生通道。
Hari没有公布用户数据，但他在产品页埋了一个有趣的钩子：「如果你曾经花30分钟手动调translateX，试试这个。」
这句话的转化率可能很高——它精准筛选了经历过那种痛苦的人，而这类人正是CSSVG的核心受众。
工具的路线图显示，路径动画和滚动触发正在开发中。如果这两项落地，CSSVG的适用场景将从"简单动画"扩展到"中等复杂度"，与GSAP的重叠区域会扩大。但Hari似乎不打算正面竞争，他的定位始终是"CSS原生能力的可视化封装"。
一个值得观察的指标：多少用户会在导出代码后手动修改，而不是直接复制粘贴。这个比例能说明CSSVG是终点，还是开发者工作流中的一个中转站。
你现在做SVG动画，是继续用熟了的库，还是愿意试试这个零KB的替代方案？
热门跟贴