我拆了一个图片压缩网站：它到底靠什么获得流量？

图片压缩是个看起来毫无门槛的品类：拖进去一张图，吐出来一张小的。也正因为如此，它几乎是所有想做工具站的人第一个想到的方向。

但把几个站拆开之后，我发现这个品类的竞争根本不在界面上，而在一个很隐蔽的技术选择上：图片是在你的服务器上压，还是在用户的浏览器里压。

需求是真的，而且大得离谱

先说需求端。"image compressor"这类词在关键词工具里的月搜索量是 74 万量级，TinyWow 靠它和相关词拿到了相当可观的搜索流量。它同时还有 “png to jpg” 这类相邻词，月搜索量接近 88 万。

TinyWow 首页的口号是 Free Tools to Make Simple，Logo 旁缀着 by Jenni——2025 年被收购后的新标识。

这么大的量，说明它对应的是一个反复出现、并且带点紧迫感的动作：图片传不上去、邮件附件超限、网页加载太慢。用户不是想"了解压缩原理"，是"现在就要一张小一点的图"。

这类需求的特点是几乎不需要教育用户，也几乎不受趋势影响。相比之下，那些依赖某个新概念的工具站，热度过去了流量就塌了。

真正的分水岭：图片去哪儿了

早期的图片压缩站都是上传式的：文件传到服务器，压完再下载。这条路的问题有三个，而且会互相放大。

成本。 图片是带宽和存储的大户。一个小有名气的压缩站，每月的流量账单可以轻松吃掉全部广告收入。

隐私。 用户压的往往不是风景照，是身份证、合同、病历。你让这些文件过一遍陌生服务器，理性用户会犹豫。TinyWow 特意在页面上写明上传的文件 1 小时后自动删除，就是在处理这个顾虑。

合规。 一旦文件真正落到你的磁盘上，你就得面对数据留存、跨境传输、删除请求这些问题。对个人开发者来说，这套东西的重量远超过压缩算法本身。

浏览器端压缩把这三条一起解决掉。图片从头到尾没离开用户的设备，你的服务器只发静态文件，成本接近零，隐私声明一句话写完。

技术上怎么做到的？两条路。一条是 Canvas 重绘：把图片画到 canvas 上再导出，用 toBlob() 指定质量参数，几行 JavaScript 就能跑，对 JPEG 效果很好，代价是不支持动图、处理大图时容易卡死主线程。另一条是把成熟的 C/C++ 编解码器编译成 WebAssembly 在浏览器里跑，Google 的 Squoosh 就是这么做的——它能用上 mozjpeg、webp、avif 这些工业级编码器，压缩率和速度都远超 canvas 方案，代价是 wasm 文件本身有点大，需要预加载或懒加载。

选择哪条取决于你要压什么。纯 JPEG 缩小尺寸，canvas 足够；要追求压缩率或者要输出 WebP/AVIF，就得上 wasm。

为什么"简单"在这里是优势

图片压缩这类工具还有个特点：它不需要前后端配合，不需要数据库，不需要用户系统。

这意味着一个人可以在几天内做出一个能用的版本，并且几乎不需要运维。没有后台任务、没有队列、没有存储清理，服务器挂了用户刷新一下就好。这种"做完了就真的做完了"的特性，对个人开发者来说比流量数字更重要——你不用为每个用户承担一份持续的运维责任。

反过来看，这也是这个品类竞争激烈的原因。门槛低意味着对手多，所以真正能站住的不是"又一个压缩站"，而是在某个维度上做得更彻底的：压得更狠、支持更冷门的格式、能批量处理、能保住 EXIF，或者干脆把压缩嵌进一个更大的工作流里。

如果要做，我会先验证什么

先确认用户愿不愿意为"不上传"这件事改变选择。这是个可以在页面上直接测的假设：把"图片不会离开你的浏览器"放在首屏最显眼的位置，看停留时间和跳出率有没有变化。

再确认目标格式。如果用户主要是压 JPEG 发邮件，canvas 方案就够了，别一上来就折腾 wasm；如果是做 Web 性能优化的人，他们要的是 WebP 和 AVIF，那 wasm 是必需项。

最后确认量。这个品类的广告单价不高，靠它赚到能覆盖时间的钱，需要的是搜索覆盖而不是单页优化。想清楚这一点，才知道该花时间在多做格式上，还是在做多语言页面上。

关键词搜索量来自第三方 SEO 工具的公开估算；TinyWow 文件留存策略引自其官网说明。